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

With no annotations, the description carries the full load and usefully discloses that balances are "paper" (simulated) and that fees live in a paper fee ledger. It does not state read-only semantics, freshness/recency bounds on "recent fills", limits, or auth requirements, and trader scoping is only implied.

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?

Two sentences, front-loaded with the resource and followed by usage cues. The first sentence is dense but each clause carries return-value information; there is little waste.

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 no output schema and no annotations, the description substitutes well by spelling out the returned fields (balances, recent fills, accrued fees). Minor gaps remain around recency definition and the undocumented trader_id, but an agent can invoke it correctly.

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 compensate for the single trader_id parameter. It only alludes to "the trader" without explaining format, source, or whether the ID is the caller's own, leaving the required parameter effectively undocumented.

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?

Names the resource (portfolio view of paper balances, fills, and 402 fees) and enumerates the exact contents returned (symbol, amount, chain). No sibling does portfolio/balance reads, so an agent can select it without inspecting other schemas.

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?

Explicitly states when to use it by mapping to the user questions it answers ("what do I hold?", "what have I paid in fees?"). It gives clear context but no exclusions or named alternatives, which is acceptable since no sibling overlaps.

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

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

With no annotations, the description carries the full burden and does disclose an authorization prerequisite (owning trader). It does not state whether the cancel is permanent, what happens to an already-fired trigger, or what a failed cancellation returns.

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?

Two short sentences, no filler, with the action front-loaded before the permission caveat. Every clause earns its place.

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 simple two-parameter mutation tool with no annotations or output schema, the description covers the core action and one precondition, but leaves trader_id undocumented and the post-cancellation state unspecified.

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 compensate, but it only names one of the two required parameters (trigger_id) and adds no format or sourcing detail for either it or trader_id.

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 pair (disarm/cancel) and resource (trigger), keyed on trigger_id, so the agent can distinguish it from set_trigger, list_triggers, and check_triggers. Sibling differentiation is implicit via the verb rather than explicit.

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 description supplies one real usage constraint – only the owning trader may cancel – which implies the required authorization context. It does not say when to prefer this over alternatives such as pause_trading or how to recover from an invalid trigger_id.

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

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

With no annotations, the description carries the full burden and does disclose the mutation side effects: triggers can fire, and paper fills occur bounded by their caps. It also discloses the return shape (one report per trigger) but says nothing about permissions, idempotency, or rate limits for repeated polling.

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 short sentences, front-loaded with the primary action and consequence, followed by the operating context and return shape. No filler or restatement of the name.

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 zero-parameter, no-output-schema tool, the description covers what runs, what side effects occur, and the rough return cardinality. It would be stronger if it described what a report contains, since no output schema exists to carry that.

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?

The tool takes zero parameters and the schema documents that cleanly, so the baseline is 4. The description adds context that the whole armed-trigger set is evaluated, which is the effective scope of the call.

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 action (poll every armed trigger against live prices) and its consequence (fire tripped ones with paper fills within caps). This is clearly distinct from the sibling trigger tools set_trigger, list_triggers, and cancel_trigger, which create, enumerate, and remove triggers rather than evaluate them.

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?

Explicitly explains that this normally runs on a cron and that the tool exists so agents and tests can drive the evaluation directly, which tells an agent exactly when to reach for it. It stops short of stating when not to use it (e.g., avoiding redundant calls after a scheduled run).

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

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

No annotations are provided, so the description carries the full burden. It discloses meaningful behavior beyond the schema: the polling pattern, the backed_up gate, and the critical rule that the deposit address is returned only after the 12-word backup is confirmed. It stops short of covering auth requirements or the full return shape (no output schema exists).

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 tightly written sentences, front-loaded with purpose, then usage, then the security constraint. No sentence is redundant and each adds distinct value.

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 polling status tool with no annotations and no output schema, the description covers what the agent needs: when to call, the terminating condition, and the key state-dependent return value. It does not fully enumerate the response fields, but the essential gating behavior is clear.

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 100% with a single trader_id parameter, so the schema already documents it. The description adds no format or semantics beyond what the schema provides, making the baseline 3 appropriate.

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 (Check) and resource (claim-ceremony progress for this trader's wallet), and ties it to a concrete state flag (backed_up). An agent can distinguish it from siblings like provision_wallet and swap_status without opening any schema.

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?

Explicitly states the trigger (poll after provision_wallet) and the stopping condition (until backed_up is true), plus a hard prohibition on revealing the deposit address early. This is precise when-to-use guidance rather than inference.

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

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

With no annotations, the description carries the full burden and does well: it discloses paper mode (simulated fills, play funds, real quotes) and the safety guarantee that nothing can move real money, plus the fee model. It does not cover idempotency (calling again with the same trader_id) or rate limits, leaving minor gaps.

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?

Front-loads 'Start here' and the mode switch, with dense but load-bearing detail. The fee parenthetical and guide-contents list are slightly verbose but useful for a first-call tool. No filler sentences.

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?

No output schema and no annotations, so the description must do all the work; it names what the guide contains (trade flow, fees, safety rules, copy-paste prompts) and the safety envelope. Almost complete, with only edge-case behavior (repeat calls, idempotency) unaddressed.

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 100%, so baseline is 3, and the description adds real value beyond the schema: it explains that omitting trader_id provisions a new trader, that the returned id should be persisted, and that it must be passed to every other tool — usage semantics the schema alone does not convey.

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 action (provisions your paper trader) plus what it returns (full integration guide, status with trader_id), and frames itself as the entry point among siblings. An agent can immediately tell this apart from provision_wallet, balance, or swap_* tools.

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?

Explicitly says 'Start here', explains the two calling modes (no trader_id vs. with trader_id), and instructs the agent to persist the trader_id and pass it to every other tool. That is direct when/how guidance with a forward-looking integration rule.

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

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

With no annotations provided, the description carries the full burden. It discloses the return content (armed/fired triggers with baselines and fire times), which implies a read-only operation, but it omits permissions, pagination, ordering, and side-effect details.

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?

The description is a single, front-loaded sentence with no wasted words. It conveys the core purpose and return content efficiently.

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 simple one-parameter list tool with no output schema and no annotations, the description is adequate but incomplete. It explains what is returned but does not address parameter semantics, filtering, pagination, or how it relates to sibling tools.

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% for the single required parameter, trader_id. The description only says 'for a trader' and does not name the parameter or explain its expected format, so it does not compensate for the missing schema documentation.

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 description states a specific verb+resource: list all triggers for a trader, and clarifies the trigger states and returned details. However, it does not differentiate itself from the sibling check_triggers, leaving some ambiguity about when this tool is preferred.

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 explicit when-to-use guidance and no mention of alternatives such as check_triggers, set_trigger, or cancel_trigger. Usage is only weakly implied by the word 'List'.

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

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

With no annotations, the description carries the full behavioral burden and provides substantial context: paper mode only, funds are simulated and worthless, and the tool does not exist in live mode. It still leaves operational gaps such as idempotency, rate limits, or error behavior, but the mode and value semantics are clearly disclosed.

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?

The description is front-loaded with the core action and scope, then efficiently adds the paper-mode constraint and live-mode distinction. Every sentence contributes useful context without redundancy.

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 6-parameter tool with no annotations and no output schema, the description covers the critical mode, purpose, and sequencing context. It does not explain return values or faucet limits, but with 83% schema coverage and no output schema, it is largely complete for correct invocation.

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 83%, so the input schema already documents nearly all parameters, including amount, symbol, decimals, chain, and token_address. The description adds no parameter-level meaning beyond that; baseline 3 is appropriate.

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 description states a specific verb and resource: 'Credit your paper trader with PLAY funds (the sandbox faucet).' It also scopes the action clearly with 'Paper mode only' and distinguishes it from live-mode onchain funding, making the tool's purpose unmistakable despite not naming sibling tools directly.

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?

It gives explicit when-to-use context: paper mode, as the signup/funding step before trading. It also states when it does not apply: live mode. However, it does not name a specific alternative tool for live funding, so it stops short of full 5-level routing guidance.

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

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

With no annotations, the description carries the full burden and does well: it discloses exactly what stops working (fills, trigger arming, trigger firing), that stopping is immediate and always safe, and that no confirmation is required. It omits permission requirements, whether open orders/positions are cancelled, and how the state is later reversed.

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?

Front-loaded with 'KILL SWITCH', then the exact effect, then the no-confirmation guarantee, then trigger phrases. Every sentence is actionable and nothing is wasted.

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 one-parameter emergency stop with no output schema and no annotations, the description covers the essential behavior and urgency. Minor gaps remain around auth, side effects on open positions, and reversal, which are left implicit via the resume_trading sibling.

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 0% and the description never mentions trader_id. However, with a single self-evident parameter (whose trading to pause) and the schema marking it required, the ambiguity cost is low, leaving this adequate but with a clear documentation gap.

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?

Names a specific action (stops) with precise scope: fills, trigger arming, and trigger firing all fail while paused. An agent can distinguish this from the sibling resume_trading without opening any schema.

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?

Gives clear triggering context ('Call the moment anything looks wrong') and user phrasings ('stop everything' / 'pause trading'), plus the reassurance that no confirmation is needed. It does not explicitly name resume_trading as the counterpart, so the routing is implied rather than stated.

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

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

With no annotations, the description carries the full behavioral burden and does well: it states one wallet per trader, returns the existing claim link if already provisioned, and warns 'never mint two.' It also describes the expected follow-up ('poll claim_status until backed_up is true'). It stops short of disclosing auth/permission needs or error behavior, but the key idempotency and next-step behavior are covered.

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?

The description is front-loaded with purpose, then usage, idempotency, human-facing instructions, and follow-up. Every sentence earns its place; there is no redundant or filler 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 provisioning tool with no output schema and no annotations, the description covers purpose, proactive usage, idempotency, return value handling, and the required follow-up polling. It is nearly complete, though it omits any mention of the optional trader_id parameter or permission/auth considerations.

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 100%, so the single trader_id parameter is fully documented in the schema. The description adds no parameter meaning beyond the schema and does not mention trader_id at all. Baseline 3 is appropriate when the schema already carries parameter semantics.

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 description states a specific verb and resource: 'Provision the human's trading wallet and get their claim link.' It is clear what the tool does, but it does not explicitly differentiate itself from sibling tools such as claim_status or get_started; sibling differentiation is implicit rather than stated.

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?

It gives a clear proactive trigger: 'Call this on your own as soon as you are connected — the human should never have to ask for it.' It also notes the idempotent case when a wallet already exists. However, it does not name alternative tools or explicitly state when not to call it beyond the idempotency note.

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

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

With no annotations, the description carries the full burden. It usefully discloses the three behaviors restored (trading, trigger arming, firing), which goes beyond the name, but omits permissions, whether resuming is idempotent when already active, failure behavior, and side effects on pending triggers.

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?

Two short, front-loaded sentences with zero filler; the reversal relationship comes first and the effect list second. Nothing is wasted.

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 one-parameter state-mutation tool with no annotations and no output schema, the definition covers what changes but not the identifier's semantics, error conditions, or authorization needs. Adequate but with clear gaps.

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?

The single required parameter trader_id is documented neither in the schema (0% coverage) nor in the description. The one-parameter shape is guessable, but no format, source, or scope for the identifier is given, so semantics rest entirely on convention.

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 and effect ('Lift the kill switch') and names the sibling tool it reverses (pause_trading), letting an agent place it precisely among 17 siblings. The follow-on sentence enumerates exactly what resumes.

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?

Use context is clear and explicit: this is the counterpart to pause_trading, so an agent knows to call it after a pause. No when-not guidance (e.g., calling it when already running, or which trader states make it valid) is offered.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the default (0 = always ask), the auto-execute condition (green safety plus an existing standing approval), the exception for red flags, the absence of a maximum, and that enforcement is server-side and non-bypassable. It stops short of stating return format, failure behavior, or permission requirements, keeping it below a 5.

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?

Front-loaded with the action and followed by the operating rules in four tight sentences with no filler. The final sentence on server enforcement is slightly rhetorical but does convey real behavioral information.

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 mutation with no annotations and no output schema, the description covers semantics, defaults, and enforcement boundaries thoroughly. It omits error/permission behavior and the return value, which are the remaining gaps.

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 only 50% (trader_id has no schema description), but the prose compensates: it defines the unit (USD), the default and 0-sentinel behavior, and the open upper bound. trader_id is contextualized as the trader whose policy is being modified.

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?

Starts with a specific verb+resource ('Set the per-trade auto-approve threshold in USD for this trader'), which unambiguously identifies the mutation. No sibling in the list sets an auto-approve threshold, so the tool is not confusable with set_trigger, pause_trading, or the wallet siblings.

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 description explains the meaning of the threshold but never states when to use this tool versus alternatives or what preconditions the caller must verify. Usage is implied from the field semantics rather than given as explicit guidance.

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

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

With no annotations, the description carries the full burden and does well: it discloses that the current live price becomes the baseline, that the trigger fires exactly ONCE, that execution is bounded by the trigger's own caps under the standing approval created here, and that BLOCKED tokens cannot be armed. It leaves failure handling and reversibility (cancel_trigger) implicit.

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?

Four tight sentences, front-loaded with the worked example and then the mechanics. No filler, though the double-quote-heavy opening is slightly dense.

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 mutation tool with no annotations, no output schema, and 8 parameters, the behavioral picture is good but incomplete: the return value (e.g., a trigger id), what happens on validation failure, and how to inspect or cancel the armed trigger are not mentioned.

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%. The description adds genuine meaning by mapping plain language to sell_pct and price_up_pct values ('50 = sell half', '100 = doubles'), but the other undocumented parameters (trader_id, chain, stable_symbol, stable_decimals) get no explanation.

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 ('Arm') and resource ('standing strategy' / trigger) and distinguishes the tool from siblings like list_triggers, cancel_trigger, and check_triggers by describing one-shot arming behavior. The plain-language example makes the effect immediately concrete.

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?

Usage is implied through the example and the constraints (one-shot firing, needs standing approval from this call, blocked tokens rejected), but there is no explicit when-to-use vs. alternatives guidance — nothing routes the agent to cancel_trigger, list_triggers, or pause_trading.

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

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

With no annotations, the description carries the full burden and does so richly: paper vs. live behavior, server-side approval enforcement, auto-approve conditions, re-inspection at execution time, once-only fill, atomicity, kill-switch and expiry failure modes, and the paper: return reference. This is far beyond what structured fields provide.

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?

Dense but front-loaded — the paper/live distinction and approval mechanics come first, with edge cases after. Every sentence carries information; it is long but justified by the tool's conditional complexity, with only minor density cost.

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?

No output schema exists, but the description discloses the return form ('paper:' reference, never confused with real tx hashes). For a mutation tool with no annotations, all gating, failure, and safety conditions an agent needs are present.

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 67%; the description elaborates user_approved semantics well beyond the schema (explicit yes vs. auto-approve path, red flags) and reinforces quote_id freshness/expiry. trader_id remains undocumented in both places, which is the only real gap.

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+resource ('Execute a swap_quote') and immediately scopes it as a paper fill vs. the unwired live path. It is clearly distinguishable from the sibling swap_quote, which produces the quote this tool consumes.

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?

Explicit when-to-use and when-not: paper mode fills, live mode refuses, approval via user_approved=true or auto-approve threshold, red flags need explicit yes, honeypots never fill. It names the gating conditions and points to related tools (signer_status, set_auto_approve) for the live path.

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

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

With no annotations, the description carries the full behavioral burden and delivers: fee applied at the quote layer, the 402 fee formula (max 50 bps / $0.50 min), gross/fee/net decomposition, honeypot blocking before quoting, quote TTL and single-fill semantics, and the amount_in_usd auto-approve basis.

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?

Dense but front-loaded: the core purpose and the fee/return semantics come first, with the ETH sentinel last. The parenthetical about the $0.50 minimum being a placeholder is slightly tangential, but nearly every sentence conveys callable-relevant behavior.

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 9-parameter tool with no output schema, the description supplies the missing return shape (amount_out_gross, fee, amount_out_net) and the constraints an agent needs (TTL, single fill, blocked tokens, chain coverage). Nothing required for correct invocation is missing.

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 67%, so the schema already documents most parameters. The description adds one genuinely missing detail not in the schema — the ETH sentinel address on EVM — but does not clarify trader_id, decimals_in/out, or the amount format, so it only marginally exceeds the schema baseline.

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+resource ('Dry quote for a swap') plus the mechanism (real venue quotes from KyberSwap/Jupiter/0x, best net-of-fee fill wins). It is clearly separable from swap_execute, which it names as the consumer of these quotes.

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?

Explains quote lifetime (60 seconds, fill at most once), that swap_execute rejects stale/consumed quotes, and that quoting is always safe (no signing/broadcasting) — effectively telling the agent to call this before executing. It never explicitly says 'call this to preview before swap_execute,' so it stops short of a 5.

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

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

With no annotations, the description carries the full behavioral burden and adds meaningful context: it lists the returned fields and explains that paper fills carry a paper: reference rather than a real transaction hash. It does not cover authentication needs, error behavior, rate limits, or whether the fill may be pending.

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?

The description is two short sentences with no wasted words, and it front-loads the core action before adding the important paper-fill nuance.

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?

There is no output schema, so listing returned fields is useful and the paper-fill note is valuable. However, the description omits where trade_id comes from, how pending or failed fills are represented, and any permission or authentication context, leaving meaningful gaps.

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 compensate for the single undocumented trade_id parameter. It only repeats 'by trade_id' without explaining format, source, or where the identifier originates, adding little beyond the parameter name itself.

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 description states a specific verb and resource: 'Check a fill by trade_id,' and enumerates the returned fields (status, amounts, fee, venue, reference). It clearly distinguishes the tool from generic wallet or trading tools, but it does not name or contrast with the closest siblings such as swap_quote or swap_execute.

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?

Usage is implied by 'Check a fill by trade_id,' suggesting this is used after a swap execution to inspect a fill. However, the description gives no explicit when-to-use guidance, no when-not-to-use conditions, and no named alternatives such as swap_execute or claim_status.

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

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

With no annotations, the description carries the full burden and does so: it defines verdict semantics (BLOCKED means no quote or fill ever; REVIEW_REQUIRED requires explicit user approval), describes the checks performed, and constrains agent behavior ('NEVER says looks safe'). This is disclosure well beyond a restatement of the name.

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?

Front-loads the action and the pre-trade ordering, then lists checks and verdicts compactly. The check enumeration is long but each item maps to a real output field, so little is wasted.

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?

No output schema exists, so the description must explain what comes back, and it does — listing the checked dimensions and the three verdict values. An agent has everything needed to call it and interpret the result.

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 100%, so chain and contract_address are already documented with formats and defaults. The description only adds the 'CA' shorthand and reinforces that an address is pasted in, so baseline 3 is appropriate.

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 and resource ('inspect a token', 'get red flags + facts') and enumerates exactly what is checked. It is clearly distinguishable from siblings like swap_quote and swap_execute, which it explicitly references.

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?

Gives explicit when-to-use ('call this first, every time, before swap_quote') and states the sequencing relative to a named alternative. It also tells the agent how to act on each verdict, which is unusually complete routing guidance.

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

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

No annotations are provided, so the description carries the full burden and does so well: it discloses that paper mode only records and debits the paper balance with status PAPER_RECORDED, that live mode is policy-restricted to the owner's pre-registered wallet, and that the tool never auto-executes. The server-side read-back recording is a non-obvious behavioral detail that adds genuine value.

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?

Front-loaded with the action, then the hard approval requirement, then mode-specific behavior. Sentences are dense but each carries distinct information (approval gate, paper status, live policy, no auto-execution) with no filler.

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 high-stakes, annotation-free mutation tool with no output schema, the description covers the critical unknowns: approval flow, mode-dependent effects, result status, and execution guarantees. It omits return-shape details and the semantics of several required identifiers, keeping it from a 5.

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 43%, so the description must compensate and it partially does: it explains that confirmed=true is only valid after confirming amount + destination, and reinforces destination read-back semantics already hinted in the schema. However, chain, symbol, token_address, and trader_id have no documented meaning in either the schema or the description, leaving over half the required parameters semantically bare.

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 and resource: 'Withdraw to an external wallet.' An agent immediately knows this moves funds out to an external address, which is distinct from the funding/settlement siblings (provision_wallet, paper_faucet, swap_execute). It stops short of naming a sibling it must not be confused with, so it is clear but not maximally differentiated.

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?

Gives an explicit precondition ('ALWAYS requires explicit per-action approval') and the exact condition for setting confirmed=true (after reading amount AND destination back and getting a yes). It also distinguishes paper vs live mode behavior. It does not name alternative tools or state when NOT to use this tool, so it falls just short of a 5.

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