This is an impressive contribution to the Acumatica ecosystem. The focus on security, governance, and usability addresses many of the concerns that come up when discussing AI integrations with ERP systems.

The opt-in GI exposure is particularly valuable. In most implementations, Generic Inquiries are created for a wide range of business and technical purposes, and exposing every GI to an AI assistant isn't practical or desirable. Requiring an explicit "Exposed to MCP" designation provides a sensible governance model while allowing administrators to control exactly what the AI can access.

I also appreciate the decision to block parameterized GIs. The OData behavior of returning unfiltered data when parameters are omitted is a subtle but significant risk. Detecting this condition and failing fast is a much safer approach than returning potentially misleading results.

The schema discovery capabilities are another standout feature. Having metadata generated directly from the instance's Swagger definition means developers can build integrations against the actual deployed endpoint, including customizations, rather than relying on static documentation.

Overall, this project demonstrates a strong understanding of Acumatica's REST API and OData nuances while implementing practical safeguards for enterprise AI adoption. Thanks for sharing the updates and continuing to evolve the project.

MCP4Acumatica 0.50 — curate your Generic Inquiries for AI, and the machinery that makes it safe

Since the 0.38.3 announcement, the biggest change in MCP4Acumatica is a complete pipeline for teaching the AI what your inquiries actually mean — plus the first write tool, and a much smarter error surface. MCP4Acumatica is the open-source MCP server connecting Claude (and other MCP clients) to Acumatica 2025 R2; each user signs in with their own Acumatica credentials, and their existing roles govern what they can see. Repo: https://github.com/hallboys/MCP4Acumatica

Headline: GI curation, end to end (0.48.x–0.49.x)

A GI's field names alone don't tell a model that a period column is fiscal-year-offset, that a status filters by stored code while displaying labels, or that an aging inquiry repeats each document per period. Now you can tell it — in Acumatica, on the GI itself:

• Per-column AI descriptions delivered to the model. Write text into the bundled custom fields (GIResult.UsrResAIDescription) and the server aligns it to real OData property names positionally. When an alignment can't be proven unique, the server refuses to annotate rather than risk attaching your text to the wrong column — a mis-shifted description is worse than none. (Refused GIs keep authoritative names and $metadata types; the documented fix is captioning the GI's key columns.)
• A bundled authoring skill. skills/acumatica-gi-descriptions/ is an Apache-2.0 Claude skill covering the full workflow against your instance: derive the column↔property mapping, live-sample to verify it, draft to a spec, validate coverage, write back via the API, and read-back verify. We curated our own deployment end-to-end with it — 1,400+ column descriptions across 100+ inquiries — and the skill is those lessons, packaged. No descriptions ship with the repo: your inquiries are yours, and curation is per-instance.
• Calculated columns can't silently break queries (0.49.0). A $filter on a calculated (=…) GI column makes Acumatica return HTTP 200 with an empty body — no error at all. The registry flags expression columns, describe_inquiry marks them calculated: true, and run_inquiry refuses such filters before contacting Acumatica, listing the stored columns to use instead. This was the single largest error class in our production logs (~14% of tool errors), and the guard works with zero curation beyond tagging.
• Imported the feed GIs before 0.48.0? Re-import acumatica/MCPGIFields.xml — description delivery needs its new SortOrder/IsActive columns.

Exploring next: a community description pack for the stock GIs (genericized, name-keyed). If that would be useful to you, tell me.

First write tool, safely (0.40.0) — community contribution 🎉

Big thanks to @VarunDasharadhi for contributing the write-tool infrastructure and the first write tool, acumatica_create_or_update_customer. Writes are layered in guardrails: a deploy-time kill-switch and runtime admin toggle, a mandatory dry-run/confirm handshake, strict field allowlists, and a durable mutation audit trail. The registry design means the next write entity is a single entry.

The model gets corrections, not just errors (0.44.0–0.46.0)

Production log analysis showed ~41% of tool errors were OData dialect mistakes — the contract API is v3, the GI endpoint is v4, and models carried syntax across. Filter rejections now return structured corrections (the right function, the real field names, correct date literals) with an explicit "the query never executed," so a syntax error is never reported as "no records found." Empty/non-JSON bodies get the same treatment, and write-path anomalies explicitly warn against retries that could duplicate auto-numbered records.

Reliability and operations

• Concurrent-session response crossing fixed (0.50.0) via the agents SDK 0.21.0 upgrade — under heavy parallel use, a response could rarely reach the wrong in-flight request. Strongly recommended if you run simultaneous sessions.
• Configurable rate limiting (0.41.0) — per-user concurrency and per-minute caps, runtime-tunable, with structured throttle envelopes so a rate limit never reads as an ERP outage.
• Authenticated preflight (0.43.0–0.45.0) — diagnostics that actually verify tenant and endpoint version (Acumatica 401s every unauthenticated path, even nonexistent ones, so token-less checks can't).
• Login gate simplified (0.39.0) — the canary GI is configurable (ACUMATICA_CANARY_GI); a marker role remains the recommended restriction pattern.

Upgrading

git pull && npx wrangler deploy (or redeploy your fork). No breaking configuration changes. Full per-release detail: /docs/changelog on your deployment. Issues and PRs welcome.