EDI MCP Server

Connect agents to 167 source tools with scoped access, reviewed sends, explicit confirmation, and retained outcome uncertainty.

The source @stateset/edi-mcp package 0.2.1 exposes 167 tools over the EDI API. It supports local stdio and a stateless Streamable HTTP implementation. Local tools use the configured tenant/partner credential; API scopes, role, tenant, and readiness checks remain authoritative.

Build and connect

Use Node 20.19+ from the source checkout. Packaging tests do not establish npm publication; the supported example uses the in-repository build.

cd mcp
npm ci
npm run build

Configure your MCP host with a scoped key loaded through its secret configuration:

{
  "mcpServers": {
    "stateset-edi": {
      "command": "node",
      "args": ["/absolute/path/to/stateset-edi/mcp/dist/index.js"],
      "env": {
        "EDI_API_BASE": "https://api.edi.stateset.com",
        "EDI_API_TOKEN": "YOUR_SCOPED_TENANT_KEY"
      }
    }
  }
}

Choose the tool family

Need	Examples
Workspace and readiness	edi_workspace, edi_partner_readiness
Connected orders and exceptions	edi_operation_orders, edi_operation_order, edi_operation_exceptions
Reviewed 855/856/810	edi_preview_order, edi_send_reviewed_order
Direct outbound	Eleven X12 types including 753; EDIFACT INVOIC, DESADV, INVRPT
Transport observations	Deliveries/evidence, AS2 receipts, SFTP/FTPS jobs, hosted SFTP, Mail receipts
Integration	Sync outcomes, mapping revisions/transforms, callback deliveries/history
Recovery	Held auto-855 work, explicit retry/redelivery/reprocess, dead-letter actions
Operations	Reconciliation, evidence, deductions, audit, guide/qualification workflows

Discover the actual tool list in your connected build. The MCP surface and REST’s 202 documented operations are not one-to-one. Internal validation now covers configured X12 and EDIFACT types; a passing baseline does not automatically promote a partner.

Review mutations before invoking them

All fourteen direct outbound tools require a typed payload, partner_id, stable idempotency_key, and literal confirmation: "CONFIRM". Reviewed order sending additionally requires the original order_revision and frozen overrides from preview.

The host must show the target, scope, and actual action before supplying confirmation. The string and MCP annotations do not prove a person approved it. Do not manufacture readiness attestations, external acceptance, or permission to contact a counterparty. The synthetic order-to-invoice demo creates a new test partner; its retailer acceptance is simulated fixture evidence.

After a timeout or lost response, retain the key and exact payload. The server never retries mutations automatically. Errors retain status, code, and outcome_unknown where available; inspect the ledger before explicitly recovering the original request. See orders and recovery.

Runtime and hosted boundaries

Setting	Default / range
EDI_REQUEST_TIMEOUT_MS	30000; 250–120000
EDI_MAX_RESPONSE_BYTES	8 MiB; 1 KiB–32 MiB

Requests refuse redirects and bound response reads. The hosted implementation uses resource-specific StateSet WorkOS OAuth, live organization membership, and separate 60-second tenant credentials. It requires exact resource registration and gateway secrets; do not configure a platform API token on that service.

Hosted HTTP implementation/container tests do not establish public deployment, a signed-in customer flow, or real revocation. Use local stdio until those gates are independently verified. For terminal operation see CLI and SDK.