mcp-edi

by MaestroMed

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a distinct purpose: parsing three different EDI standards, validation, segment explanation, and generation. No overlap or ambiguity.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with underscores: parse, validate, explain, generate. No mixing of conventions.
Tool Count5/5
Six tools cover the core EDI workflows (parse, validate, explain, generate) for the main standards without being excessive or sparse.
Completeness4/5
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.
Average 4.2/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 12 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
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 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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-edi MCP server](https://glama.ai/mcp/servers/MaestroMed/mcp-edi/badges/card.svg)](https://glama.ai/mcp/servers/MaestroMed/mcp-edi)

Score Badge

Copy to your README.md:

[![mcp-edi MCP server](https://glama.ai/mcp/servers/MaestroMed/mcp-edi/badges/score.svg)](https://glama.ai/mcp/servers/MaestroMed/mcp-edi)

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/MaestroMed/mcp-edi'

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