MCP server exposing Acumatica ERP (contract-based REST API) as tools for AI agents. Multi-instance, OAuth2.
Wellknown found it in public sources; nobody has proven control of it yet. Claiming takes one click if the repository is under your GitHub account, or a small file on your domain otherwise. Verified owners get the badge, 15-minute checks, status alerts, edits that outrank crawled data, and a ranking boost.
Agents can do it too: POST https://wellknown.network/api/v1/claims with {"agent":"grp-mcp-plugin","method":"well_known_file"} — machine-readable steps at claim.json, guide at /docs/claim.
Everything here was measured by our prober or read from a registry. Nothing is self-reported.
Attributed to the source that supplied each field. Treated as claims, not facts.
# grp-mcp MCP server that exposes **Acumatica ERP** as tools for AI agents. Multi-instance, OAuth2 — point it at any Acumatica site with a base URL + credentials. It reaches Acumatica through **five client planes**, so an agent can read and write almost anything: - **Contract-based REST** — CRUD entities, bulk-load from Excel/CSV, invoke actions, run reports, attach files, manage customization projects. - **DAC-based OData** — read tables/DACs that aren't on the endpoint, plus mandatory-field metadata (`run_dac_odata`, `get_dac_metadata`). - **Screen-based SOAP engine** — *drive screens the REST API can't*: context / master-detail / wizard screens (segment values, Enable Features, the financial calendar…). Discover (`list_screens`, `screen_get_schema`), read (`screen_get`), and write (`screen_submit`, with dry-run + per-field errors + dialog auto-answer) any screen by replaying its UI commands — no browser, no zeep. Higher-level writers (`screen_insert_rows` for master-detail/bulk grids, `screen_record` for idempotent create-or-edit) and ready-made setup recipes (`create_financial_calendar`, `create_ledger`, `chart_of_accounts`, `enable_features`, `manage_financial_periods`) sit on top. - **Modern UI-screen plane** — the JSON protocol the real browser UI uses (`/t/<Tenant>/ui/screen/<ScreenID>`), reusing the SAME login session as the classic plane (no extra auth, no browser). `ui_get_structure` reads a screen's full descriptor — views, fields, **enum allowed-values**, action inventory, grid keys — and `ui_screen_action` sets fields + fires actions (incl. dialog-confirm). This reaches what classic SOAP can't: actions whose classic tag is a silent no-op (e.g. GL201000 Generate Calendar), enum value discovery, live workflow-aware field/action state, and **full grid CRUD** — read, insert, update, and delete an *existing* grid row (the classic engine can only append rows; editing one in place silently corrupts data there — see be…
Mapped onto the structured taxonomy from declared text and observed tool names. Confidence shown for derived entries.
Every source is kept verbatim. Field changes are logged as events.