MCP4Acumatica (Open Source MCP Server) Update

For anyone new to the thread: MCP4Acumatica is an open-source (Apache-2.0) remote MCP server that connects Claude — and other MCP clients — to an Acumatica instance through the contract-based REST API and OData. It runs on Cloudflare Workers, each user logs in with their own Acumatica credentials (so their Acumatica role governs what the AI can access), sensitive fields are redacted, and every call is logged. It ships ~38 read-only entity lookups plus Generic Inquiry, schema-discovery, and utility tools. Repo: https://github.com/hallboys/MCP4Acumatica

Here's what's new since my last update (Previous thread).  Current Version 0.38.3

Generic Inquiry governance (the headline)

Exposing GIs to an AI assistant needs guardrails, so there's now an opt-in exposure gate

(Note: This feature Needs a Customization and Couple of GIs):

• You choose which GIs the AI can see. Tag a GI with a new Exposed to MCP checkbox; only tagged GIs are discoverable/queryable. Until you configure it, the assistant can't browse GIs at all — it can only run one you name explicitly. No more handing the model a menu of hundreds of screen-built inquiries. Note: You need to expose the GI to OData feed as well.
• AI descriptions + accurate field types. Add a short AI Description on a GI (and per output column) to help the assistant pick the right inquiry. Field types are read from OData $metadata, so money/qty columns don't get mislabeled as integers. Note: It appears that 26R1 and later will have the description fields out of the box.  For now these are Custom Columns.
• Drop-in customization. The repo bundles an Acumatica customization project (the GIDesign/GIResult custom fields + SM208000 form changes) and the helper GIs — import, publish, tag your GIs, done.
• ⚠️ Parameterized-GI safety — worth knowing even if you never touch this project: a Generic Inquiry with parameters, queried over OData/the contract API without supplying those parameters, returns default/unfiltered results with no error. A headless caller (AI or otherwise) can't tell the data is wrong. The server now detects and refuses parameterized GIs outright instead of returning misleading rows.

Schema-discovery tools for builders

New offline tools for devs building integrations/customizations: search entities by name or "which entities expose field X," pull a full entity schema (fields, types, actions, expandable sub-entities), and paste a GI definition XML to get a plain-English structural summary. These read an index built from your instance's own swagger.json, so they're always current and include your customizations.

Contract-REST / OData robustness (some Acumatica gotchas)

• substringof(...) eq true silently returns []. The contract-REST $filter parser returns an empty set (HTTP 200, no error) when a boolean string function is compared to a literal — so "contains" searches quietly returned nothing. The server now strips the trailing eq true. (PSA for anyone hitting the contract API directly.)
• Clear errors for non-filterable document entities. When a $filter can't be applied to a complex document entity (PurchaseOrder, Shipment, etc.), the API throws an opaque 500 — or worse, silently returns []. The server now returns an actionable error / false-negative warning and points you to a keyed lookup or a GI.

Other

• Custom Web Service Endpoint support — target a non-Default contract endpoint (SM207060) via one setting, with endpoint-aware "entity not exposed" messages.
• 26R1-readiness fix — the identity-lookup fallback now respects the configured endpoint version (was hardcoded to 25.200.001).
• Setup docs corrected (the Connected Application has no "scope" field — scopes are request-side) and the one-click Cloudflare deploy path smoothed out.

Feedback welcome — especially from anyone exposing GIs to AI/LLM tooling. Curious how others are handling the parameterized-GI-over-OData behavior.