crypto_exit_checkCompare BTC sell sizes across rungs/brackets to estimate venue exit capacity, excluding stale, future, uncovered, or unconverted venues; fees excluded.
Compare four BTC sell sizes by rung/bracket. Withholds stale/future, uncovered or unconverted venues. Fees excluded; no trade clearance.
| Name | Required | Description | Default |
|---|---|---|---|
| sizes_usd | No | ||
| max_age_seconds | No |
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint/idempotentHint already declaring a safe, repeatable read, the description earns extra credit by disclosing what the output deliberately omits: stale/future, uncovered and unconverted venues are withheld, and fees/trade clearance are out of scope. That is real behavioral context about result filtering rather than a restatement of annotations.
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?
Three tight clauses with the core comparison action front-loaded and no filler. Dense jargon ('rung/bracket') costs a little clarity without adding length.
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 two-parameter read-only comparison tool with annotations, it covers the scope and exclusions well. Without an output schema it should still say what the comparison returns (spread, venue list, failure reasons), and it never explains rung/bracket, leaving the agent partially equipped.
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 description coverage is 0%, so the description must carry the parameter burden. It loosely hints at max_age_seconds via 'withholds stale/future' and at sizes_usd via 'four BTC sell sizes', but the schema permits 1-4 sizes, contradicting the word 'four', and no units, format, or meaning of rung/bracket is given.
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 (compare) and resource (BTC sell sizes by rung/bracket), which is more than a restatement of the name. It does not, however, distinguish itself from the closely named sibling exit_cost, so the agent must infer the boundary.
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?
No explicit when-to-use, prerequisites, or named alternative. The caveats 'fees excluded; no trade clearance' faintly imply that a fee-inclusive or trade-clearing analysis belongs elsewhere, but the agent is never routed to exit_cost or told which conditions select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.