Skip to main content
Glama
Sign In
mcp-edi

mcp-edi

by MaestroMed
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Parse EDIFACT

parse_edifact

Parse UN/EDIFACT interchanges into structured JSON, decomposing segments and elements. Recognizes message types, verifies counters, and reports parsing issues.

Instructions

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "message": "<message>"
    },
    "name": "parse_edifact"
  }
}

Input Schema

NameRequiredDescriptionDefault
messageYesRaw EDIFACT interchange, e.g. UNA:+.? 'UNB+UNOA:4+...'

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
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.

Deploy Server

Other Tools