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

Adds substantial context beyond the annotations: nothing is actually sent by TRNCH, the 0.5% fee is pre-deducted from the quote, the approval-before-tx ordering, the target chainId 4663, and what each error code (409, 429 with retry-after) means operationally. Authentication requirements are stated explicitly (key from trnch_register, Bearer header).

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 dense paragraph that is front-loaded with the action and the call shape, then the return contract, then failure modes, then auth. Every sentence contributes a fact an agent needs; nothing is padding.

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, the description carries the return contract itself (router, quote, approval, tx, chainId, from) and the sequencing rule for the nullable approval. Combined with the error codes, chain, and auth details, nothing an agent needs to call this correctly 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 100%, so the baseline is 3, but the description adds meaning the schema lacks: tokenId originates from trnch_heat's `id` field, amountUsd is settled in USDG, and the fee is already netted out of the quoted amount. It does not discuss slippageBps behavior beyond the default, which the schema already covers.

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?

Opens with a specific verb and resource ("Build a buy") and immediately scopes it: quotes six routers, returns the best route as a signable transaction. This clearly separates it from trnch_quote (price only) and trnch_sell (opposite direction) without needing the 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?

Gives concrete selection rules for the parameter alternatives ("Give tokenId or token, and amountUsd (paid in USDG) or amountIn with tokenIn") and states the post-call procedure (send approval first, then sign/send tx from the same wallet). It does not explicitly say when to prefer the sibling trnch_quote over this tool, so it stops short of a full routing statement.

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?

Goes well beyond the annotations: it discloses the auth requirement (Bearer key from trnch_register), that the return is an acknowledgement only, and that the tool does not send, cancel or change the transaction. It also clarifies that crediting happens only once the receipt is checked on chain, implying asynchronous settlement. The idempotency statement largely restates idempotentHint=true, a small duplication.

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 usage condition, then side effects, idempotency and auth in a compact single paragraph. Dense but every clause carries actionable information; only the idempotency clause partly duplicates the annotations.

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 report tool with no output schema, everything needed is present: prerequisite, auth, side-effect scope, idempotency, and failure mode. No return-value detail is required since only an acknowledgement is returned.

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 parameter is fully described in the schema, but the description adds real meaning: the hash must come from a swap sent by this wallet via trnch_buy or trnch_sell, and any other hash credits nothing. That constraint is absent from the schema's pattern-only definition.

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 ('report its hash' for a sent swap) and ties it directly to the transactions produced by trnch_buy and trnch_sell, which no other sibling does. An agent can immediately distinguish it from the trading 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 frames it as 'Optional, after sending a tx from trnch_buy or trnch_sell', naming the prerequisite tools and the exact moment of use. It also states the negative cases (hash that is not a swap of this wallet credits nothing; repeat calls change nothing), so when-not-to-use is covered too.

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?

Annotations already declare it as a safe, read-only, idempotent read, and the description adds material context beyond them: the API key from trnch_register must be sent as an Authorization Bearer header, polling should be throttled to every few seconds, and the new-holds variant carries higher risk. That is real behavioral disclosure, not restatement.

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: what the feed is, what a token looks like, how to paginate, how to poll, and what auth is needed, with zero 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 exists, so the description carries the return burden and does it: it enumerates the token fields (rank, Heat score, price, liquidity, volume, price changes, entry time) and the nextSince cursor. Auth and rate guidance round out everything needed to call 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 coverage is 100% and the single `since` parameter is already documented as 'nextSince from the previous call.' The description reinforces the round-trip usage ('pass it back as since') but adds no format or edge-case detail the schema lacks, so it sits at the 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?

Opens with a specific verb+resource ('Read the live Heat') and immediately disambiguates the two sub-feeds: heat = screened/ranked tokens, new holds = just-spotted, higher risk. An agent knows exactly what comes back without opening a 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 concrete operating guidance: poll at most every few seconds, pass token ids to trnch_buy or trnch_sell, pass nextSince back as since for only new entries, dedupe by id. It lacks an explicit 'when not to use this' or a comparison to another feed, but the follow-up routing to siblings is clear.

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?

Annotations already cover read-only, idempotent, non-destructive semantics, and the description adds value on top: it discloses that no transaction is built, that the quote is already fee-adjusted, the 409 behavior, and that an API key from trnch_register must be sent as a Bearer token. That is behavior an agent cannot infer from the structured fields.

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 sentences, front-loaded with the core action and return value, then usage routing, then error/auth constraints. No filler or repetition of the title or schema.

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 still explains what comes back (best amount out, fee-adjusted, plus router). Auth requirements and the 409 failure mode cover the remaining operational gaps for a read-only quote call.

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 tokenIn, amountIn, slippage, and decimals are already fully documented, and the description adds no per-parameter detail beyond what the schema states. Baseline 3 applies when the schema carries the semantic load.

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?

Specific verb plus resource ('Quote any pair across six routers'), with the returned value spelled out: best amount out net of the TRNCH fee plus the router. It is clearly distinguished from siblings by naming trnch_buy and trnch_sell as the trading alternatives.

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 ('Use it to compare before buying') and when-not-to-use, routing the agent to trnch_buy/trnch_sell for actual trades. It also names a concrete failure condition (409 for non-tradable tokens) and the auth prerequisite.

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?

Annotations declare a non-readonly, non-idempotent, non-destructive write, and the description adds substantial context beyond that: the 201 status, the exact response shape, that the key is shown only once and must be stored, the balance requirements (10 USDG or 0.004 ETH on Robinhood Chain), the 3-keys-per-wallet cap, and the 400 condition. This is exactly the kind of operational detail an agent cannot infer from hints.

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?

Extremely information-dense with no filler: step position and return shape are front-loaded, followed by the storage warning and error codes. The error-code clauses are compact but slightly stacked, keeping it just short of perfect.

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, the description still fully specifies the return payload and status code. Combined with the balance and rate-limit constraints, an agent has everything needed to invoke this correctly 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 the baseline is 3, but the description adds real semantics: wallet must be the same one used in trnch_register_message, message must be passed unchanged, and the wallet must hold specific balances. Only the optional 'label' parameter is not elaborated on in prose, which the schema handles.

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 two-step registration action ('Step 2 of 2: send the message from trnch_register_message and its signature') and names the exact return payload { key, prefix, wallet }. The dependency on trnch_register_message makes it immediately distinguishable from every sibling.

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 frames itself as the second step and points to trnch_register_message as the prerequisite, so the agent knows the ordering. It also enumerates the failure conditions (402, 409, 400), though it doesn't say what to do on those errors or when not to call it.

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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the description isn't carrying the safety burden alone; it still adds real value by disclosing the 10-minute expiry and that the call moves no funds. It doesn't say whether a second call within the window returns the same message or a fresh one, which is the one behavioral ambiguity left.

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 sentences, front-loaded with the step position and the payoff, then the return shape and constraint, then the next action. Every sentence carries 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?

There is no output schema, but the description supplies the return shape ({ message }) plus the signing standard and validity window, which is everything needed for this single-parameter read step. Nothing an agent needs to invoke it correctly 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?

The single wallet parameter has 100% schema coverage including the address pattern and EOA/EIP-1271 note, so the baseline of 3 applies. The description's only wallet reference ('your wallet must sign') adds no constraint beyond the schema.

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 and artifact: step 1 of 2 to obtain an API key, returning the exact text to be signed with personal_sign (EIP-191). It is clearly distinguishable from the sibling trnch_register, which is explicitly labeled as step 2.

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 sequencing is given: call this first, then call trnch_register with the resulting signature. 'No browser' frames the alternative flow, so an agent knows this is the headless path rather than the interactive one.

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?

Goes well beyond the annotations: discloses the 0.5% fee already deducted from the quote, that six routers are compared, that TRNCH itself broadcasts nothing ('Nothing is sent by TRNCH'), the exact return shape, the chainId, and error semantics for 409 (token not tradable via TIA) and 429 (retry-after). Those are precisely the behavioral facts an agent needs before committing to a trade.

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, then the parameters, then the return contract, then errors and auth — each sentence carries distinct, actionable information with no filler, even though the total is longer than average.

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 available, the description supplies the return fields ({ router, quote, approval, tx, chainId, from }) and the ordering rule for approval. Combined with auth, error codes, and the no-broadcast guarantee, an agent can call this correctly and handle the response without further context.

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 all five parameters are already documented. The description restates the either/or pairings (tokenId or token, percent or amount) and notes the balance is read on chain, but adds little syntax or constraint detail beyond the schema. Baseline 3 for a fully covered schema 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 — 'Build a sell for USDG in one call' — and immediately qualifies scope: quotes six routers, returns the best route as a transaction. An agent can distinguish this from trnch_buy and from quote-only siblings 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 concrete invocation guidance (tokenId or token, percent or exact amount) and the API-key prerequisite from trnch_register, plus a clear post-call procedure ('if approval is not null, send it first, then sign and send tx'). It stops short of explicitly routing against siblings — e.g., no statement that trnch_quote is the preview-only alternative to this build-and-sign 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?

The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so safety is covered. The description adds two genuinely new facts beyond them — no API key required and the 24-hour data window — but says nothing about refresh cadence or the response shape beyond the metric names.

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, zero filler, and the metric list is front-loaded before the usage hint. Every clause — units in seconds and percent, 'No key needed', the 'use it first' directive — 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?

With no output schema and no parameters, the description carries the full burden and discharges it by enumerating the returned fields with units. Nothing an agent needs in order to decide to call trnch_stats 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?

The tool takes zero parameters, so the baseline is 4 by rule. The description correctly implies no inputs are needed and spends its words on outputs instead, which is the right allocation.

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 verb plus resource ('Read live public numbers for the last 24 hours') and enumerates the exact metrics returned, so the agent knows precisely what it gets. It doesn't name any sibling explicitly, but the read-only stats scope is plainly distinct from buy/sell/quote/heat execution 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?

'Use it first to judge whether TRNCH screening is worth routing through' gives an explicit entry-point condition plus the 'No key needed' prerequisite. It stops short of stating when NOT to call it or which sibling to chain into next, so it lacks full alternative routing.

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