arcgate

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 unusually well: pricing tiers, x402 payment mechanics, the signing scope (method/path/body), nonce single-use, expiry, the one-time-visible key, and concrete error codes. It even flags the crucial behavior that omitting a signature is a 401 signature_required, never a charge.

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?

Well front-loaded (purpose first) and organized with bold Cost/Inputs/Returns/Errors/Next headers. It loses a point because the trailing paragraph restates cost and payment placement already covered in the Cost bullet, adding bulk rather than new 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, and the description compensates by spelling out the returned fields (accountId, first key, periodEnd, units, ownerHasBox) and how to use the key (ARCGATE-KEY). For a paid, signed, mutating tool, everything needed to call it correctly is 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 100%, so the schema already documents all three parameters (including the agentSignature nested object). The description still adds meaning the schema does not fully surface, e.g. the signed path uses the lowercased address and the bodyHash covers the canonical JSON body, plus the per-tier price association. That is real added value above the baseline 3.

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 opening sentence states a specific verb+resource ('Opens the account for an address'), the time scope (one period of 30 days) and the primary return ('its first key'). It also names the sibling it differs from ('409 account_exists... Read it with accountStatus'), so an agent can distinguish it from accountRenew/accountStatus 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?

The Errors and Next sections give explicit routing: on 409 account_exists use accountStatus; follow up with accountStatus to read the period/units and tradeSearch to spend the key. It also states who may invoke ('Anyone may pay, not only the owner'), which is exactly the when-to-use context an agent needs.

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: it discloses the x402 payment flow (payment goes in params._meta["x402/payment"], needs an x402-aware client), that no key/signature is required, that credit never expires, the 1 USDC minimum and 400-before-settlement behavior, and exact error codes with side-effect status.

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 purpose sentence followed by scannable labeled bullets (Cost, Inputs, Returns, Errors, Next), which is efficient for a multi-faceted tool. The closing paragraph restates the minimum cost and body-amount point already made in the Cost bullet, a minor 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 2-parameter payment tool with no output schema and no annotations, it covers cost, payment channel, inputs, return fields (accountId, credit.added, balance), error codes with settlement guarantees, and next-step tools. Nothing needed to call 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?

Schema coverage is already 100%, so the baseline is 3, but the description adds real meaning: the base-unit string convention ("1000000" = 1 USDC), that the 402 quotes exactly the amount, and the fallback/refusal behavior for missing or sub-minimum amounts. It does not add much on `address` beyond the schema, keeping it just shy of 5.

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 ('Adds prepaid credit to an account, in USDC') and immediately frames it as overage credit drawn past a period's units, which separates it from siblings like boxTopUp or boxUnitsBuy. An agent can identify the operation without opening the 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 covers when credit is consumed (keyed calls or a linked box's watch hit past the period's units), who may invoke it (anyone, no key or signature), and routes to alternatives for follow-up: accountStatus for balances, accountCreate on 404, boxStatus for reactivated boxes. Conditions and alternatives are both named.

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 thoroughly: it discloses the live-read price, the x402 payment path and that no key/signature/body is needed, that the tier is the owner's and never the payer's choice, and the exact settlement semantics of grace vs. lapsed renewals (leftover units discarded, credit kept, no day lost). It enumerates every error code with the condition and settlement outcome, which is precisely the behavioral context an agent needs for a paid mutation.

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?

Bold section headers (Cost, Inputs, Returns, Errors, Next) make it scannable and front-loaded, and the length is justified by the payment complexity. It loses a point for repetition: 'Nothing settles' recurs five times and the address letter-case/payer point appears in both description and 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?

There is no output schema and no annotations, yet the description enumerates the returned fields (`accountId`, `tier`, `periodStart`, `periodEnd`, `graceEnd`, `units`), the pricing table, and the full error surface. Nothing an agent needs to invoke or recover from this call 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% and the `address` description already documents letter-case tolerance and that the payer may be any address, so the schema does the heavy lifting. The description's Inputs section largely restates the path parameter; the baseline 3 is appropriate when the schema is this complete.

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: it starts the account's next 30-day period and restores a lapsed account. It explicitly distinguishes itself from siblings by naming `accountTier` (which sets the scheduled tier) and `accountCreate` (used when no account exists), so an agent can tell it apart without opening another 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?

States the preconditions clearly (the period must have ended, otherwise 409 `period_running` names `periodEnd`), tells the agent how to recover from repricing (ask again and pay the new price), and routes to the follow-up tool (`accountStatus`). It also notes who may invoke it (anyone, not just the owner), leaving little to 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 so thoroughly: it declares the operation is free, specifies the exact auth mechanism (owner EIP-712 signature over GET with the given path and empty body, or an ARCGATE-KEY header), and documents both failure modes (404 account_not_found, 403 key_wrong_account). This is exactly the behavioral context an unannotated read tool needs.

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 first sentence front-loads the purpose and the remaining content is organized under Cost/Inputs/Returns/Errors/Next headers, which is easy to scan. The 'Returns' bullet, however, is a very long dense run-on enumerating every notice type, which slightly hurts conciseness even though the detail is justified by the absence of an output 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?

There is no output schema, so the description must explain return values and it does so exhaustively (tier, scheduledTier, period/grace bounds, state enum, units, credit, limits, linkedBoxes, notices with per-type field breakdowns). Combined with the auth details, error codes, and follow-on tool routing, nothing needed 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 description coverage is 100%, so the schema already documents 'address' (including 'any letter case') and the agentSignature object in depth. The description's 'Inputs' line only restates the address path parameter, adding no syntax or semantics beyond the schema, which is the baseline-3 case.

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 opening sentence states a specific verb ('Reads') and resource ('an account's tier, its period, the units used and left, and its limits'), enumerating the returned fields so an agent knows the scope. It does not, however, differentiate itself from plausible siblings like accountTier or accountUsage, which appear to expose subsets of the same data, so it falls short of a 5.

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 well supported by the 'Next' section (tradeSearch to spend units, boxLink to link a box) and by error-based routing (404 account_not_found → 'Create one with accountCreate'). What is missing is explicit guidance on when to prefer this over accountTier/accountUsage, so it is clear context without exclusions.

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 declares the operation free, states it must be owner-signed over a specific method/path/body, and warns that the ARCGATE-KEY header alone yields 401 signature_required. It also documents the 409 tier_does_not_fit downgrade refusal (with what the body names), held-message exemption, upgrade-never-refused rule, and lapse/grace scheduling behavior.

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?

Bold labeled sections (Cost, Inputs, Returns, Errors, Next) front-load the core behavior and make the dense content scannable. It is long, and the signature details in the description partly overlap the schema's agentSignature documentation, but the length is defensible for a signed, error-prone mutation.

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 three-parameter, nested-object, signed mutation with no output schema, the description covers return fields (accountId, tier, scheduledTier, periodEnd), typed error codes with causes, cancellation semantics, and downstream tool handoffs. 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?

Schema description coverage is 100% and the parameter descriptions are themselves unusually detailed (tier, address, and the full AccountRequest signature recipe), so the schema does the heavy lifting. The description's "Inputs" bullet (address any letter case, tier one of the paid tiers, current tier cancels a pending change) largely restates that, adding little beyond 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?

"Sets the tier the account's next `accountRenew` runs at, up or down" is a precise verb+resource statement, immediately qualified by the crucial scoping fact that units and limits do not change until renewal. This distinguishes it cleanly from siblings like accountRenew (which pays) and accountStatus (which reads the schedule).

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 "Next" section explicitly routes the agent to accountRenew (pay once periodEnd passes) and accountStatus (read scheduledTier), which gives clear sequencing context. However it never states when NOT to call this tool or frames these as alternatives the agent must choose between, so it stops short of the top tier.

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 thoroughly: cost is free, auth is either a signature over GET with no body (or an empty-bytes hash) or an ARCGATE-KEY, and it discloses subtle billing semantics — credit-paid draws counted, refunded draws not, grace-period draws attributed to the closed period, and previous being null before the first renewal.

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 opening sentence front-loads the purpose, then bold section headers (Cost, Inputs, Returns, Errors, Next) organize the detail. Given the absence of an output schema, the lengthy Returns section is justified rather than wasteful, and every sentence carries operative 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 read tool with a nested auth object, no annotations, and no output schema, the description supplies everything an agent needs: purpose, auth modes, return shape, boundary cases, and error conditions with recovery paths (accountCreate for 404, key/account mismatch for 403).

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 address and agentSignature parameters are already fully documented in the schema. The description restates that address is a path param in any letter case but adds no syntax or constraint beyond the schema, 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 (reads) and a precisely scoped resource: the units an account's draws took, broken out by UTC day and by operation, across the current and previous period. This distinguishes it cleanly from siblings like accountStatus (units left) and accountCredit (buying credit), which it explicitly names.

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 Next section routes the agent to accountStatus for remaining units and accountCredit for purchasing past-period draws, and the Cost line clarifies this read draws nothing. It stops short of stating an explicit 'do not use this when...' exclusion, so it is clear context rather than full when/when-not 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 so well: it discloses the 0.005 USDC x402 cost, the ARCGATE-KEY header alternative, where payment goes (params._meta['x402/payment']), required x402-aware client, and two concrete error codes with causes. It also clarifies data semantics ('There is no score: feedback is facts. The registration file is the agent's own claim').

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?

Well front-loaded and bullet-structured, with cost, inputs, returns, errors and next steps scannable. However, the opening sentence is nearly verbatim restated in the 'Returns' bullet, and the cost appears twice (top bullet and closing paragraph), so a little trimming would help.

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 paid, no-annotation tool with no output schema, the description supplies everything an agent needs: return shape, error semantics, payment path, auth alternative, and sibling routing. Nothing material 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 description coverage is 100%, so the schema already documents chainId and agentId fully, including the ERC-8004 IdentityRegistry context and the 404 unknown_chain behavior. The description restates the input names but adds no format or syntax detail beyond the schema, matching the baseline 3.

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 -- 'Everything arcgate holds on one agent' -- and enumerates the three payloads (on-chain facts, registration file with chain checks, feedback). It is clearly separable from sibling agentSearch ('find other agents') and agentWallet, which are named explicitly.

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?

Provides a 'Next' section routing the agent to agentSearch for finding other agents and agentWallet for address lookups, plus a 404 agent_not_found remedy ('Find the agentId with agentSearch'). It does not state exclusions or when *not* to call this, but the surrounding context 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?

With no annotations, the description carries the full burden and does so richly: it discloses per-call cost (0.005 USDC via x402), the alternative ARCGATE-KEY header payment path where payment goes in params._meta, result ordering (agentId ascending), pagination via nextAfter, error behavior, and the semantic caveat that declarations are the agent's own claims. This is exactly the behavioral context an agent needs before calling.

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?

Bullet structure with Cost/Inputs/Returns/Errors/Next is well front-loaded and scannable. However, the cost is stated twice (the Cost bullet and the trailing paragraph), which is redundant text that doesn't earn 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 7-parameter, no-annotation, no-output-schema tool, the description covers return shape (page of agents by agentId ascending with on-chain facts and registration declarations), pagination, errors and payment. It could say more about the fields inside each agent record, but the essentials for correct invocation 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 100%, so every parameter is already documented in the schema, including the AND semantics ('every one, not any'). The description largely restates inputs rather than adding syntax or format meaning beyond what the schema provides, so the baseline of 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 (lists), resource (agents in Arc's ERC-8004 IdentityRegistry) and a precise scope (those matching their registration-file declarations). This clearly separates it from the sibling agentProfile (single-agent read), so an agent can route without opening either 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?

The 'Next' section routes the agent to agentProfile for a single agent's checks and feedback, and the Errors section explains the 404 unknown_chain case. It also clarifies that feedback never orders or filters results, implying this tool searches on declarations, not reputation. It stops short of an explicit when-not-to-use 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?

With no annotations, the description carries the full burden and delivers: 0.005 USDC per call over x402, the alternative ARCGATE-KEY header payment path, where payment goes (params._meta['x402/payment']), the 404 unknown_chain failure mode, the empty-list-not-error behavior, and the agentId-ascending ordering. An agent knows exactly what this call costs, how to pay, and how it fails.

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?

Bold labels (Cost / Inputs / Returns / Errors / Next) make it scannable and the critical scoping facts are front-loaded. It loses a point because the pricing is stated twice — once in the Cost bullet and again verbatim in the trailing paragraph — which is pure duplication.

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, and the description compensates by describing the return shape (per-agent summary plus roles, ordered by agentId) and the empty-result case. Cost, payment, error, and next-step information are all present, so 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 description coverage is 100%, so both parameters are already documented in the schema, including the 'any letter case' detail and the unknown_chain constraint. The description mostly restates those inputs rather than adding new syntax, format, or edge-case meaning, so the baseline of 3 applies.

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 (looks up), a specific resource (the ERC-8004 agents an address owns or is the agentWallet of), and the exact relationship being resolved. It is distinguishable from the other agent-oriented siblings (agentSearch, agentProfile) because the lookup key and the ownership/agentWallet relation are named explicitly.

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 'Next' section routes the agent to agentProfile for an individual agent's checks and feedback, and the error note tells it to use only the chain this deployment serves. It gives clear context for when this is the right entry point, though it never explicitly contrasts itself with agentSearch (the other agent-listing sibling).

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 discloses the per-call cost and x402 payment channel, payment location (_meta), that anyone may pay, and the critical lifecycle behavior that messages are deleted within the hour after allowance.expiresAt passes. This is exactly the kind of non-obvious behavior an agent needs.

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 one-line summary followed by tight bulleted sections for Cost, Inputs, Returns, Errors, and Next. Every sentence earns its place 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?

No output schema exists, yet the Returns section names the returned fields (granted, allowance), and the error/next sections cover failure routing and preconditions. For a payment-gated creation tool with no annotations, the description is complete enough to call 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% for the single `address` param, so baseline 3 applies. The description adds meaning beyond the schema by noting it is a path parameter, accepts any letter case, and that there is no request body, which reduces call-construction errors.

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 ('Creates the box for an agent's address') with concrete scope: 500 messages, 30 days, 0.05 USDC. It clearly distinguishes itself from boxTopUp (topping up an existing box) and boxStatus (reading the allowance).

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 409 `box_exists` error explicitly tells the agent to use `boxTopUp` instead, and the 'Next' section routes to `boxTopUp` and `boxStatus` with conditions. When-to-use versus alternatives is stated rather than inferred.

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 and does so thoroughly: cost is free, the exact signing scheme (method, path, body, EIP-712 typed data, required headers), authorization alternatives (ARCGATE-KEY vs owner signature), and the side effect of notifying the owner's box. Error states are enumerated with codes and remedies.

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 one-line summary followed by labeled bullet groups (Cost, Inputs, Returns, Errors, Next) makes it scannable. It is long, and the signature/auth mechanics are restated from the schema, but each section is purposeful rather than 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 4-param, nested-auth mutation tool with no output schema and no annotations, the description supplies the missing layers: return fields (address, accountId, linkedAt, keyId), full error taxonomy, and navigation to related tools. Nothing an agent needs to invoke it correctly is absent.

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 highly detailed nested-object docs, so the schema already explains address, accountId, and both signature objects. The description's 'Inputs' line restates path/body placement but adds no semantics 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 verb and resource ('Links the box to an account') plus the effect on behavior (watch hits draw the account's units; limits become the account's tier). It is trivially distinguishable from siblings like boxUnlink and boxCreate, and the cardinality constraint ('A box belongs to at most one account') sharpens the semantics.

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 'Errors' and 'Next' sections effectively encode when-to-use and when-not: link only when a box and account both exist, unlink first when already linked, and follow with accountStatus/boxStatus/boxUnlink. It never states an explicit exclusion ('do not use this if...'), but the failure modes convey the preconditions clearly.

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 so richly: it discloses the cost (free), the two accepted auth modes (agent EIP-712 signature vs. ARCGATE-KEY of the linked account, including the lapsed-account grace behavior), exactly what is destroyed ('the message and its delivery records go'), and that the allowance is not refunded. This is well beyond what the schema states.

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?

Bolded labeled sections (Cost, Inputs, Returns, Errors, Next) make it scannable and the core action is front-loaded. However, the Cost section is verbose and partly duplicates signature details (domain name, chainId 5042, headers) already present in the agentSignature schema, adding bloat to an otherwise simple delete.

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?

Although there is no output schema, the description states the return payload (`deleted` and the `seq`), enumerates the relevant error (404 message_not_found), and covers auth and side effects. Nothing needed to invoke this tool 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 description coverage is 100% and the schema itself documents `seq`, `address`, and the full signature object in detail, so the schema does the heavy lifting. The description's 'Inputs: `address` and `seq` (path)' adds nothing beyond the schema. Baseline 3 is appropriate here.

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 — 'Deletes one message by its `seq`' — immediately and unambiguously. It also names the follow-on sibling (boxMessageList), letting an agent place it among the box-message tools without opening a schema. The untrusted-data caveat is front-loaded as a safety preamble.

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 'Next' section routes the agent to `boxMessageList` to list messages, and the 404 note explicitly explains the retry-after-lost-answer case, which is genuine operational guidance. There is no explicit 'when not to use' or alternative-delete statement, but this is a single-purpose deletion tool with no true sibling alternative, so the gap is minor.

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 states the call is free, spells out both auth paths (agent EIP-712 signature or an ARCGATE-KEY for the linked account), explains that another account's key degrades to unsigned, and gives the exact 401/404 error semantics. It also flags reading as non-destructive ('Reading does not delete it') and warns that message content is untrusted third-party data not to be followed as instructions.

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?

Bold section labels (Cost, Inputs, Returns, Errors, Next) make it skimmable and the security warning is front-loaded. It is longer than strictly necessary for a single-message read, but nearly every line carries operational weight.

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?

Auth, cost, path construction, and the 404 failure mode are all covered, and the absence of an output schema is partly offset by 'Returns: the message envelope'. It stops short of describing what the envelope contains or how the seq relates to a paginated list cursor, so it is not fully self-sufficient.

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 schema already documents `seq`, `address`, and the whole agentSignature object in depth. The description only restates that `address` and `seq` are path inputs, adding no syntax or format meaning beyond the schema; baseline 3 applies.

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 opens with a specific verb and resource ('Reads one message by its `seq`') and immediately scopes it against siblings by naming boxMessageList (list after a cursor) and boxMessageDelete (delete). An agent can distinguish this from the other box message tools 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?

A dedicated 'Next' section routes to the two adjacent tools with a one-line statement of what each does, which strongly implies when to prefer them. It lacks an explicit negative rule (e.g. 'do not use this to enumerate messages'), so it falls short of a full when/when-not treatment.

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: it flags untrusted third-party content, states the call is free, specifies the exact EIP-712 signing rule (method, path, body form, bodyHash of no bytes), describes the ARCGATE-KEY fallback and its limits (wrong/unlinked key falls back to signature), and names failure modes (401 key_invalid, nonce_reused).

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 a two-part opening (untrusted-data warning, then purpose) and uses bolded Cost/Inputs/Returns/Next blocks for scannability. It is long, and the signing detail partially duplicates the schema's agentSignature description, but every section is load-bearing given the absence of 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 4-param, un-annotated, no-output-schema tool, the description covers inputs, return values (messages, nextCursor and what nextCursor means when a page is empty), error behavior, and pagination strategy. Nothing an agent needs to call 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?

Schema coverage is 100%, so baseline is 3, but the description adds meaning beyond the schema: the cursor is a seq with 'messages with a higher seq are returned', any extra query param is 'ignored and not signed', and a limit over 100 is cut. It also clarifies that cursor/limit are covered by the signature.

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 ('Lists the box's messages') with scope qualifiers ('after a cursor, oldest first, one page at a time') that an agent can act on immediately. The pagination semantics ('one page at a time') also distinguish it from boxMessageFetch's single-message read.

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 'Next:' block explicitly routes to boxMessageFetch ('read one message by its seq') and boxMessageDelete ('delete a message you have handled'), and the description adds the sequencing rule 'Advance the cursor only after you have handled a page.' It gives clear context and alternatives, though not an explicit when-not-to-use case.

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: it declares the call is free/never charged, details the signature-vs-ARCGATE-KEY auth rules and key lapses, describes pause state transitions (paused_daily_cap, resumesAt), notice emission, refusal semantics (whole hit refused, counted in unstoredWatchHits), and enumerates error codes. This is exceptional behavioral disclosure.

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 purpose and organized under bolded sections (Cost, Inputs, Returns, The cap, Errors, Next). It is dense and long, with some redundancy between the Inputs and Errors bullets, but nearly every sentence adds operational value for a genuinely complex tool.

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, yet the description specifies the return payload ('address' and 'maxUnitsPerDay', with null meaning none) and cross-references boxStatus. Auth, inputs, cap mechanics, errors, and follow-up tools are all covered, leaving nothing an agent needs 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. The description largely restates what the schema already documents (case-insensitive address, whole number ≥1 or null, missing = 400 not clear), adding only marginal nuance such as 'A box has no cap until it sets one.'

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 set and resource ('Sets, raises, lowers or clears the box's daily spend cap'), defines the cap precisely, and references siblings (boxStatus, watchList, boxCreate) so the agent can route correctly. The scope is unambiguous against neighboring 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?

Provides explicit routing ('Next: boxStatus', 'watchList') and prerequisite handling ('the address has no box. Create one first (boxCreate)'), plus the alternative auth paths. It stops short of stating when NOT to use this tool versus an alternative, but context 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?

With no annotations, the description carries the full burden and does so richly: cost is free, the two auth paths (EIP-712 signature vs. ARCGATE-KEY of the linked account), the exact case where a key is ignored, the 401 key_invalid behavior, key validity after account lapse, and the 404 error. This is exceptional behavioral disclosure for a read tool.

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?

Bold headers (Cost/Inputs/Returns/Errors/Next) front-load the essentials and every bullet is substantive. It is dense and on the long side, but the auth detail is genuinely load-bearing given zero annotations, 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, yet the description enumerates every returned field (allowance sub-fields, unitBalance, linkedAccount, maxUnitsPerDay, counts, unstoredWatchHits, registeredAgents) with meaning, and covers inputs, errors and follow-ups. Nothing an agent needs to call 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?

Schema description coverage is 100% and the nested agentSignature object is documented exhaustively in the schema, so the description need not add parameter detail. It only notes 'address (path)', which the schema already covers; baseline 3 applies when the schema does the heavy lifting.

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 ('Reads') plus the exact resource scope: a box's allowance, unit balance, message counts and unstored watch hits. An agent can distinguish it from accountStatus and boxMessageList without opening either 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?

The 'Next' section routes to related operations (boxTopUp, boxUnitsBuy, boxSpendCap, boxMessageList) and the auth bullets make clear this is a free read. However, it never states when to prefer this over a sibling status tool or any exclusion condition, so usage is contextual rather than prescriptive.

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: cost (0.05 USDC / 50000 base units), payment channel (x402 via params._meta), non-renewal semantics, and the destructive consequence that every message is deleted within the hour of expiry. Error codes and their meanings are spelled out.

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 value proposition and organized into scannable Cost/Inputs/Returns/Errors/Next sections. Slightly repetitive: the 0.05 USDC cost is restated twice (opening line and closing paragraph).

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 compensates by describing the return (granted, what the payment added, the resulting allowance) and by enumerating error cases and next actions. Nothing needed to call this correctly appears 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 address field is already documented. The description adds meaning beyond the schema by specifying that the payment payload goes in params._meta["x402/payment"] and that an x402-aware client is required — crucial invocation detail not present in the input 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 verb+resource+quantities: adds up to 500 messages and 30 days to an existing box, with a price. It distinguishes itself from siblings by naming boxCreate (when no box exists) and boxStatus (to read allowance).

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 (existing box, top-up), when-not (409 box_required -> use boxCreate; 409 allowance_full -> wait), and the follow-up read path (boxStatus). It also clarifies anyone may pay, removing ambiguity about who is allowed 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?

No annotations, so the description carries the full burden and does well: it discloses pricing, the x402 payment flow, that anyone may pay, settlement behavior ('Nothing settles' on 400), and precise error codes 400/409. However, the score is capped because several disclosures live in schema descriptions and it never states permission/signing requirements beyond a passing mention of the payer — solid but not exhaustive for a paid mutation.

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 core behavior and organized into labeled sections (Cost, Inputs, Returns, Errors, Next) that are easy to scan. Slightly penalized for redundancy — the 0.005 USDC/20-unit pricing is repeated three times across the first line, the Cost bullet, and the closing paragraph.

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?

Despite no output schema, the description documents the return shape (units.bought, units.balance) and enumerates both failure modes with their codes. For a 2-param paid mutation, an agent has everything needed to call it, interpret the result, and recover from errors.

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 meaning beyond the schema: it explains that `units` drives the 402 price, that a missing/under-minimum value is priced then refused with 400, and that `address` is case-insensitive and keyed. This enriches how the agent should set the params.

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 ('Adds units to an existing box's balance') with pricing inline, and immediately distinguishes itself from siblings by naming boxCreate, boxStatus, and watchList as the create/read/follow-up tools. An agent can tell this apart from boxTopUp and boxCreate 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?

Explains exactly when it's needed ('a box with none has its watches paused until this is called') and routes to alternatives: use boxCreate if 409 box_required, then boxStatus to read balance, watchList to confirm watches resumed. Exclusions (anyone may pay, not only the owner) are explicit.

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 delivers: cost is free, three alternative authorization paths are enumerated, the allowance/expiry reset semantics are spelled out, and the error surface is documented. This is unusually rich behavioral disclosure for a mutation tool.

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 purpose sentence followed by clearly labeled Cost / Inputs / Returns / Errors / Next sections. Dense but every block earns its place; nothing is 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?

With no output schema, the description supplies returns (address, accountId, fresh allowance), the single error case, and follow-up tools. Combined with the schema's auth details, an agent has everything needed to invoke this 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 100% and all three parameters (address, agentSignature, accountSignature including nested nonce/expiry/signature) are fully documented in the schema. The description's 'Inputs: address (path), the box. No body.' mostly restates the schema, so baseline 3 applies.

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 — 'Ends a box's link to its account' — and immediately distinguishes itself from siblings like boxLink ('link it again') and boxStatus. An agent can tell exactly what this operation does without opening the 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?

The 'Next' block routes the agent to boxStatus (read allowance) and boxLink (re-link), and the error case 404 link_not_found defines the condition under which the tool is pointless. It does not explicitly frame when-not-to-use, but the surrounding context 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?

With no annotations, the description carries the full burden and mostly succeeds: it discloses cost (free), inputs (none), and a detailed returns inventory, and 'reports whether the service is up' clearly implies a non-destructive read. It does not mention auth requirements, rate limits, or failure/error behavior, which keeps it short of 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?

One lead sentence followed by tight, labeled bullets for cost, inputs, returns, and next steps. Zero filler and every line 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?

No output schema exists, so the description compensates by enumerating the return payload (DB import health, rule set version, commit, cache/RPC/spend counters, payer-identity mode). For a zero-param, annotation-free health endpoint, nothing an agent needs 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 there is no parameter semantics to document; the description's explicit 'Inputs: none' matches the empty schema. Baseline 4 applies for a 0-param tool.

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: reports whether the service is up, plus diagnostics. No sibling tool does anything similar, and the one-line summary front-loads the purpose unambiguously.

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 'Next' bullet gives clear context (call this before starting a trade via tradeSearch), and the zero-cost note signals it is safe to call freely. It does not state any when-not or alternatives, but no alternative exists among the siblings.

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: 0.01 USDC x402 cost with payer identity constraints, ARCGATE-KEY free-tier semantics and lapse behavior, the one-time-only secret exposure, the untrusted-content/prompt-injection warning, and enumerated error codes (401/403/409). This is exactly the behavioral context an agent needs before invoking.

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 core one-line purpose and organized under bold Cost/Inputs/Returns/Errors/Next headers, which is well-structured for a complex tool. It loses a point for redundancy — the 0.01 USDC price and payment mechanics are restated at both the top and the closing paragraph.

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 tool with no output schema, the description fully covers the return value (id, url, secret with a store-it warning), the prerequisites (box must exist), cost/auth modes, and failure modes. Nothing an agent needs to call 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?

Schema coverage is 100% and the single parameter is fully documented in the schema, including the pattern and 'any letter case' note. The description's 'Inputs' line largely restates the schema (address path, no body) rather than adding new semantics, so the 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 concrete verb and resource: it creates a URL where outside services post messages to the box. This is immediately distinguishable from inboundList/inboundRotate/inboundDelete and from webhookCreate-style siblings because it names the exact artifact produced (an inbound address with id, url and secret).

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?

Provides real routing context: the box must exist first (`boxCreate`), the 10-address limit implies deleting via `inboundDelete`, and the 'Next' block names the relevant siblings. It stops short of an explicit 'use this instead of webhookCreate/telegramCreate when...' comparison, so it lands at 4 rather than 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 burden and does so: it discloses cost (free), two auth paths (agent signature over a specified method/path/bodyHash, or an ARCGATE-KEY with its grace-period behavior), the 404 inbound_address_not_found semantics, and crucially that already-stored messages survive deletion.

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?

Bold-labeled sections (Cost, Inputs, Returns, Errors, Next) make it front-loaded and scannable, and nearly every sentence carries actionable content. The signature/cost paragraph is dense enough that it could be shared documentation, which keeps it just under a 5.

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?

The tool has no output schema, and the description compensates by naming the return payload (`deleted` and `id`) and the persistence guarantee for stored messages. Auth, errors and follow-up are all covered, so 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 description coverage is 100%, so the schema already documents address, id and the signature object in depth. The description adds only that they are path inputs and where the id originates, which is marginal value over the structured fields. Baseline 3 applies.

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 ('Deletes one of the box's inbound addresses') and immediately disambiguates the effect ('A post to it is a 404 from then on'), which cleanly separates it from inboundCreate, inboundList and inboundRotate. An agent can pick it out without opening the 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 operational context and a 'Next' section routing to inboundCreate for recreating an address, plus the note that the id comes from create/list. It lacks an explicit when-not-to-use (e.g. inboundRotate vs delete), so it falls 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 burden and does so richly: it declares the call is free, details the exact signing scheme (method, path, no body) and the ARCGATE-KEY alternative, explains which keys do and don't apply, and notes the key survives account lapse. It also discloses that the return never includes the secret and is ordered oldest-first.

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 purpose is front-loaded in the first line, and the Cost/Inputs/Returns/Next structure makes it scannable. It is dense and the auth paragraph overlaps somewhat with the schema's signature description, but nearly every sentence carries non-redundant routing or behavioral 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?

There is no output schema, so the description correctly explains the return shape (`addresses` with `id`, `url`, `createdAt`, oldest first, never a secret). Combined with full auth and cost disclosure, an agent has everything needed to call this tool 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 100%, so the schema already fully documents both `address` and `agentSignature` with patterns, constraints, and signing semantics. The description only restates `address` (path), adding no syntax or format detail beyond what the schema provides, so the baseline of 3 applies.

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: 'Lists the box's inbound addresses with their urls.' The 'Next' section names the sibling tools (inboundCreate, inboundRotate, inboundDelete) and their distinct purposes, so an agent can distinguish this read-only listing from the mutation 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?

The 'Next' block routes the agent to the correct alternative for creating, rotating, and deleting addresses, giving clear context for which sibling handles which action. It stops short of an explicit 'use this when you want to enumerate addresses' statement, but the routing is strong and unambiguous.

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 thoroughly: old secret stops working immediately, secret shown only now, cost is free, detailed signing/auth requirements, 401/404 cases, and the ARCGATE-KEY alternative. Rich behavioral disclosure.

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?

Well-structured with front-loaded purpose and labeled bullets (Cost, Inputs, Returns, Errors, Next). Slightly verbose on signing details, but each section is purposeful and scannable.

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, but the description fully covers return values (id, url, new secret and its one-time visibility), errors, and auth. An agent has 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%, so the schema already documents all three parameters. The description adds that address and id are path params, no body, and that the path in signature uses the lowercased address—useful but marginal against the exhaustive 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 verb and resource: 'Replaces the secret of one of the box's inbound addresses.' This is unambiguous and distinguishable from siblings like inboundCreate/inboundDelete/inboundList.

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?

Provides a useful 'Next' pointer to inboundList and hints at use ('give it to your senders'), but does not explicitly state when to rotate vs. using inboundCreate/inboundDelete or any preconditions beyond signing.

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: cost (free), the exact signing scheme (typed data fields, domain, origin binding), the one-time visibility of the returned secret, and the concrete failure mode (404 account_not_found with the fix, accountCreate). It also notes the key is never charged on a missing signature.

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 one-line purpose, then bolded sections (Cost, Inputs, Returns, Errors, Next) that let an agent skip what it does not need. The signature paragraph is dense and long, but given zero annotations that detail is load-bearing rather than 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?

No output schema exists, so the description supplies the return shape (id, label, key, createdAt) itself. Combined with cost, auth, error and next-step coverage for a 3-param nested-object tool, nothing an agent needs to call 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?

Schema coverage is 100%, so the baseline is 3; the description goes beyond it by specifying that address is case-insensitive and that the signed path must have the address lowercased, plus the canonical-JSON bodyHash rule. That materially clarifies how agentSignature must be constructed, which the schema only gestures at.

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 ('Makes another key for the account') plus a critical behavioral fact ('The key is shown once'). It is clearly distinguishable from keyList/keyRevoke by the 'Next' pointers, but it never explicitly contrasts itself with keyRotate, the nearest sibling that also produces a key.

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?

States the selection condition crisply: this is authorized only by an owner signature and explicitly NOT by the ARCGATE-KEY header ('a call with only a key is a 401 signature_required'). The 'Next' section routes to keyList and tradeSearch. It stops short of saying when to prefer this over keyRotate, which is the one sibling an agent could confuse it with.

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 declares the call is free, names the exact signing contract (method, path with lowercased address, empty body hash), states which credential does NOT work, and enumerates the failure modes (401 signature_required, 404 account_not_found). That is far more behavioral context than a typical read tool provides.

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?

Bulleted sections (Cost/Inputs/Returns/Errors/Next) are front-loaded with the purpose and scannable. There is mild duplication of the signing contract between the top-level description and the agentSignature property description, but each block still carries distinct operational 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?

There is no output schema, so the description correctly compensates by describing the return payload ('keys, oldest first', with id/label/createdAt/lastUsedAt and null-for-unused semantics). Combined with error enumeration and signing details, an agent has everything needed to invoke and interpret this tool.

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. The description adds meaning beyond the schema by specifying that `address` is accepted in any letter case and, more importantly, that the request `path` must use the lowercased address — a signing requirement not derivable from the schema alone.

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 opening sentence gives a specific verb and resource ('Lists the account's keys') plus the exact fields returned, and immediately adds a scope constraint ('A secret is never listed') that an agent needs. It is trivially distinguishable from keyCreate/keyRotate/keyRevoke 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?

The 'Next' section routes the agent to keyRotate and keyRevoke, and the 404 bullet routes it to accountCreate. The Cost bullet also states the auth condition explicitly ('ARCGATE-KEY does not authorize it: a call with only a key is a 401 signature_required'). It stops short of a general when-to-use/when-not statement, but the alternative routing is unusually concrete.

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 delivers: it discloses that the key is permanently invalidated, that all linked boxes are unlinked with fresh allowances, that the operation is free, that it requires an owner EIP-712 signature (not just the ARCGATE-KEY header), and it enumerates specific error cases. This is thorough behavioral disclosure.

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 and structured with clear bullet points for cost, inputs, returns, errors, and next steps. Despite its length, every section adds necessary information for a complex operation, with no wasted 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?

Given the complexity of a signed deletion with side effects, no annotations, and no output schema, the description provides everything an agent needs: what happens to the key and boxes, authentication requirements, exact signing payload, error conditions, and follow-up actions. Nothing critical 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 meaningful context beyond the schema: it states that address and id are path parameters and that there is no request body, and it specifies the exact method (DELETE) and path pattern needed for the agentSignature, which is critical for correctly constructing the signature parameter.

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 opens with 'Deletes a key' – a specific verb and resource – and immediately clarifies the consequence (401 key_invalid from the next call) and side effect (linked boxes unlinked). This distinguishes it from keyCreate, keyList, and keyRotate without ambiguity.

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 'Deletes a key', and a follow-up is suggested ('keyCreate: make another key'), but there is no explicit guidance on when to use this versus keyRotate (which likely replaces a key) or other alternatives. An agent must infer the use case from the name and description alone.

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 delivers: it is free, it requires an owner EIP-712 signature (not the ARCGATE-KEY header, which yields 401 signature_required), the old secret dies immediately over both HTTP and MCP, lastUsedAt is null until first use, and it enumerates both 404 error codes. This goes well beyond what any caller could infer.

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 core behavior is front-loaded in the first sentence, then organized into tight labeled sections (Cost, Inputs, Returns, Errors, Next) so an agent can scan to the section it needs. Length is justified by the absent annotations and no wasted prose.

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 signed mutation tool with three parameters, a nested signature object, and no output schema, the description covers inputs, return value (id, label, new key shown only once), cost, authorization, and failure modes. Nothing an agent needs to call 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?

Schema description coverage is 100% and the agentSignature nested object is exhaustively documented in the schema, so the baseline is 3. The description adds operative detail the schema does not surface as prominently: address and id are path parameters, there is no body, and therefore the bodyHash is the hash of no bytes — all of which determine how the signature must be built.

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 opening sentence gives a specific verb (rotate/replace the secret) and resource (key), and critically distinguishes the operation from keyRevoke by stating the id and label are preserved. An agent can tell it apart from keyRevoke and keyCreate 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?

The description establishes clear context for when to use it (replace a compromised or stale secret while keeping the key's identity) and provides a follow-up route ('Next: keyList'). It stops short of explicitly naming keyRevoke or keyCreate as the alternatives to pick instead, so the when-not guidance is left to 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 so: it declares the call free, states the exact EIP-712 domain, path-lowercasing and no-body hashing rules, says the current owner's signature yields 401 invalid_signature and a key-only call yields 401 signature_required, and enumerates every failure mode including the subtle replaced-proposal case.

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?

Long, but organized under Cost/Inputs/Returns/Errors/Next headings with the core action front-loaded in the first sentence. Some signing detail in the Cost bullet is duplicated verbatim in the schema's agentSignature description, which costs it the top mark.

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?

Despite having no output schema, the description lists the return fields (accountId, owner, previousOwner), explains the notices channel, and fully covers the state outcome (account keeps its id, keys, boxes, units and credit) plus the error taxonomy. Nothing an agent needs to call or interpret 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?

Schema description coverage is 100%, so the schema already documents both the address path parameter and the nested agentSignature object in depth. The description's Inputs bullet ('address, the account's current owner, any letter case. No body.') largely restates the schema, adding only the no-body confirmation; baseline 3 applies when the schema does the heavy lifting.

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: 'Takes over an account its owner proposed to your address.' That is precisely distinguishable from the sibling ownerTransfer, which proposes the transfer rather than accepts it, and the description makes the accepting party's role 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 precondition is unambiguous (a pending transfer proposed to the signing address, otherwise 404 transfer_not_found), and the Next section routes the agent to accountStatus and keyList afterwards. It stops short of naming ownerTransfer as the counterpart tool, so the when-to-use framing is contextual rather than explicit.

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 declares cost (free), that ARCGATE-KEY alone yields a 401 signature_required, the exact signing target (method/path/body), the expiry window via account.transfer.days, and the nonce-reuse rule. Specific failure codes (404 account_not_found, 409 account_exists) and the one-account-per-address invariant are disclosed up front.

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 core behavior, then organized into Cost/Inputs/Returns/Errors/Next with bolded labels. The length is justified for a signing-required mutation with no annotations and no output schema; the only minor redundancy is the repeated 401 signature_required mention.

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, and the description compensates by enumerating the return fields (accountId, owner, newOwner lowercased, expiresAt) and its semantics. Combined with errors, cost, and the follow-up tools, nothing an agent needs to call or interpret 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 description coverage is 100%, so the schema already documents address, newOwner and the nested agentSignature fields. The description's Inputs section largely restates that ('any letter case', 'the address to move the account to'), adding little beyond it. Baseline 3 is appropriate where the schema does the heavy lifting.

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 first sentence states a specific verb and resource ('Proposes moving the account to another address') and immediately scopes it ('Nothing moves until that address accepts with ownerAccept'). This distinguishes it from the sibling ownerAccept, which is the completing step rather than the proposing step. An agent can select it without opening the 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?

The two-phase workflow is explicit: this proposes, ownerAccept commits, and accountStatus reads. It also states the replacement rule ('a second proposal replaces the first, which is how a mistyped address is fixed'), giving the agent a clear condition for re-invoking rather than looking for an edit tool.

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 present, the description carries the full burden and does so richly: x402 pricing (0.01 USDC), who may pay, the ARCGATE-KEY free/paid transition, the one-time secret code with its 900-second expiry, and a prompt-injection warning that message content is untrusted. It also enumerates five specific error codes with causes.

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?

Long but well structured with bold section headers (Cost, Inputs, Returns, Errors, Next) and bullets, so an agent can scan to the relevant part. It loses a point for a slightly indirect opening sentence and for repeating the price at the very end after already stating it under 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?

For a paid mutation tool with no output schema and no annotations, the description is complete: it documents inputs, the full return payload, the payment channel (params._meta["x402/payment"]), and the error taxonomy. 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?

Schema description coverage is 100%, so the schema already documents both `address` (pattern, signing requirement) and `filter` (full enum semantics), making 3 the baseline. The description adds only marginal value, restating that `address` is path-style/any letter case and that `filter` is optional; the substantive filter semantics live in 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?

The name telegramCreate plus the Returns section ('the channel's `id`, a one-time link `code`...') make it clear the tool creates a Telegram channel for a box, and it is cleanly distinguished from telegramList/telegramLink/telegramDelete. However, the opening sentence describes the created channel's push behavior ('Sends each message of the box its `filter` takes...') rather than stating the create action explicitly, so the verb is inferred 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?

A dedicated 'Next' section routes the agent to telegramList, telegramLink and telegramDelete, and the error list supplies explicit when-not conditions with alternatives (409 telegram_limit: 'Delete one first'; 409 box_required: 'create the box first (boxCreate)'). The relationship to sibling tools is fully spelled out.

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 exist, so the description carries the full burden and does so: cost is free, two alternative auth mechanisms are spelled out (signed DELETE over a named method/path with no body, or an ARCGATE-KEY scoped to the linked account), key-invalidity and lapsed-grace behavior are disclosed, and the irreversibility ('the price of the channel is not refunded') and residual state ('Messages stay in the box') are explicit.

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 one-line purpose, then organizes cost, inputs, returns, errors, and next steps as labeled bullets – every block is scannable. It is dense and somewhat long, but the density is justified by a non-obvious dual-auth scheme that would otherwise be misfired.

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 still supplies the return shape ('deleted' and the id), the single relevant error (404 telegram_not_found with its three causes), the auth preconditions, and the follow-up tool. Nothing needed 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?

Schema description coverage is 100%, so the schema already explains the address, id pattern, and the full agentSignature structure. The description's 'Inputs: address and id (path)' only restates what the schema says, so baseline 3 applies.

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 ('Deletes one of the box's Telegram channels') and immediately bounds the effect ('Nothing more is sent to its chat'). An agent can distinguish it from telegramCreate and telegramList 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 operational context: it is free, which auth path applies, and routes forward with 'Next: telegramCreate: make a new channel (paid)'. It does not, however, contrast deletion with the sibling telegramLink (unlinking/keeping the chat), which is the closest ambiguous alternative for a 'remove a Telegram thing' intent.

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 thoroughly: cost (free), the exact signing scheme (method POST, path, no-body hash), the ARCGATE-KEY alternative and its limits (another account's key does not apply; a key for an unlinked box does not apply; key survives account lapse), the destructive-ish side effect that any earlier code stops working, and the resulting state change when the code is sent to the bot (links chat, enables channel, clears failure count). Errors 404 telegram_not_found and 503 telegram_unavailable are spelled out.

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?

Bold section labels (Cost, Inputs, Returns, Errors, Next) front-load the purpose and make scanning easy. The auth paragraph is dense and long, but nearly every clause is load-bearing for a signature-gated endpoint; only minor tightening is possible.

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, yet the description enumerates the return fields (id, code, t.me link, expiresAt), warns the code is a one-time secret, and covers the two documented error cases plus the follow-up tool. Combined with the full auth model, an agent has everything needed to call and interpret this 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 already 100%, so the baseline is 3. The description adds call-time framing the schema scatters elsewhere: it names 'address' and 'id' as path parameters and states explicitly there is no body, which is directly useful when assembling the signed request.

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 — 'Issues a new one-time link code for one of the box's Telegram channels' — plus the trigger scenario ('to link a chat again after /stop, a block or a disable'). This clearly separates it from telegramCreate, telegramList and telegramDelete without needing to open 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 an explicit when-to-use condition (re-linking after /stop, a block, or a disable) and a concrete follow-up step pointing at telegramList to verify 'linked: true'. It does not explicitly exclude or contrast against telegramCreate for first-time linking, so it stops just short of a full 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 burden and delivers: it declares the call free, spells out the two auth paths (EIP-712 signature vs ARCGATE-KEY), notes that a wrong or unlinked key degrades to needing a signature, warns of the 401 key_invalid case, and clarifies the key survives an account's lapse. It also discloses output behavior: oldest-first ordering, filter always null, the code and chat are never returned, and linked:false conflates three distinct states.

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 purpose, then bolded sections (Cost, Inputs, Returns, Next) that make scanning easy. It is long and the auth paragraph substantially overlaps the schema's agentSignature description, so some sentences are redundant, but each section is information-dense rather than padded.

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, yet the description enumerates the returned fields, ordering, and the meaning of the ambiguous linked:false flag, and it covers cost and both auth modes. Nothing an agent needs to invoke or interpret this call 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 description coverage is 100% and the nested agentSignature object is exhaustively documented, so the schema already does the heavy lifting. The description restates 'address (path)' and repeats auth behavior that the schema also covers, adding little parameter-specific meaning beyond what is structured.

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 ('Lists the box's Telegram channels') plus the returned scope ('with their state'), and the 'Next' section names the sibling tools (telegramLink, telegramCreate) it is not. An agent can distinguish it from telegramCreate/telegramLink/telegramDelete 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?

The 'Next' section routes the agent to the right follow-ups (get a new link code via telegramLink, make a new channel via telegramCreate) and labels telegramCreate as paid, giving clear context. It stops short of an explicit 'use this when you need X, not Y' exclusion, so it is clear context rather than full when/when-not 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 behavioral burden and does so thoroughly: it discloses cost, x402 payment flow, quote TTL, stored quoteId behavior, safety verdicts, readiness checks, stale-quote behavior, and nuanced inconclusive/high-tax/launch-window handling. It also explains downstream tradeSwap refusals such as 422 exit_risk_high and 422 sell_unverified.

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 definition is front-loaded with purpose and is structurally organized into Inputs, Returns, Errors, and Next. It is necessarily long for a complex quoting tool, but there is some redundancy, notably the payment/cost explanation repeated at the top and bottom.

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?

Given the lack of annotations and output schema, the description is unusually complete: it covers inputs, return shape, errors, quote lifecycle, readiness, safety checks, and agent routing decisions. An agent has enough information to call tradeQuote correctly and understand follow-up actions.

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 schema already documents all 14 parameters. The description adds useful semantic context beyond the schema, especially taker readiness, quote TTL/expiry, and exitRisk policy interaction with next, though it does not add meaning for every parameter.

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 opening sentence states a specific verb and resource: pricing a swap between two tokens across indexed venues and storing it as a quoteId. It clearly differentiates the quote from tradeSwap and mentions tradeSearch/tradeVenues for resolving inputs.

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 explicitly routes the agent: use tradeSwap when next is swap, stop when next is stop, requote when next is requote, and use tradeSearch or tradeVenues to fix bad inputs. It also explains when stop and requote conditions apply, including the two-quote rule for requote.

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 and does so richly: it discloses rate limiting (one chain read per quote every 5 seconds), a hard lifetime cap (132 reads, exhausted 'for good'), 404 semantics tied to tradeSwap's one-hour window, and the caveat that Safe/ERC-4337/EIP-7702 senders will trip a 400 because they send from elsewhere.

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 one-line purpose, then labeled bullets for Cost, Inputs, Returns, Errors, and Next. The length is justified because it compensates for the absence of both annotations and an output schema; nothing is redundant or 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?

With no output schema, the description fully specifies the return value (`result`, `delivered` vs `minAmountOut`, per-transaction `status`, `reason`, and `next`) as well as every error code. Nothing an agent needs to call and interpret this tool 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 schema already documents both parameters; the description nonetheless adds real meaning by framing `txHashes` as the 1-4 transactions the caller sent (swap plus approvals) and by surfacing the wallet-type edge case where a hash legitimately will not belong to the quote's taker.

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 opening sentence names a specific verb and resource — verifying that a sent swap delivered what the quote promised — and immediately scopes it as read-only ('It only reads the chain'), which cleanly separates it from the write-oriented siblings tradeSwap/tradeSwapTx. An agent can distinguish it from tradeQuote and tradeSwap 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?

The 'Next' section gives explicit routing: follow the `next` field, and when it equals `requote`, call tradeQuote. Error blocks tell the agent exactly what each failure means and how to react (wait `retryAfterSec`, resend the same `txHashes`, or stop), including the terminal condition when reads are exhausted.

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 paid access (0.005 USDC via x402, ARCGATE-KEY header alternative), a concrete error taxonomy (404 token_not_found, 429 lookup_rate_limited with retryAfterSec, 503 rpc_unavailable), and the lookalike-impostor caveat. It stops short of covering caching, result stability, or whether params._meta payment is validated before or after the lookup.

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?

Bold-labeled sections (Cost, Inputs, Returns, Errors, Next) make it skimmable and the purpose is front-loaded. The closing paragraph partly re-states the cost bullet ('Costs 5000 base units (0.005 USDC) per call'), which is mild duplication, though it does add the header-based payment detail and the docs link.

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 4-parameter tool with no output schema and 50% schema coverage, the description supplies the return-field semantics (verification status, safety verdicts, pools, `launch`, `exitRisk` in basis points and separate from the safety sell-check, plus its `limitations`), the cost/payment path, errors, and the follow-on call. The set is coherent and near-complete; only edge behaviors like retry/pagination are absent, and the 25-result cap leaves little ambiguity there.

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% (`query` and `limit` are undocumented in the schema), so the description must compensate, and it does: it restates `query` as a flexible resolver over ticker/name/prefix/0x address and pins `limit` to 1-25 with default 10. It also clarifies that filters narrow `results` only while ranks/flags are computed over the unfiltered match set, adding real semantics about how the filters interact with output.

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 first sentence states a specific verb and resource ('Resolves a ticker, name, prefix or `0x` address to candidate ERC-20 tokens on Arc'), and the 'Next' section separates it from the pricing sibling by naming `tradeQuote` as the follow-on step. An agent can tell this is the discovery/lookup tool rather than the quote or swap tool 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?

The 'Next' section gives clear routing ('tradeQuote': price a swap with the chosen result's `address` as `sell` or `buy') and the Returns section instructs 'Check verification and safety before you trade,' establishing when to use it. It does not explicitly state when *not* to call it, but the sibling hand-off makes the intended position in the workflow unambiguous.

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: per-call x402 cost tiers, one-charge-per-quote rule, the persistence of an unlimited Permit2 approval, the native-USDC no-approval path, and a complete error taxonomy with charges and stop conditions. This is the kind of detail an agent cannot get from any structured field.

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?

Well front-loaded with bold section headers (Cost, Inputs, Returns, Errors, Next) and dense bullets. However, the cost tier table is restated almost verbatim in the closing paragraph, which is pure duplication and adds length without new 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 no-output-schema, paid, multi-step swap tool, the description covers inputs, returns, cost, payment channel, all failure modes with their recovery actions, and the follow-up calls. Nothing an agent needs in order to invoke or recover from this tool 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 baseline is 3, but the description adds real meaning: it enumerates which parameters are required vs optional and warns that `permit` is invalid here (400 invalid_request), steering the agent away from a plausible mistake. It does not add syntax beyond the schema, hence not a 5.

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: 'Turns a stored quote into unsigned transactions for the taker to sign and send', and immediately scopes arcgate's role ('never signs, broadcasts or holds funds'). This clearly separates it from tradeQuote (creates the quote), tradeSwapTx (signs the permit) and tradeReceipt (confirms the fill), all named in the description.

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 routing: 'tradeSwapTx: when next is sign_permit' and 'tradeReceipt: when next is send', plus the precondition that a stored quote must exist. It also names an alternative tool for the permit step and says never to pass `permit` here, giving both when-to-use and when-not.

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 delivers: cost is free, the round can be used once, an attempt cap of 5 failed calls (429), quote liveness constraints, and a security warning ('Read what you sign'). The error catalogue discloses exactly which preconditions must hold and what each failure means.

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 one-line lead sentence states the purpose up front, and the bulleted Cost/Inputs/Returns/Errors/Next blocks are tightly scoped with no filler. Long but every section earns its place and is easy to scan.

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?

Although there is no output schema, the description explains the return value ('transactions to send in order' with 'next is send'), covers the flow position, and enumerates failure modes for a 5-parameter nested-object tool. 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning by stating the parameters must mirror the earlier tradeSwap call and that permit is composed of 'message from signatures[0].typedData' plus the signature over it. This clarifies provenance that 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?

The opening sentence gives a specific verb and resource ('Finishes a tradeSwap call that asked for a Permit2 signature') plus the concrete outcome ('returns the transactions ready to send'). It clearly distinguishes this completion step from the sibling tradeSwap that it follows.

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 explicitly frames this as the second half of a tradeSwap flow and routes the agent on failure: 'Call tradeSwap first' for no_pending_swap, 'call tradeQuote' for stale/expired quotes, and 'tradeReceipt' as the next step after sending. When to use it and what to do instead is fully specified.

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 cost (Free), that there are no inputs, and the shape of the return (`executable` flag per venue). It does not mention auth/permission requirements or caching, but for a free read-only listing this is largely adequate.

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 one-line purpose followed by tightly labeled Cost/Inputs/Returns/Next bullets. Every line earns its place and nothing is padded.

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 listing tool with no output schema, the description supplies the essential context: cost, absence of inputs, return shape, and the follow-up tool to call. Nothing needed 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 tool takes zero parameters, so the baseline of 4 applies; the description correctly confirms 'Inputs: none' so the agent knows nothing needs to be supplied.

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 names a specific verb (Lists) and three concrete resources (DEX venues, hub tokens, launchpads) scoped to 'this deployment indexes'. No sibling tool lists venues, so the agent can distinguish it immediately from tradeQuote/tradeSwap etc.

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 clearly states the workflow context by naming tradeQuote as the next step and explaining exactly how to pass the returned ids as `venues` or `excludeVenues`. It stops short of explicit when-to-use/when-not-to-use framing, but the routing guidance is strong.

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 exist, so the description carries the full burden and does so unusually well: exact price (0.01 USDC over x402), who may pay, how ARCGATE-KEY makes a call free and when it stops being free, per-box caps (20 watches, 5 screens, 5 agent screens, downgraded-tier caps), and clause constraints that silently never fire. The untrusted-third-party warning on message content is a genuinely valuable safety note. It loses a point only because polling/cooldown cadence and delivery timing are left 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?

Long but entirely structured: cost, inputs, returns, errors, next steps, each front-loaded with a bold header and scannable bullets. Given the complexity of a paid, four-shape watch create, essentially every sentence earns its place; the only waste is restating the 10000 base-unit price at the end.

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 tool with a deeply nested union condition, no output schema and no annotations, the description covers returns (id, condition, createdAt), the full error catalogue with remediation, quota limits, and payment mechanics. 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?

Schema coverage is 100%, so the baseline is 3, and the description adds meaning beyond it: `address` is the box's address in any letter case and must be the payer, and `condition` is one of four discriminated shapes whose clauses are enumerated with cross-cutting rules (a `lookalikes` clause is a token watch's only clause; `pools changes` never holds on a pinned asset). It does not, however, walk through the `on` and `where` semantics that 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?

Names a specific verb (create a watch) and the four condition shapes (token watch, screen, agent screen, agent watch), and adds the side effect that a message lands in the box when it fires. An agent can distinguish watchCreate from watchList/watchDelete without opening either 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 real routing guidance: 409 box_required tells the caller to run boxCreate first, 404 agent_not_found points at agentSearch for the ID, and the Next block names watchList, watchDelete and boxMessageList. It stops short of an explicit 'use this instead of X' exclusion, but the surrounding workflow 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?

With no annotations, the description carries the full burden and delivers: cost is free, two auth paths (agent signature vs ARCGATE-KEY), the exact signed path/method/bodyHash, and that a lapsed account's key still works. It also discloses that stored messages are retained and the watch price is not refunded — substantial behavioral context beyond structure.

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 core purpose, then organized into Cost/Inputs/Returns/Errors/Next sections with zero filler. Some auth detail duplicates the signature schema description, slightly inflating 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?

No output schema exists, yet the returns are explicitly described (deleted and id), errors are enumerated (404 watch_not_found with causes), and the follow-up tool is named. An agent has everything needed to 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 coverage is 100%, so parameters are already well documented; the description nonetheless confirms address and id are path parameters and explains the request path construction. Adds meaningful framing over 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 and resource ('Deletes one of the box's watches') and adds the key consequence ('It never fires again'). An agent can distinguish it from watchCreate and watchList 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?

Frames the tool as removing an existing watch and points to watchCreate as the inverse, with the '(paid)' note for creation. There is clear context but no explicit when-not guidance (e.g., versus leaving a watch running).

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 and delivers: it is free, authenticates via an agent EIP-712 signature over GET with no body, or an ARCGATE-KEY of the linked account, with explicit failure modes (401 key_invalid, signature_required, nonce_reused) and the note that a lapsed account's key still works during grace. It also discloses ordering ('oldest first').

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 summary sentence, then tightly organized Cost/Inputs/Returns/Next bullets. It is long and the signing mechanics partially duplicate the agentSignature schema description, but every section is purposeful and skimmable.

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, yet the description specifies the returned watch fields and ordering. Auth requirements, cost, failure modes and next steps are all covered, so an agent has 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 description coverage is 100%, so the schema already documents address and the full agentSignature object. The description only notes that address is a path input, adding nothing the schema does not already carry. 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 first sentence states a specific verb (lists), resource (the box's watches) and returned fields (conditions, last-fired time). It names the sibling tools watchCreate and watchDelete, so an agent can distinguish it from them immediately.

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 'Next:' block explicitly names watchCreate (make a new watch, paid) and watchDelete (delete a watch), routing the agent to the right alternative. It does not spell out a when-not-to-use condition, but the alternatives and their roles are 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?

No annotations are provided, so the description carries the full burden and does so: x402 pricing (0.01 USDC), who may pay, the key-based free path and its expiry behavior, the one-time-only `secret` disclosure, the ownership-challenge requirement before delivery, and the 5-channel limit. It also flags the message payload as untrusted third-party data never to be followed as instructions.

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?

Bold section headers (Cost, Inputs, Returns, Errors, Next) make it skimmable and front-loaded, and most sentences earn their place. There is minor redundancy between the Cost bullet and the trailing 'Costs 10000 base units (0.01 USDC) per call' paragraph, which repeats the price.

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 paid, mutating, multi-error endpoint with no output schema, the description supplies return fields (id, url, secret, filter, createdAt), all four error codes with meanings, payment integration detail, and prerequisite/limit behavior. Nothing an agent needs to call it correctly appears to be 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 already 100%, yet the description adds the request body shape `{url, filter?}`, that url is https-only, and that a null/missing `filter` means every type. This goes beyond the schema field text, though some content (https-only, filter enum meanings) overlaps with it.

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+resource ('Pushes each message of the box its `filter` takes to an https URL') and states the outcome ('so the agent need not poll `boxMessageList`'). It is clearly distinct from webhookList, webhookRotate, webhookEnable and webhookDelete, which it names explicitly.

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 context (create a push channel instead of polling), names the conditions that change cost (own box address vs. ARCGATE-KEY during period/grace vs. lapsed), and routes to alternatives for follow-up actions (webhookList/Rotate/Enable/Delete). The 409 `box_required` message even names the prerequisite sibling boxCreate.

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 and does so thoroughly. It discloses cost (free), authentication options (agent signature or ARCGATE-KEY, with key grace behavior), the exact signing method and path, the return shape ('deleted' and 'id'), that messages stay in the box, that the channel price is not refunded, and the specific 404 error condition.

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 opening sentence front-loads the core action, and the remaining sections (Cost, Inputs, Returns, Errors, Next) are tightly organized. Despite its length, every sentence earns its place by covering authentication, error handling, and side effects that an agent needs for correct invocation. No wasted words.

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 the description must explain return values and side effects — it does ('Returns: deleted and the id. Messages stay in the box. The price of the channel is not refunded.'). It also covers authentication, cost, and the single documented error, making it complete for a delete operation with no annotations.

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 schema already documents all three parameters in detail, including nested signature fields. The description adds only a high-level summary ('Inputs: address and id (path)') and does not contribute additional syntax, format, or edge-case meaning beyond what the schema provides. 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 opens with a specific verb+resource: 'Deletes one of the box's webhook channels.' It also states the immediate consequence ('Nothing more is delivered to it') and names a related sibling ('webhookCreate') for follow-up. This distinguishes it clearly from webhookCreate, webhookEnable, webhookList, and webhookRotate.

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 gives clear context for when to use it: deleting a webhook channel and stopping delivery. It also points to the next-step alternative ('webhookCreate: make a new channel (paid)'). However, it does not explicitly state when-not to use it or compare it to siblings like webhookEnable or webhookRotate, so it falls short of full alternative routing.

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