Encode JSON into base64 XDR for any Stellar type using the type's JSON schema, enabling roundtrip with decode and schema tools.
Encode JSON into base64 XDR for a named type (roundtrip with stellar_xdr_json_schema + decode tools).
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Stellar XDR type name (see stellar_xdr_types), e.g. TransactionEnvelope | |
| json | Yes |
Changes observed during successful MCP inspections.
v0.1.9Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses the input format (JSON), output format (base64 XDR), and the schema relationship, which covers the core behavior of a stateless pure transformation. However, it does not disclose failure modes (invalid type name, JSON failing schema validation) or whether validation is enforced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence front-loads the operation and output format, with the roundtrip context cleanly tucked into a parenthetical. Every word earns its place; no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-param tool with no output schema and no annotations, the description covers the operation, output format, and companion pipeline tools. Missing are explicit error semantics and a direct pointer that type must come from stellar_xdr_types (though the schema's type description covers this). The inverse tool is only implied as 'decode tools' rather than named.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (borderline), but the schema itself already provides solid descriptions for both parameters — json documents its string/object variants and JSON.stringify serialization, and type points to stellar_xdr_types with an example. The description adds little beyond echoing 'named type' and 'JSON', so it doesn't compensate for the coverage gap, yet the schema carries that weight adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Encode'), the exact transformation (JSON → base64 XDR), and the type-driven mechanism ('for a named type'). The roundtrip reference to decode tools distinguishes it from the sibling stellar_decode_xdr without requiring schema inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The roundtrip mention ('roundtrip with stellar_xdr_json_schema + decode tools') implies a pipeline workflow, but the description never explicitly says when to choose this tool over stellar_decode_xdr or whether the JSON must first be prepared via stellar_xdr_json_schema. No explicit conditions or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.