MCP server for transformer.bee that provides tools to convert between EDIFACT and BO4E formats
TransformerBee.mcp has two tools with reasonable names but critical gaps in parameter descriptions and output schema documentation. Tool names follow verb_noun pattern appropriately ('convert_*'). However, parameter descriptions are minimal and lack actionable detail. Input schemas reference custom types (EdifactFormatVersion, BOneyComb) without inline documentation of their structure or valid values. No output schema is documented, forcing LLMs to reason about what the conversion tools return. Error handling and input validation guidance are absent from the descriptions. The server is STDIO-only, which caps protocol readiness at 50. Overall definition quality reflects these significant gaps in schema completeness and parameter guidance.
Convert a BO4E transaktion to its EDIFACT equivalent
Convert an EDIFACT message to its BO4E equivalent
Parameter descriptions lack actionable detail and constraints. 'edifact' parameter has a one-line description but no guidance on valid format, length, structure, or error cases. 'transaktion' parameter references BOneyComb type without explaining what fields it contains or how to construct it.
No output schema documented. LLMs cannot reason about what fields the conversion tools return, forcing them to guess the structure and retry on parsing errors. The tools return some response but that response structure is invisible in the MCP definition.
EdifactFormatVersion and BOneyComb are custom types referenced in schemas but never defined in the tool registration. LLMs cannot determine what values are valid for 'edifact_format_version' or how to construct a 'transaktion' object. These types should be either inlined with their structure or documented with clear examples.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Tool descriptions are minimal (both under 80 characters). Rubric baseline for good descriptions is 194 chars (p10=34, p90=392). Current descriptions answer 'what does it do' but lack 'when to use it' and 'what does it return' guidance. LLMs cannot distinguish between these tools or understand their return values.
No error handling guidance. Descriptions do not explain what happens if an EDIFACT message is malformed, what happens if a BO4E transaction is incomplete, or how the LLM should recover from conversion failures. Pattern requires 'Error responses must tell the LLM what to do next'.
STDIO transport only. This server cannot be used by hosted/remote MCP clients. All STDIO servers are capped at protocol readiness score 50 and cannot be rated higher than D-tier for production readiness.