Acumatica 2026 R2's built-in MCP server, compared with MCP4Acumatica

2026 R2 ships its own MCP server (the MCP Server feature under AI Studio, configured on MCP Servers, SM302100). We maintain MCP4Acumatica, an open-source (Apache-2.0) MCP server for Acumatica that runs on Cloudflare Workers, so we put the two side by side on a 2026 R2 sandbox: same user, same Generic Inquiries, same queries, Claude as the client. Along the way we found a few things about GI OData that matter to anyone using it directly, and we checked those on 2025 R2 as well.

Short version

• The built-in server is the easiest way to give an AI client curated GIs — if you license AI Studio. No hosting, parameterized GIs work, and every response carries an exact total with skip/top paging. The MCP Server feature sits in the AI Studio feature group, so it is only available when AI Studio is part of your Acumatica license.
• It is GI-only, and the model gets no help when a query is wrong. Every failure we triggered came back as the same generic message, and parameters described as mandatory are not enforced.
• Two GI OData findings worth knowing even if you never use MCP:
  • $count works on the GI OData endpoint in 2026 R2, although the 2025 R2 documentation lists it as unsupported.
  • Parameterized GIs can be called over OData with values (2025 R2 and 2026 R2), but a misspelled parameter name is silently ignored and the inquiry returns unfiltered rows. Validate names first, and it works well: we now run parameterized GIs this way on a 2025 R2 production tenant.
• The two servers are complementary. Nothing stops you connecting both.

What we tested

Three GI tools on one built-in MCP server: an AP document inquiry, a GL batch inquiry, and a parameterized kit-component inquiry. We ran the same filters through both servers, including deliberately wrong ones. The OData parameter behavior was then checked on a 2025 R2 production tenant with direct OData calls. Acumatica notes that the built-in server's generated tool schemas are not fixed contracts and may change between releases.

Side by side

Findings worth knowing

1. $count works on GI OData in 2026 R2

The built-in server's exact totals made us test $count=true against /t/{tenant}/api/odata/gi/{Inquiry} directly. On 2026 R2 it returns @odata.count, with or without a filter, and the count equals the number of rows the same query returns. The 2025 R2 Reporting Tools guide lists $count among the options the GI-based OData interface does not support; we have not tested 2025 R2 itself.

2. Calling parameterized GIs over OData

The Reporting Tools guide documents this, but several details are easy to get wrong. Checked on 2026 R2 and 2025 R2:

• Querying a parameterized GI by its plain name runs it with no parameter values. Depending on how the design uses each parameter, you get no rows or every row, with no error either way.
• The URL that takes values is /t/{tenant}/api/odata/gi/{Name}_WithParameters(Param=value). The exact name is the FunctionImport in $metadata (the GI name with spaces and punctuation removed); the parameters are listed in the Function element it points to.
• $filter, $select and $top work on top of the parameters. Strings are single-quoted with ' doubled. A value of '' is a literal blank that usually matches nothing, not "no value": leave the parameter out instead.
• A parameter marked Nullable="false" in $metadata is one with Is Required checked on the GI's Parameters tab. Leaving it out returns HTTP 404.
• An optional parameter left out takes the GI's default value (@QuarterStart, for example), so the result can be narrower than you expect.
• A misspelled parameter name is silently ignored. The call succeeds and returns the inquiry's unfiltered rows. Check names against $metadata before calling.
• Date-time values cannot go in the URL path: the : is rejected by ASP.NET request validation ("A potentially dangerous Request.Path value was detected"). Parameter aliases avoid it: (FromDate=@p1)?@p1=2026-10-01T00:00:00Z.
• 2025 R2 declares GI date parameters as Edm.DateTimeOffset, while 2026 R2 declares them as Edm.Date. 2025 R2 still accepts a plain 2026-10-01 for them.

MCP4Acumatica 0.56.0 builds on this: it validates names, types and required parameters before calling Acumatica, sends every value as an alias, and tells the model which defaults applied. It is running against a 2025 R2 production tenant.

3. Every error reads the same

On the built-in server, a misspelled field, a v3 function (substringof) on this v4 endpoint, and a filter on a calculated column all returned An error occurred invoking '<tool>'. with no detail. The model cannot tell which part of its query to fix, so it guesses. One improvement over plain GI OData on 2025 R2: a filter on a calculated column now fails with an error instead of an empty 200 response.

4. Parameters are inputs, but not required

On the built-in server, passing a parameter returned exactly the right rows. However, the schema describes the parameters as mandatory without marking them required, and a call without them ran the inquiry with blank parameters. For our kit inquiry that meant "all kits", which happens to be harmless. For an inquiry whose parameters drive defaults or joins, blank parameters can return plausible but wrong rows with no warning.

5. Descriptions: names only, even with Description for AI filled in

The generated tool description is a list of field names, with no types and no description of the inquiry. 2026 R2 adds Description for AI fields on the GI, on Results Grid columns and on Parameters. They are stored on the inquiry design, but Generic Inquiry (SM208000) shows them only when AI Studio is licensed, and the documentation ties them to the in-product AI Assistant (processed on ML503010) without mentioning MCP. We filled in the inquiry description and two column descriptions on one GI and reconnected the client: the tool description was unchanged. Caveat: we could not process the GI on AI Assistant Data Processing (ML503010); on our self-hosted sandbox it fails with Discovery endpoint address not set, which we take to mean the AI Assistant cloud service is not configured there. So our result covers descriptions that are entered but not processed. If you have AI Assistant running and have seen processed descriptions reach MCP clients, please say so.

6. The two paths do not always see the same rows

For the same user and inquiry, the built-in server returned a handful of rows that GI OData never returns, even when filtered by the document's own key. GI OData on 2025 R2 hides the same rows. We have not determined the cause or which behavior is intended; it shows up only if you compare totals between the two.

Setup gotchas

• License first. The MCP Server feature appears on Enable/Disable Features (CS100000) under the AI Studio group; without AI Studio in your license you can't enable it, and the Description for AI fields on Generic Inquiry (SM208000) are hidden too. The 2026 R2 docs tie AI units to AI Assistant; they don't say MCP calls consume them (the AI client runs its own model), but confirm with Acumatica for your contract.
• The {tenant} in /t/{tenant}/... URLs is the tenant's Login Name on Tenants (SM203520), not its Tenant Name. A single-tenant instance shows no tenant list on the sign-in page, so it is easy to use the wrong one. On a self-hosted instance, a wrong value made IIS return its own 404 page (handler StaticFile) to a signed-in browser and 401 to a bearer token, which looks like an authentication problem.
• The built-in server's URL follows the pattern {instance}/t/{Login Name}/mcp/{Server Name}.

Which to use

• Built-in server: curated GIs, paging through large results, no infrastructure — if AI Studio is in your license.
• MCP4Acumatica: entity lookups, schema and documentation questions, corrective errors, enforced GI parameters, field redaction, clients that register themselves, and no AI Studio license.

Questions and corrections welcome, especially if Description for AI reaches MCP clients in your build.