MCP server: convert between XML and JSON. Attribute-aware, CDATA-safe.
Two minimal tools with basic schemas and descriptions. Both tools have input schemas with proper types and required fields, but descriptions are terse (under 100 chars) and lack context on when/why to use them. No parameter descriptions provided, LLMs cannot infer what 'xml' or 'value' parameters control. No output schema documentation. Error handling is generic ('xml tool failed: ...'). Tools are simple converters but lack the depth expected of production tools.
Parse XML and return a JSON-compatible value. Attributes are prefixed with `@_`.
Serialize a JSON object back to XML. Keys starting with `@_` become attributes.
Parameter descriptions missing. 'xml' and 'value' parameters have no descriptions explaining format, constraints, or expected structure. LLMs cannot infer parameter meaning from names alone.
Output schema not documented. Tool descriptions do not specify what fields or structure the response contains. LLMs need explicit output documentation to plan downstream operations.
Tool descriptions are terse (under 100 chars) and lack context. No explanation of when to use to_json vs to_xml, what edge cases are handled (CDATA, namespaces, nested structures), or what the attribute prefix convention means.
Error messages are generic and non-actionable. 'xml tool failed: ...' does not guide the LLM on recovery. Should specify what constraint was violated and suggest next steps.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | 2026-07-28+ | v2 |
No input validation constraints documented. 'xml' parameter accepts any string but should document max length, encoding, or complexity limits. 'value' parameter requires an object but does not specify depth limits or forbidden keys.