synapse_export_aegis_g2

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden and largely drops it. It does not say whether this is a read-only render or a write that appends to a transparency log, whether the export is idempotent, whether authentication or signing keys are required, or what the returned artifact looks like. 'Export canonical' weakly implies immutability/publication but never commits to it.

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?

It is a single front-loaded sentence with no filler, which is structurally sound. The compression comes at the cost of comprehension, though: noun-stacking ('canonical RFC 6962 G2_BUDGET_ROUTING attestation leaf') makes the one sentence harder to parse than a slightly longer plain-English version would be.

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?

With six undocumented optional parameters, no annotations, and no output schema, the description is the only source of information and it supplies almost nothing. An agent could not confidently decide what to pass, whether the call has side effects, or what it gets back.

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?

Six parameters exist with 0% schema description coverage, and the description explains none of them. The clause 'routing receipt or simulation parameters' faintly gestures at two input modes that might map to the receipt fields (task_id, model_id, cost_usd) versus the budget/simulation fields (budget_cap_usd, tokens_used), but no parameter is named, typed, or marked optional.

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?

The verb 'Export' and the resource 'attestation leaf' are specific, and the RFC 6962 / G2_BUDGET_ROUTING qualifiers distinguish it from siblings like synapse_rate_limit_status or route_agent_step. However, 'canonical RFC 6962 attestation leaf' is dense jargon with no plain-language gloss, so an agent cannot easily infer what artifact it actually produces or why it would want one.

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?

There is no when-to-use or when-not-to-use guidance, and no sibling is named as an alternative or a prerequisite. The phrase 'for a routing receipt or simulation parameters' hints at two input scenarios but does not tell the agent which conditions should trigger an export versus a call to check_budget_status or route_agent_step.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.