Loading ToolBench
MCP server that lets AI agents parse, validate, summarize and acknowledge EDI documents (X12 & EDIFACT). Zero-dependency parser, works with Claude, Cursor and any MCP client.
Four tools with clear, domain-specific descriptions (avg 180 chars, within baseline 194). All have input schemas with type constraints. However, parameter descriptions are minimal (content param reused across all tools with single description), and output schemas are undocumented. No error recovery guidance, no tool annotations, and no composition hints for multi-step workflows. Naming is verb-forward (parse_, validate_, summarize_, generate_) and appropriate for EDI domain. Risk classification (READ_ONLY) present but not leveraged in descriptions.
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.
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.
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.
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.
Output schemas undocumented. All tools return JSON text wrapped in {content: [{type: 'text', text: ...}]} but LLMs cannot infer structure of the JSON payload itself (parse_edi returns parsed envelope/groups/transactions; validate_edi returns errors/warnings; summarize_edi returns prose; generate_997_ack returns X12 text). Without documented output schemas, agents cannot plan downstream tool calls or extract specific fields.
Parameter descriptions are generic and reused. The 'content' parameter appears in all four tools with identical description. No guidance on when to use parse_edi vs validate_edi vs summarize_edi, LLMs must infer from tool names alone. Missing composition hints like 'Call parse_edi first to extract fields, then validate_edi to check integrity.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
Error handling returns raw error messages without recovery guidance. fail() function returns 'Error: {message}' with isError=true, but does not categorize errors (retryable vs user-fixable vs fatal) or suggest next steps. E.g., 'Invalid X12 envelope' gives no hint to call parse_edi first or check document format.
No tool annotations. Tools lack readOnlyHint, destructiveHint, or idempotentHint metadata. All four are marked Risk: READ_ONLY in the spec but this is not reflected in tool definitions. generate_997_ack modifies state (generates new document) but is not annotated as such.
generate_997_ack optional parameter 'ack_control_number' lacks validation guidance in description. Pattern is '^\d{1,9}$' but description only says 'default 1001', does not explain format, range, or why it matters. LLMs may pass invalid values.