---
title: "Does the Dynamics 365 ERP MCP server truncate results?"
canonical_url: "https://cognilium.ai/blogs/does-the-erp-mcp-server-truncate-results"
slug: "does-the-erp-mcp-server-truncate-results"
section: "blogs"
date_published: "2026-09-09"
date_modified: "2026-09-16"
word_count: 1186
reading_time_minutes: 5
author: "Mudassir Marwat"
author_identifier: "0009-0008-1927-2598"
person_same_as:
  - "https://www.linkedin.com/in/mudassir-marwat/"
  - "https://orcid.org/0009-0008-1927-2598"
  - "https://github.com/mudassirmarwat"
  - "https://medium.com/@mudassir-marwat"
  - "https://www.youtube.com/@mudassir-marwat"
  - "https://dev.to/mudassirmarwat"
  - "https://hashnode.com/@mudassirmarwat"
  - "https://huggingface.co/mudassirmarwat"
  - "https://bsky.app/profile/mudassir-marwat.bsky.social"
  - "https://substack.com/@mudassirmarwat"
  - "https://topmate.io/mudassirmarwat"
  - "https://fueler.io/mudassirmarwat"
  - "https://www.instagram.com/mudassirmarwat/"
  - "https://www.facebook.com/mudassir.marwat"
  - "https://www.reddit.com/user/mudassirmarwat/"
  - "https://www.f6s.com/member/mudassir-marwat"
  - "https://cognilium.ai/founder"
entities: []
related:
  - "https://cognilium.ai/blogs/mcp-data-tools-vs-form-tools-vs-action-tools"
  - "https://cognilium.ai/blogs/which-environments-run-the-erp-mcp-server"
  - "https://cognilium.ai/blogs/which-model-should-an-erp-agent-run-on"
---
# Does the Dynamics 365 ERP MCP server truncate results?

Form state carries at most twenty-five rows, and the warning is an instruction a builder can delete. The cap is on the form path, not the data path.

## Key takeaways

- Form state carries at most twenty-five rows, and the agent does not error when it reaches the ceiling — it answers.
- The cap is a platform property; the warning is a prompt instruction. Delete the instruction and the truncation becomes invisible.
- *Grid filtering supports only the matches operator* — no before, after or between on dates — so the usual way of getting under the ceiling is unavailable on the form path.
- Microsoft scopes the cap to form state, which makes choosing the data path a correctness decision and not only a performance one.
- A full page of rows is the boundary condition that reads as success, which is why it needs a habit rather than a check.

**Yes — form state carries at most twenty-five rows.** The agent does not error when it hits the ceiling. It answers, and the answer is built on whatever arrived.

The part worth knowing is where the cap applies and where it does not, because that distinction is also the fix.

## Is there a documented row cap?

There is, and it sits in the agent instruction block Microsoft publishes as a starting point:

> *"A tool call response can include up to 25 rows of data as form state. Generate a warning if the form state contains 25 rows of data."*

**Two separate things live in that sentence**, and separating them is the whole article:

The cap is real whatever you do. **The warning exists only if the instruction survives into your agent.**

## Does hitting the cap produce an error?

No, and that is the design worth understanding. Microsoft's mitigation is a *behavioural* one — it asks the model to notice and say so, rather than the platform refusing.

Which means the failure is silent by default, and the boundary condition is exactly the one that reads as success: a full page of results. **An agent that receives twenty-five rows has no way to know whether the answer was twenty-five or two hundred.** It sees a complete-looking set and reasons over it.

Microsoft's instruction block guards a closely related failure in the same section, and the pairing is telling:

> *"When instructed to create new data, and the creation fails, DO NOT retrieve existing data instead."*

**Both rules exist to stop an agent reporting a partial or substituted result as a whole one** — which is [the false-success problem](/blogs/why-erp-agents-report-false-success) in its read-side form.

**Do not delete either line when you customise the instructions.** They read like boilerplate and they are the two sentences doing correctness work.

## Why is twenty-five rows easier to hit than it sounds?

Because the filtering that would narrow a grid below the ceiling is itself limited. Limitation eight of ten:

> *"The MCP server doesn't support advanced filters on grids. For example, it doesn't support the 'before,' 'after,' and 'between' operators for date columns. It supports only the 'matches' operator for filtering."*

**No date range.** For a transactional ERP that is the single most natural way to cut a result set down, and on the form path it is unavailable. Ask about open orders in a period and the grid you are filtering is the whole grid.

There is one published exception worth knowing, because it reads like an escape hatch and is narrower than it looks: `(lessThanDate(x:int))` *"is a valid value for a grid date column filter"* — a relative, one-sided comparison, not a range.

Two other form behaviours compound it. Tabs *"are closed by default"* and the agent must open them to reach controls, and the `form_find_controls` tool *"accepts only one search term per call."* **More calls to assemble less context** — and outside Copilot Studio every one of those calls is billed.

## What does a truncated answer look like from the outside?

Like a good one, which is the entire problem.

A reviewer reading the agent's reply sees a well-formed list of records, correctly retrieved, correctly described. There is no ellipsis, no "showing 25 of 212", no marker of any kind — the response is simply built from a smaller set than the question implied.

**Compare that with the failure modes people design for.** A timeout is visible. A permission error names itself. A wrong value can be spotted by someone who knows the data. **A short answer that is internally consistent survives every one of those checks**, because nothing about it is wrong except its completeness.

That is why the mitigation Microsoft chose is a warning rather than a validation: there is nothing for the platform to reject. The response is valid. It is the inference drawn from it that is not.

## Does the cap apply to data tools as well?

Read Microsoft's words closely: the limit is on rows *"as form state."*

**Form state is what the form path returns.** The data tools are a different family — they read through data entities over OData, and Microsoft describes that path as needing *"fewer tool calls"* and giving *"better performance"* for standard operations.

So the honest answer is that **the twenty-five-row sentence is scoped to form state and does not, on its face, describe the OData read path.** We are not asserting that data tools are uncapped — Microsoft does not say that either, and an unbounded claim about a limit that is not documented would be a guess. What is documented is the scope of *this* cap, and it is the form path.

That makes tool-family choice a correctness decision and not only a performance one, which is [the routing question](/blogs/mcp-data-tools-vs-form-tools-vs-action-tools) this cluster's comparison covers.

## What should you actually do about it?

Three moves, in order of return. These are ours:

- **Keep the warning instruction, verbatim.** It costs one line and it is the only thing that surfaces the condition at all. Treat it as load-bearing when you rewrite the prompt.
- **Route list-shaped reads to data tools.** If the job is "find the records", that is the family Microsoft tells you to prefer anyway, and the documented cap is on the other path.
- **Design the question to be narrow.** With only a *matches* operator on the form path, narrowing has to come from the request rather than the filter — one customer, one order, one item, rather than a period.

**And treat a twenty-five-row answer as unproven.** Not wrong, unproven. That is a cheap habit and it is the one that catches the case where the number mattered.

**About Cognilium** Cognilium builds AI optimization apps for Microsoft Dynamics 365 — companion apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Dynamics is your system of record. Cognilium is your system of intelligence. https://cognilium.ai · https://www.linkedin.com/company/37180269/

**Agentic ERP.** We build turnkey AI optimization apps for Dynamics 365 — sidecar applications that run in your own Azure tenancy and solve the calculations a standard ERP is not built to compute. Built on **Azure OpenAI, Microsoft Fabric and Copilot Studio**. We build these on request, against your data and your environment.

**More on the boundary between what Copilot does and what you build:** [Agentic ERP on Dynamics 365](/erp-ai).

If an agent is giving you answers that look complete, the row cap is worth ten minutes of someone's attention. Bring a query that returned a full page to a 15-minute call.

## Sources

- [Build an agent with Dynamics 365 ERP MCP](https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/copilot/build-agent-mcp)
- [Use Model Context Protocol for finance and operations apps](https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/copilot/copilot-mcp)

## Fact-check

**Tier summary:** 10 × T1 (8 verbatim, 2 read off a quotation), 4 × T2 — **0 × T4.**

**The absence claim this article deliberately does NOT make.** The obvious next sentence — *"so data tools have no row cap"* — is unsupported. Microsoft scopes the twenty-five to form state and publishes nothing about an OData ceiling, and **an absence found by not seeing it is not evidence.** §4 says this in the body rather than hiding it in a fact-check row, because a reader will reach for that inference themselves.

## Frequently asked questions

### Is there a documented row cap?

There is, and it sits in the agent instruction block Microsoft publishes as a starting point:

### Does hitting the cap produce an error?

No, and that is the design worth understanding. Microsoft's mitigation is a behavioural one — it asks the model to notice and say so, rather than the platform refusing.

### Why is twenty-five rows easier to hit than it sounds?

Because the filtering that would narrow a grid below the ceiling is itself limited. Limitation eight of ten:

### What does a truncated answer look like from the outside?

A reviewer reading the agent's reply sees a well-formed list of records, correctly retrieved, correctly described. There is no ellipsis, no "showing 25 of 212", no marker of any kind — the response is simply built from a smaller set than the question implied.

### Does the cap apply to data tools as well?

Read Microsoft's words closely: the limit is on rows "as form state."

### What should you actually do about it?

And treat a twenty-five-row answer as unproven. Not wrong, unproven. That is a cheap habit and it is the one that catches the case where the number mattered.

---

Canonical HTML: https://cognilium.ai/blogs/does-the-erp-mcp-server-truncate-results