Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-edi parse this X12 850 purchase order"
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 meets AI agents: give Claude the ability to read, validate and write EDIFACT, ANSI X12 and cXML.
An MCP server that turns 40 years of B2B message formats into something an AI agent can work with natively — built by an EDI consultant with 20 years of EDIFACT/X12/cXML integrations behind him.
The parsers are written by hand — no EDI library, no XML dependency. Tokenizing UNA service strings, deducing X12 delimiters from the ISA header, verifying UNT/SE/GE/UNZ/IEA control counters: that is the point. The only runtime dependencies are the official MCP SDK and zod.
git clone https://github.com/MaestroMed/mcp-edi.git
cd mcp-edi
npm install && npm run buildAdd to claude_desktop_config.json (or .mcp.json for Claude Code):
{
"mcpServers": {
"edi": {
"command": "node",
"args": ["/absolute/path/to/mcp-edi/dist/server.js"]
}
}
}Restart the client — six EDI tools appear.
Related MCP server: encoding-devops
Tool | What it does |
| Raw UN/EDIFACT → structured JSON. UNA-aware (custom separators, release character), UNB/UNZ + UNH/UNT envelopes, type recognition (ORDERS, DESADV, INVOIC, ORDRSP...), UNT/UNZ counter checks. |
| Raw ANSI X12 → structured JSON. Delimiters deduced from the ISA itself, ISA/GS/ST hierarchy, type recognition (850, 856, 810, 997...), SE/GE/IEA counter and control-number checks. |
| cXML e-procurement → JSON: PunchOutSetupRequest/Response and OrderRequest, From/To/Sender credentials, items and amounts. SharedSecret values are detected but never echoed. |
| Auto-detects the standard, verifies envelope structure, mandatory segments per message type, and every counter. Returns actionable errors/warnings: segment, position, expected, found. |
| Built-in dictionary — 35 EDIFACT + 28 X12 segments. |
| Simple JSON (parties, dates, line items) → valid EDIFACT ORDERS D.96A interchange with correct envelopes, escaping and counters. Round-trips through |
You: Our supplier says our order file is broken. Here it is: (pastes EDIFACT)
Claude (calls
validate_message): The interchange is invalid — two problems:
UNTdeclares 18 segments but the message contains 20 (UNT_COUNT_MISMATCH, position 21). Your mapper is not counting the twoPRIsegments added last week.
UNZcontrol referenceICR0002does not matchUNBreferenceICR0001— the envelope was rebuilt from a stale template.You: Fix the counters and show me what line 2 orders.
Claude (calls
parse_edifact): Line 2 orders 24 PCE of EAN8718123400022("Industrial widget size L") at 15.75 EUR net.
EDI is not legacy — it is the installed base of world trade. Every retailer, carrier and marketplace still speaks EDIFACT or X12, and every e-procurement platform speaks cXML. What is changing is who reads these messages: agents are starting to negotiate, order and invoice on behalf of companies.
Agent-to-agent commerce will not replace the EDI rails; it will drive them. The missing piece is a translation layer the agent can trust — deterministic parsing, real envelope validation, counters checked, nothing hallucinated. That layer is what this server provides: the LLM does the reasoning, the parsers do the arithmetic.
npm test # vitest — 81 tests: nominal, custom UNA separators, truncated
# messages, wrong counters, generate→parse round-trips
npm run build # tsc, strict mode
npm run smoke # spawns the compiled server, runs the MCP handshake on stdio,
# checks tools/list and a live tools/callsamples/ contains six anonymized messages (ACME Corp / Globex — fictional data only): ORDERS, DESADV, INVOIC, 850, 856, PunchOutSetupRequest. Every sample validates clean; the test suite enforces it.
AS2 headers inspector — MDN, MIC and disposition debugging for transport-level issues
Peppol UBL — parse and validate BIS 3.0 invoices/orders
SAP IDoc — ORDERS05/DESADV parsing from flat-file IDocs
MIT — Mehdi Nafaa
Explain an EDI segment tag in plain English: role, key elements and a realistic example. Covers 35 EDIFACT segments (UNB, BGM, DTM, NAD, LIN, QTY...) and 28 X12 segments (ISA, ST, BEG, N1, PO1, HL...). Tags that exist in both standards (DTM, LIN) return both entries unless a standard is specified.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | Yes | Segment tag, e.g. UNB, BGM, NAD, ISA, PO1 | |
| standard | No | Restrict lookup to one standard |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses coverage (35 EDIFACT, 28 X12 segments) and behavior for tags in both standards (returns both unless standard specified). With no annotations, the description carries the full burden and does well, though error handling for unknown tags is not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Key information (purpose, coverage, examples, dual-standard handling) is efficiently presented and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple explanation tool, the description covers purpose, supported segments, and standard handling. The output is described vaguely ('role, key elements, example'), but lacking a formal output schema, this is acceptable. No mention of error handling or performance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by listing example tags and clarifying the standard parameter's effect on ambiguous tags. This goes beyond the schema's simple type descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool explains an EDI segment tag in plain English, covering role, key elements, and a realistic example. It specifies the exact standards (EDIFACT and X12) and provides concrete segment examples, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 siblings like parse_edifact or validate_message. The description implies usage for understanding individual segments but does not mention when to choose explain_segment over other tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a syntactically valid EDIFACT ORDERS D.96A interchange (UNA + UNB...UNZ) from a simple JSON order description: parties, dates, currency and line items. Envelopes, escaping and UNT/UNZ counters are computed automatically; the output round-trips through parse_edifact with zero issues.
| Name | Required | Description | Default |
|---|---|---|---|
| buyer | No | Buyer party (NAD+BY), id is typically a GLN | |
| items | Yes | Order lines (LIN groups) | |
| sender | Yes | Interchange sender (UNB) | |
| currency | No | ISO 4217 currency code (CUX), e.g. EUR | |
| freeText | No | Header free text (FTX+AAI) | |
| supplier | No | Supplier party (NAD+SU) | |
| orderDate | Yes | Order date, "YYYYMMDD" or "YYYY-MM-DD" (DTM+137) | |
| recipient | Yes | Interchange recipient (UNB) | |
| messageRef | No | Message reference number (UNH/UNT), default 1 | |
| orderNumber | Yes | Purchase order number (BGM) | |
| deliveryDate | No | Requested delivery date (DTM+2) | |
| deliveryParty | No | Delivery party (NAD+DP) | |
| interchangeRef | No | Interchange control reference (UNB/UNZ), default 1 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behaviors. It mentions automatic computation of envelopes, escaping, and counters, and asserts zero-issue round-tripping. It does not address authentication, rate limits, or potential failure modes, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the core purpose and key behavioral traits. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 parameters, nested objects) and lack of output schema, the description provides essential context about the output (EDIFACT interchange, round-trip quality) but omits details like return type format, error handling, or performance characteristics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter documented. The tool description adds value by mapping parameters to EDIFACT segments (e.g., NAD+BY, DTM+137) and summarizing the structure, which goes beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a syntactically valid EDIFACT ORDERS D.96A interchange from a simple JSON order description. It specifies the resource (EDIFACT ORDERS D.96A format) and the action (generate), distinguishing it from siblings like parse_edifact, which parse EDIFACT.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a JSON order description and need EDIFACT output, and mentions round-trip compatibility with parse_edifact. However, it does not explicitly state when to use this tool versus siblings, nor provides when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse a cXML e-procurement document (PunchOutSetupRequest, PunchOutSetupResponse, OrderRequest) into structured JSON: From/To/Sender credentials, punchout session data, order header with totals and addresses, and line items with quantities and prices. SharedSecret values are detected but never echoed.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | cXML document (XML text) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It provides a key behavioral detail: 'SharedSecret values are detected but never echoed,' disclosing a security-sensitive trait. However, it doesn't mention error handling, rate limits, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first lists the main output components, the second adds a critical transparency note about SharedSecret. Every sentence earns its place; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter, no output schema, and no annotations, the description covers purpose, input, output structure, and a security behavior. It is fairly complete for a simple parsing tool, though it lacks details on optional fields or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with a single 'message' parameter described as 'cXML document (XML text)'. The description adds significant meaning by listing specific document types and the structured output fields (e.g., From/To/Sender credentials, order header), which goes beyond the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool parses cXML e-procurement documents into structured JSON. It lists specific document types (PunchOutSetupRequest, PunchOutSetupResponse, OrderRequest) and the output fields (credentials, session data, order header, line items), distinguishing it from siblings like parse_edifact and parse_x12 which handle different formats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly tells when to use this tool: when you have a cXML document. It doesn't explicitly say when not to use or mention alternatives, but the tool name and context from sibling tools (e.g., parse_edifact, parse_x12) make the usage domain clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse a raw UN/EDIFACT interchange into structured JSON: UNA-declared separators, UNB/UNZ envelope, one entry per UNH/UNT message with decomposed segments (composite and simple elements), message type recognition (ORDERS, DESADV, INVOIC, ORDRSP...) and UNT/UNZ counter verification. Returns issues with segment, position, expected and found values.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | Raw EDIFACT interchange, e.g. UNA:+.? 'UNB+UNOA:4+...' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It details key behaviors: parsing, counter verification, and returning issues with segment/position/values. It does not mention destructive actions; parsing is inherently read-only. Could add more on error handling or limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with key information. It efficiently covers input processing and output details. Could be slightly more structured (e.g., bullet points) but is clear and non-redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and one parameter, the description provides adequate context: explains what gets parsed, how messages are handled, and what is returned. Lacks mention of limitations like version support or file size, but sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter with a brief example. The description adds significant context about expected input structure (UNA separators, envelope format, message types), enhancing the schema's meaning. Baseline 3, raised due to added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool parses raw UN/EDIFACT into structured JSON, listing specific components (UNA, UNB/UNZ, UNH/UNT) and message types. It distinguishes from sibling parsers like parse_x12 and parse_cxml by specifying the EDIFACT format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for EDIFACT data but does not explicitly state when to use it over alternatives (e.g., parse_x12 for X12). No when-not or exclusion criteria are provided, though sibling names suggest context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse a raw ANSI X12 interchange into structured JSON. Delimiters are deduced from the ISA segment itself (element separator = 4th character, component separator = ISA16, segment terminator = the character after ISA16). Returns the ISA/GS/ST hierarchy with decomposed segments, transaction type recognition (850, 856, 810, 997...) and SE/GE/IEA counter and control-number verification.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | Raw X12 interchange starting with ISA |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It discloses delimiter deduction logic (element separator, component separator, segment terminator), return structure (ISA/GS/ST hierarchy, decomposed segments), transaction type recognition, and counter/control-number verification. It does not mention error handling or size limits, but coverage is good.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states the main purpose, second provides key behavioral details. No fluff. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex (parses structured EDI), has no output schema, and one parameter. The description covers return hierarchy, segment decomposition, transaction type recognition, and verification. This is complete for the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one required parameter 'message' described as 'Raw X12 interchange starting with ISA'. The description adds no additional parameter-level semantics beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Parse', 'deduced', 'Returns') and names the resource ('raw ANSI X12 interchange', 'structured JSON'). It distinguishes from siblings like parse_edifact and parse_cxml by explicitly stating it handles X12 format and mentions specific transaction types (850, 856, 810, 997...).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the tool is for parsing X12 interchanges, and siblings handle other formats (EDIFACT, cXML) or other operations (validate, explain, generate). It does not explicitly state when not to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect the EDI standard (EDIFACT, X12 or cXML), verify the envelope structure, the mandatory segments for the recognized message type, and all control counters. Returns an actionable list of errors and warnings — each with segment, position, expected and found — plus a one-line summary.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | Raw EDI content in any supported standard |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully discloses behavior: detects standard, verifies structure, returns actionable errors/warnings with details. Does not mention auth, rate limits, or destructive actions, but these are not expected for a read-only validation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff, efficiently conveys purpose, process, and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description sufficiently explains return structure (list of errors/warnings with segment, position, expected/found, plus summary). Complexity of validating multiple standards is addressed. Sibling tools are only parsers/generators, so no missing overlap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter described as 'Raw EDI content'. Description adds context of what the tool does but does not expand on parameter format, encoding, or size limits. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool detects EDI standard (EDIFACT, X12, cXML), verifies envelope structure, mandatory segments, and control counters. Differentiates from sibling parsing tools by being a general validator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies validation use case but lacks explicit when-to-use versus siblings like parse_edifact, parse_x12, or explain_segment. No exclusions or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0explain_segmentgenerate_edifactparse_cxmlparse_edifactparse_x12validate_messageEach tool has a distinct purpose: parsing three different EDI standards, validation, segment explanation, and generation. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern with underscores: parse, validate, explain, generate. No mixing of conventions.
Six tools cover the core EDI workflows (parse, validate, explain, generate) for the main standards without being excessive or sparse.
Covers parsing for EDIFACT, X12, and cXML, validation across all, explanation, and generation for EDIFACT. Missing generation for X12 and cXML is a minor gap.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Hosted Amazon Seller and Vendor MCP server for Claude, ChatGPT, Cursor, Codex, Gemini, Copilot.
Cloud-hosted MCP server for secure AI access to enterprise data sources via CData Connect AI.
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/MaestroMed/mcp-edi'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
