MCP4Acumatica 0.56: Acumatica 2026 R2 support, and parameterized Generic Inquiries

Hi all,

Two pieces of news for MCP4Acumatica, our open-source (Apache-2.0) MCP server that gives AI assistants governed access to Acumatica:

1. It now runs on Acumatica 2026 R2.
2. It can run Generic Inquiries that take parameters. Until this release it refused them, and the reason is worth knowing even if you never use our server.

Acumatica 2026 R2

We've been running a second MCP4Acumatica worker against a 2026 R2 sandbox (contract endpoint 26.200.001) alongside our 2025 R2 production one. On 2026 R2 we've exercised the Generic Inquiry tools (listing, describing, running, parameters, filters), entity lookups and searches on the contract API, and the documentation tools answering from the 2026 R2 documentation, release notes included.

What went into it:

• Documentation index for the new docs format. From 2026 R2 the official Markdown documentation ships as one file per help topic; the ingestion script handles that layout since 0.54 (and still builds the older monolithic guides).
• Exact totals (0.55, opt-in). $count works on the GI OData endpoint in 2026 R2, although the 2025 R2 docs list it as unsupported. With ACUMATICA_GI_COUNT on, a result that hits the row cap tells the assistant "N records match" instead of "there may be more".
• Release differences handled. For example, 2026 R2 declares GI date parameters as dates where 2025 R2 declares them as date-times; the server reads the type from the instance's $metadata rather than assuming one.

To point an install at 2026 R2: set ACUMATICA_ENDPOINT_VERSION to 26.200.001, rebuild the documentation index from the 2026 R2 docs and the schema index from your instance's own swagger.json, clear the cache, and optionally turn on ACUMATICA_GI_COUNT. The upgrade guide walks through each step. Because each worker serves one Acumatica instance, you can stand up a 2026 R2 worker next to your current one and try it before you upgrade.

No AI Studio license needed. Acumatica's own built-in MCP server, new in 2026 R2, is part of the AI Studio feature group, so it's only available if AI Studio is in your license. MCP4Acumatica uses the standard contract API and OData instead: it works on any license (counting against your normal Web Services API user limits), and its GI and column descriptions live in its own custom fields, which work without AI Studio too. The two can run side by side; we've posted a separate comparison.

One tip from our setup: the {tenant} in /t/{tenant}/... URLs is the tenant's Login Name on Tenants (SM203520), not its Tenant Name.

Parameterized Generic Inquiries

Why it used to refuse them

Query a parameterized GI over OData by its normal name and Acumatica runs it with no parameter values: you get either no rows or every row, with HTTP 200 and no error. A person would notice. An AI assistant won't; it will report plausible but wrong numbers. So MCP4Acumatica refused every parameterized GI, and teams ended up building "no parameters" copies of inquiries just to use them.

What changed in 0.56

Acumatica documents a second way in: each parameterized GI is also exposed as an OData function, {Name}_WithParameters(...), that takes the values. MCP4Acumatica now uses it, and checks the call before contacting Acumatica:

• Required parameters must have a value. A parameter is required exactly when Is Required is checked on the GI's Parameters tab ($metadata marks it Nullable="false").
• Unknown parameter names are refused. This matters: Acumatica silently ignores a misspelled parameter name and returns unfiltered rows, with no error.
• Values must fit the type: text, real calendar dates, booleans, numbers passed through exactly as written.
• No parameters argument at all is refused, with the list of parameters, so the assistant always sees them before it runs anything.
• Optional parameters left out take the GI's default (@QuarterStart, for example), and the response says which defaults applied, so the assistant can tell you.
• Every value is sent as an OData parameter alias, which also sidesteps ASP.NET request validation rejecting the : in date-time values when they're in the URL path.
• If the server can't read $metadata, it refuses the call instead of guessing that the GI has no parameters.

acumatica_describe_inquiry and acumatica_list_generic_inquiries now show each GI's parameters. An optional feed GI, MCPGIParams, adds parameter labels and default values so the assistant can say things like "this used the current quarter".

We verified the behavior on a 2025 R2 production tenant and a 2026 R2 sandbox. One release difference: 2025 R2 declares GI date parameters as date-times, 2026 R2 as dates; the server reads the type from $metadata and accepts a plain YYYY-MM-DD either way.

Turning it on

It's off by default. To enable it:

1. Set ACUMATICA_GI_PARAMETERS to "true" on your worker and redeploy (after one test call on your release, as the upgrade guide describes).
2. Re-import acumatica/MCPGIs.xml, which no longer filters out parameterized GIs, and optionally import acumatica/MCPGIParams.xml. Give the role that reads the feeds access to the new one.
3. Tag the parameterized GIs you want exposed. Before you do, check each one's Parameters tab: anything needed for correct results should be marked Is Required, and the defaults should be ones you'd accept being applied silently.

Heads-up: once you re-import MCPGIs, any parameterized GI that was already tagged for exposure becomes visible to the assistant, because the old feed ignored the tag on those.

Details: Generic Inquiries → Parameterized GIs and the changelog.

Also

• acumatica-claude-kit v0.2.7. Our Claude Code plugin of Acumatica integration gotchas picked up everything above about GI parameters over OData, plus new notes on OData v3 vs v4, row-level security silently shortening results, DAC-based OData, Auth Code and refresh-token handling, Acumatica's built-in 2026 R2 MCP server, and a new self-hosted install/upgrade section.

Questions, issues and PRs welcome.