How do I use edi-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@edi-mcp summarize the 850 purchase order in samples/850-purchase-order.edi" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

edi-mcp

by heocoi

Overview Schema Related Servers Score Discussions

TypeScript

edi-mcp

Let AI agents read, validate and acknowledge EDI documents.

An MCP (Model Context Protocol) server that parses raw X12 and EDIFACT interchanges into structured JSON, validates envelope integrity, produces plain-language summaries, and generates 997 Functional Acknowledgments. Zero runtime dependencies beyond the MCP SDK - the tokenizer is hand-rolled and reads delimiters from the wire, the way real-world files demand.

Works with Claude (Desktop, Code, API), Cursor, and any MCP-compatible client.

Why

EDI predates JSON by decades and still moves most B2B commerce: purchase orders (850/ORDERS), invoices (810/INVOIC), ship notices (856). None of it is reachable by no-code AI connectors - there is no REST API to point Zapier at, just structured text flowing over AS2/SFTP. This server gives an AI agent eyes on that traffic:

"Summarize the PO that just landed in the inbox folder"
"Does this 810 match the PO number and line totals we sent?"
"Draft the 997 acknowledgment for this interchange"

Related MCP server: eleata e-invoice MCP server

Tools

Tool	What it does
`parse_edi`	Raw X12/EDIFACT (auto-detected) → structured JSON: envelope, groups, transactions, segments
`validate_edi`	Envelope integrity: control number agreement (ISA/IEA, GS/GE, ST/SE, UNB/UNZ, UNH/UNT) + declared counts
`summarize_edi`	Plain-language business summary. Deep support: X12 850/810/856, EDIFACT ORDERS/INVOIC. Other types get a segment inventory
`generate_997_ack`	X12 997 Functional Acknowledgment answering an interchange, sender/receiver swapped, AK2/AK5 per transaction

Quick start

git clone https://github.com/heocoi/edi-mcp.git
cd edi-mcp
npm install && npm run build

Claude Code:

claude mcp add edi -- node /path/to/edi-mcp/dist/index.js

Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "edi": {
      "command": "node",
      "args": ["/path/to/edi-mcp/dist/index.js"]
    }
  }
}

Then try: "Parse samples/850-purchase-order.edi and tell me the PO number, ship-to address and order value."

Example

Input (X12 850, abbreviated):

ISA*00*...*ZZ*ACMECORP*ZZ*WIDGETSUPPLY*260719*1030*U*00401*000000101*0*P*>~
GS*PO*ACMECORP*WIDGETSUPPLY*20260719*1030*101*X*004010~
ST*850*0001~
BEG*00*SA*PO-2026-4521**20260719~
PO1*1*48*EA*9.75**VP*WS-4417*UP*012345678905~
...

summarize_edi output:

X12 interchange 000000101 - ACMECORP → WIDGETSUPPLY, dated 2026-07-19

## 850 Purchase Order (control 0001)
- Purchase Order PO-2026-4521 dated 2026-07-19 (type SA)
- Ship-to: Acme Corp Warehouse 7
- Line 1: 48 EA @ 9.75 - VP WS-4417, UP 012345678905
- Line 2: 12 CS @ 142.00 - VP WS-9902
- Computed order value: 2172.00
- CTT declares 2 line item(s)

Design notes

Delimiters come from the wire, not from config. X12 delimiters are read from the ISA segment itself; EDIFACT service characters from UNA when present, standard defaults otherwise. EDIFACT release-character escaping (?+ → literal +) is honored.
Lenient parse, strict validate. parse_edi recovers what it can and reports anomalies as warnings; validate_edi is the strict pass. Real-world EDI is messy - a parser that throws on the first oddity is useless for triage.
Acknowledgment policy is explicit. decideAckStatus() in src/ack997.ts maps validation results to A/E/R. Default: clean → A, structural errors → R. Trading partner agreements differ; the policy is one small function on purpose.

Scope and roadmap

Current scope is read/triage/acknowledge - the 80% of daily EDI pain that needs no certification. Not yet included: 999 Implementation Acknowledgment, transaction-set-level schema validation (dictionaries per version), generating outbound 810/856, AS2 transport. Tracking the MCP 2026-07-28 spec revision.

Custom integrations

I build custom MCP servers for systems that no off-the-shelf connector covers: legacy ERPs, proprietary internal tools, SOAP/EDI/flat-file pipelines. If your business runs on a system your AI tools can't see, reach out: anhphong.pham@gmail.com · anhphong.dev

License

MIT

Available Tools

4 tools

generate_997_ackGenerate 997 Functional AcknowledgmentA

Build an X12 997 Functional Acknowledgment answering the given X12 interchange (sender/receiver swapped, one AK2/AK5 pair per transaction). The ack status follows envelope validation: clean file → A, structural errors → R.

ParametersJSON Schema

Name	Required	Description	Default
`content`	Yes	Raw EDI document text: an X12 interchange (ISA...IEA) or EDIFACT interchange (UNA/UNB...UNZ)
`ack_control_number`	No	Interchange control number to stamp on the acknowledgment (default 1001)

TDQS

A3.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Given no annotations, the description reveals key behaviors: sender/receiver swapping, one AK2/AK5 pair per transaction, and ack status based on envelope validation (clean → A, errors → R). This is beyond a basic description, but could also mention output format or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no extraneous words. Front-loaded with the core action, followed by a clarifying detail. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers the essential aspects: purpose, swapping, transaction structure, and status logic. Lacks explicit mention of output format (likely the 997 string), but context is sufficient for a tool with no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema coverage, the description does not add value beyond the schema. The 'content' parameter is implied to be the incoming interchange, and 'ack_control_number' default is mentioned in schema. Baseline score is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it builds an X12 997 Functional Acknowledgment from an interchange, specifying sender/receiver swapping and AK2/AK5 pairs. However, it does not explicitly differentiate from sibling tools like validate_edi, though the distinct purpose is evident.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives, such as when validation is needed or when parsing alone suffices. The description implies usage after receiving an interchange but does not state prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

parse_ediParse EDI to JSONA

Parse a raw X12 or EDIFACT document (auto-detected) into structured JSON: envelope metadata, functional groups, transactions and their segments. Use this when you need to read individual fields.

ParametersJSON Schema

Name	Required	Description	Default
`content`	Yes	Raw EDI document text: an X12 interchange (ISA...IEA) or EDIFACT interchange (UNA/UNB...UNZ)

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears the full burden. It explains the parsing behavior and auto-detection but omits critical details like side effects, authentication needs, error handling, or what happens with invalid input, which are important for an AI agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no extraneous words. It front-loads the primary action and output structure, making it easy for an AI agent to quickly grasp the purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parsing tool with one parameter and no output schema, the description covers the input format, auto-detection, and output structure adequately. It lacks details on edge cases or error behaviors but is sufficient for common usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers 100% of the single parameter 'content' with a description. The tool's description largely echoes this schema description, adding minimal extra meaning. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'parse', the resource 'EDI document', and the outcome 'structured JSON' with details on components (envelope, groups, transactions). It also notes auto-detection between X12 and EDIFACT, making the purpose specific and distinct from sibling tools like validate_edi.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes 'Use this when you need to read individual fields', which implies a usage context. However, it does not explicitly state when not to use it or mention alternative tools, leaving room for interpretation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

summarize_ediSummarize EDI in plain languageA

Produce a human-readable business summary of an EDI document. Understands X12 850/810/856/997 and EDIFACT ORDERS/INVOIC in detail; other transaction types get a segment inventory.

ParametersJSON Schema

Name	Required	Description	Default
`content`	Yes	Raw EDI document text: an X12 interchange (ISA...IEA) or EDIFACT interchange (UNA/UNB...UNZ)

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must convey behavioral traits. It discloses how different transaction types are handled (detailed vs. segment inventory). However, it omits the output format (e.g., plain text vs. structured), error handling, or any side effects. The absence of output schema further limits transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no wasted words. The first sentence states the core purpose, and the second adds detailed behavior for specific types. It is front-loaded and concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema, the description should explain return values. It mentions 'human-readable business summary' and 'segment inventory' but does not specify format, clarity, or handling of invalid inputs. This lack of detail limits completeness for an agent to fully understand the tool's outputs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage for the single parameter 'content', describing it as raw EDI document text. The description adds no additional semantic value beyond what the schema already provides. Therefore, a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool produces a human-readable business summary of an EDI document, listing specific supported types (X12 850/810/856/997, EDIFACT ORDERS/INVOIC) and a fallback segment inventory for others. This distinguishes it from siblings like parse_edi and validate_edi.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for obtaining a plain-language summary, and the fallback behavior hints at limitations. However, it does not explicitly contrast with siblings or state when to avoid using it. The sibling names provide some context, but the description lacks explicit guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

validate_ediValidate EDI envelopesA

Check structural integrity of an X12 or EDIFACT document: control number agreement (ISA/IEA, GS/GE, ST/SE, UNB/UNZ, UNH/UNT) and declared segment/transaction counts. Returns errors and warnings.

ParametersJSON Schema

Name	Required	Description	Default
`content`	Yes	Raw EDI document text: an X12 interchange (ISA...IEA) or EDIFACT interchange (UNA/UNB...UNZ)

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It mentions returning errors and warnings, but does not disclose other behavioral traits (e.g., read-only, auth needs, side effects). Adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first states the specific validation checks, second describes output. No wasted words, front-loaded with purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter validation tool, the description explains what is checked and what is returned. No output schema but description covers return type. Could mention that it does not parse into structured data, but still fairly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a descriptive parameter comment. The tool description adds purpose but no additional parameter-specific detail beyond the schema, so baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool validates structural integrity of X12 or EDIFACT documents, listing specific checks (control number agreement, segment/transaction counts). This distinguishes it from siblings like 'parse_edi' (parsing) and 'summarize_edi' (summarization).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for validation before parsing/summarizing, but does not explicitly state when to use this tool versus alternatives or provide exclusions. Lacks clear usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

4 tool updatesv0.1.0Jul 26, 2026
- First observedgenerate_997_ack
- First observedparse_edi
- First observedsummarize_edi
- First observedvalidate_edi

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation5/5

Each tool has a distinct purpose: parse converts raw EDI to structured JSON, validate checks structural integrity, summarize produces a business summary, and generate_997_ack creates an acknowledgment. There is no overlap.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (parse_edi, validate_edi, summarize_edi, generate_997_ack), making them predictable and easy to navigate.

Tool Count4/5

With 4 tools covering parsing, validation, summarization, and acknowledgment generation, the count is appropriate for a focused EDI utility. It could be expanded slightly for more advanced operations, but it's well-scoped.

Completeness3/5

The set covers key operations (read, validate, summarize, respond) but lacks tools for editing, converting, or batch processing EDI documents. This leaves notable gaps for complex workflows.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Document to JSON – PDF Invoice/Statement/Contract ParserOAuth
io.github.fashionmascherine-svg
Turn any PDF into structured JSON via AI + OCR: invoices, bank statements, contracts.
Finance AI & Machine Learning
28
invoicehub A
dev.invoicehub
Validate, generate & convert EU e-invoices (UBL, CII, XRechnung, Factur-X) — EN 16931 pre-validated.
Finance Legal & Compliance
42
facturx-toolkit
io.github.CedricKouma
Validate, extract, repair and generate French Factur-X / EN16931 invoices via AgentForge API
Payments & Billing Finance
2
ParselOAuth
io.github.ahutto87
Parse logistics PDFs (Bills of Lading, customs declarations, invoices) into DCSA JSON.
App Automation Documentation Access
2

Related MCP Servers

MCP Mortgage Server
Finance Legal & Compliance
confersolutions
A
license
Not graded
quality
D
maintenance
Enables AI assistants to parse and analyze mortgage documents (Loan Estimates & Closing Disclosures), converting them into structured MISMO-compliant JSON and checking for TRID compliance violations.
Updated 2 months ago (2026-06-29 16:23 UTC)
2
MIT
eleata e-invoice MCP server
Legal & Compliance Finance
hernaninverso
A
license
A
quality
B
maintenance
Validates EU electronic invoices (Peppol, XRechnung, FatturaPA, etc.) and explains validation error codes, enabling AI coding agents to check invoice validity and get fixes before rejection.
Updated 2 months ago (2026-06-30 15:36 UTC)
3
53
MIT
SignalEDI MCP Serverofficial
Finance Data Platforms Payments & Billing
SignalEDI
A
license
A
quality
A
maintenance
Enables AI assistants to parse, validate, send, and inspect X12 EDI documents via the SignalEDI Core API, with optional QuickBooks integration and a demo mode for keyless local testing.
Updated 21 days ago (2026-08-17 09:03 UTC)
18
88
MIT
ETL-D MCP Server
Data Platforms Finance
pablixnieto2
A
license
C
quality
D
maintenance
Provides deterministic data parsing and enrichment for AI agents, including bank statements, trade history, EDI, PDFs to structured markdown, and atomic enrichment for amounts, dates, and addresses, with strict schema enforcement to prevent hallucinations.
Updated 5 months ago (2026-03-26 21:42 UTC)
37
35
2
ISC

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/heocoi/edi-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

edi-mcp

Why

Tools

Quick start

Example

Design notes

Scope and roadmap

Custom integrations

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

SignalEDI MCP Serverofficial

Latest Blog Posts

MCP directory API