agent-exec

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

Annotations only supply readOnlyHint=false, openWorldHint=false, and destructiveHint=false, so the description carries the behavioral burden. It discloses the paid nature, that failed or refused fetches are still billed and signed, that the body is never returned, that no account/API key is needed, and where the payment receipt appears. This is substantial behavioral transparency beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and key constraints, then covers payment mechanics and the receipt location. It is longer than average, and the final feedback sentence is peripheral to tool invocation, but nearly every sentence carries operational information that helps the agent use the paid x402 flow correctly.

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 what the tool returns: signed attestation fields, never the body. It also explains the unusual billing semantics, the two-call x402 payment protocol, the free read-back via attest_read, and the absence of authentication requirements. For a one-parameter paid tool, this is complete enough for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the url parameter, so the baseline is 3, but the description adds meaning by clarifying that the URL is fetched from the tool's vantage point, the body is never returned, and connection failures still produce a signed, billed observation. This moves beyond the schema's maximum length and protocol constraint without contradicting 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?

The description opens with a strong verb and resource: 'we fetch a URL from OUR vantage point and return a signed, timestamped attestation.' It lists concrete outputs (hash, byte count, HTTP status and headers) and explicitly excludes the body. It also distinguishes itself from the sibling attest_read by saying the result can later be read back for free with that tool.

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 clearly explains when to call this tool: to create a paid, signed attestation for a third party. It names attest_read as the read-back alternative and gives a step-by-step payment flow (unpaid call for price, paid call with _meta['x402/payment']). It does not enumerate broader when-not-to-use cases, but the context is strong enough for an agent to select the correct 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: it is free, unauthenticated, not wallet-scoped, and returns the attestation with its signature. It also discloses that no individual reply is given for feedback, which is a minor behavioral note. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The core tool behavior is front-loaded in the first sentence, and the rest adds useful context about scope and feedback routing. The feedback sentence is somewhat tangential to the tool's operation, but it is brief and does not obscure the main purpose. Overall efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple single-parameter read tool with annotations covering safety, the description is nearly complete. It explains the return value (attestation with signature), the access model (free, unauthenticated, not wallet-scoped), and the relationship to attest_create. The only minor gap is not describing the exact response format, but no output schema exists and the description gives enough for an agent 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 the single 'id' parameter. The description adds that the id is the one returned by attest_create, which is useful but not a major semantic addition beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('read'), a specific resource ('attestation'), and the retrieval key ('by id'), and explicitly contrasts itself with attest_create. It also clarifies the non-wallet-scoped nature, which distinguishes it from any wallet-scoped read siblings. This is a clear, specific purpose statement.

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 says this is how attestations created via attest_create come back over MCP, and deliberately not wallet-scoped, so a third party can fetch and verify. It also mentions the alternative for feedback (POST /feedback). This gives clear when-to-use guidance and even routes non-tool requests elsewhere.

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

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

Annotations only say readOnlyHint=false, destructiveHint=false. The description carries the full burden and does so thoroughly: explains it's paid, atomic, compare-and-set, scoped to paying wallet, outcomes 'acquired' vs 'held', and the payment/receipt mechanism. No contradictions with annotations; adds crucial behavioral context.

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?

Though long, every sentence earns its place: core purpose is front-loaded, then outcomes, sibling routing, payment flow, and feedback. No redundancy; structured logically from core behavior to supporting details.

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?

Complete for a paid, multi-step tool. Covers payment flow, outcome semantics, wallet scoping, alternatives, and feedback. No output schema exists, but description explains receipt location and outcome fields. An agent has everything needed to invoke and interpret results.

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 covers all three parameters with descriptions (100% coverage). The description adds meaning beyond schema: for 'key' it clarifies wallet scoping, for 'plan' it links duration and price, for 'holder' it explains it identifies the process and is not signed. This extra context raises it above 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 description states a specific verb and resource: 'atomically win a caller-named key' and identifies it as a paid compare-and-set lock. It distinguishes from siblings by explicitly mentioning 'PAID' and naming related tools (claim_acquire_free, claim_read, claim_release, claim_renew). The purpose is unambiguous.

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 two-step payment flow: call without payment to get price, then with signed payment. Clarifies that outcome 'held' is not an error and explains the signal to stop duplicate retries. Names sibling tools for inspection, release, and renewal, and gives feedback channel. No ambiguity about when to use this vs alternatives.

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

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

Annotations only indicate readOnlyHint=false and destructiveHint=false. The description goes well beyond that, disclosing the domain separation for signatures ('distinct from the read and release domains'), the 'unlimited distinct keys per wallet' constraint, the renewal property, and the exact mechanism to obtain the signing message (placeholder signature triggers details.expected). It does not describe response structure, but the annotations already cover the safety profile, so the added context is valuable.

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 long (~220 words) and front-loads the core purpose, but then drifts into tangential material: complaints, questions, quote requests, and the feedback endpoint, which are unrelated to tool invocation. While some extra context (domain separation, signature flow) is valuable, the marketing-style filler significantly hurts conciseness. It could be trimmed by half without losing critical guidance.

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 5-parameter, all-required tool with no output schema, the description covers the acquisition process, signature retrieval, duration, and renewal. However, it never describes what a successful response looks like (e.g., lock metadata, expiry timestamp), which an agent would need to know to confirm success. It also omits any rate limits or quotas beyond 'unlimited distinct keys.' Given the tool's moderate complexity, a 3 reflects the gap in response semantics but acknowledges the strong coverage of the invocation flow.

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 input schema covers all 5 parameters with clear descriptions (100% coverage), so the baseline is 3. The description adds one useful nuance for the signature parameter (the placeholder-signature trick to retrieve the message), but this is more about the overall flow than parameter meaning. It does not materially improve understanding of any parameter beyond what the schema already states.

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 clear, specific action: 'win a caller-named key for 300 seconds, or learn who already holds it.' This states the verb (acquire), the resource (named key), and the duration (300 seconds). It also explicitly distinguishes itself from the sibling claim_acquire, calling it 'not a discount on it' and contrasting the lease length, so an agent can tell them apart without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use guidance: 'this lease is 12x shorter than the cheapest paid plan, so a lock that has to survive a deploy, a batch or a day is on the paid ladder from the first minute.' It names the alternative (claim_acquire) and the condition that selects it (duration need), plus notes renewability. This is direct, actionable guidance with no ambiguity.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral context: it explains that a key nobody holds returns 'claim: null' rather than a not-found error, that the read signature cannot release the key, and that a placeholder signature can be used to retrieve the exact message to sign (details.expected). This goes beyond the annotations and helps the agent anticipate edge cases.

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 verbose and includes promotional content about the /feedback endpoint, which is unrelated to the tool's operation. The core purpose is front-loaded, but the additional marketing text about daily report analysis and no individual reply adds noise. While it is informative, it could be more concise without losing essential operational details.

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 description covers the key aspects an agent needs: the free nature, the wallet scoping, the null response for unheld keys, and the placeholder signature mechanism to obtain the exact signing message. It does not specify the full response structure for a held key (beyond implying a 'claim' field), but the absence of an output schema is mitigated by the description's explanation. This is sufficient for basic invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides descriptions for all four parameters (100% coverage), so the baseline is 3. The description adds extra meaning for the 'signature' parameter by explaining the placeholder approach and the exact signature formats (EIP-191 and ed25519). It also clarifies that 'key' is scoped to the user's wallet. This added detail justifies a score above 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?

The description clearly states the tool's purpose: checking who currently holds a specific key, scoped to the user's own wallet. It uses a specific verb ('holds') and resource ('key'), and distinguishes itself from sibling tools like claim_acquire and claim_release by emphasizing it is a read-only, free operation. The phrase 'scoped to YOUR wallet' also clarifies its limited scope.

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 provides context for when to use this tool: it is for checking your own key holdings and is free, explicitly noting that 'checking your own lock must not cost again'. It does not explicitly name alternative tools or state when not to use it, but the scope and read-only nature are clear. It could be improved by directly referencing siblings like claim_acquire for acquisition, but the guidance is adequate.

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

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

Annotations already mark this destructive, and the description adds rich behavioral detail beyond that: domain-separated signing, holder being separate and unsigned, refusal unless the current holder is named (CLAIM_NOT_YOURS), anti-replay nonce, server time window, and exact signature formats. This goes well beyond the annotations and does not contradict them.

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 purpose is front-loaded and the security information is valuable, but the description is bloated by an unrelated service-promotion tail about POST /feedback, no account, and daily report reading. These sentences do not help an agent invoke the tool and prevent a higher score.

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 security-sensitive mutation with no output schema, it covers the critical invocation details: how to get the exact message to sign, both signature formats, the current-holder requirement, and the failure reason. It lacks an explicit success-response description and sibling routing, but the interactive placeholder-signature flow makes it usable.

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 input schema already describes all five parameters, so the baseline is 3. The description adds meaningful semantics: signature proves the wallet but does not authorize release, holder must be the current holder, nonce prevents replay, and signedAt has a short acceptance window. This is above baseline but not exhaustive 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 description states the exact operation: 'give up a key you hold before it expires' — a specific verb, resource, and timing. This clearly distinguishes claim_release from siblings like claim_acquire, claim_renew, and claim_read, and it is not a tautology of the tool name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear usage context: use this when you hold a key and want to free it early so the next racer does not wait. It also explains the placeholder-signature bootstrap trick to obtain the message to sign. However, it never explicitly names sibling tools or states when not to use it (e.g., when you want to renew instead).

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?

Beyond the minimal annotations (readOnlyHint=false, destructiveHint=false), the description discloses substantial behavior: it is a paid x402 operation, the first call returns a PaymentRequired, the second completes with a signed payment, and the receipt returns in _meta. It also explains the 'heartbeat' design rationale and the no-account/no-API-key requirement, giving full transparency about side effects and prerequisites.

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 longer than typical but front-loaded with the core purpose and payment model. The feedback-solicitation sentence at the end is somewhat tangential to invoking the tool, yet the overall structure flows logically from what → why → how, and every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a paid multi-step tool with no output schema, the description covers the full workflow: price discovery, payment submission, receipt location, and auth requirements. It does not enumerate failure modes or edge cases, but the essential operational context is present and the complexity is well addressed.

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 schema already covers all three parameters with detailed descriptions, so the baseline is 3. The description adds a small amount of extra meaning by linking the 'plan' parameter to the pricing table via GET /pricing or service_card, but it does not materially enhance understanding of 'key' or 'holder' 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?

The description opens with a specific verb and resource: 'extend a hold you already have without losing your place in line'. It clearly distinguishes this from claim_acquire by stating that re-acquiring does NOT extend, so an agent can identify the exact operation and differentiate it from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly explains when to use this tool (extending an existing hold) and notes that claim_acquire deliberately does not extend, warning against using the wrong sibling for renewal. It also outlines the required two-step payment flow, so an agent knows exactly how to sequence calls.

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

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

Annotations are minimal (readOnlyHint=false, destructiveHint=false), so the description carries the burden. It discloses key behaviors: the tool is free, it refuses (never a silent no-op) when the entry is no longer pending, and it explains the rationale (preventing overwrite of probe verdicts). It also reveals the authorization model (id possession is sole auth). This exceeds what annotations provide and gives the agent a complete picture of side effects and guarantees.

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 compact but information-dense. It front-loads the core action in the first sentence, then adds crucial caveats (authorization, refusal behavior), and ends with an unrelated feedback note. While the feedback note is tangential, it is brief and clearly separated. The structure is logical and not wasteful, though slightly longer than strictly necessary for calling the tool. A 4.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description covers all essentials: purpose, authorization, refusal conditions, and even the rationale. An agent knows exactly when to call it, what to expect (it may refuse), and that it is free. No critical information is missing; the description is fully self-contained for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single parameter 'id', which is described as 'The entry id returned by deadman_register.' The description adds important semantic context: 'possession of the id is the entire authorisation,' clarifying that the id alone is the credential. This goes beyond the schema's simple description, enriching the agent's understanding of how to handle the id securely. Thus a 4 rather than 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 description opens with a clear, specific statement: 'FREE: the live caller closes the loop before the lease expires, so the probe never runs.' This defines the action (close the loop) and the resource (an intent/deadman entry), distinguishing it from siblings like deadman_register (creates) and deadman_read (reads). It also clarifies the scope ('Deliberately NOT wallet-scoped') which differentiates it from other tools in the set.

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 implies when to use this tool: when the live caller wants to confirm before lease expiration. It explicitly notes the authorization model ('possession of the id is the entire authorisation') and the refusal condition ('Refused, never a silent no-op, once the entry has left pending'), giving clear behavioral guardrails. However, it does not explicitly name alternative tools or state 'use this instead of X', relying on the natural contrast with siblings. This is a minor gap, so 4.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds important behavioral nuance: the tool may execute a live probe synchronously as part of the read, 'each entry can trigger at most one live probe, ever,' and it is unauthenticated and free. This goes well beyond the annotations and clarifies a non-obvious side effect.

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 is front-loaded and effective, clearly stating the action and key conditions. However, the later sentences about feedback submission, daily review, and absence of individual replies are unrelated to invoking this tool and dilute the description. The core behavioral content could be stated in two 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?

For a single-parameter read tool without an output schema, the description sufficiently explains the return contents (verdict and raw probe response) and the important live-probe trigger condition. It lacks detailed return structure but is adequate for correct invocation; the missing details are more relevant after the response is received.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'id' is fully described in the schema as 'The entry id returned by deadman_register,' giving 100% coverage. The description reinforces that the id comes from deadman_register but does not add further semantic detail, so it meets the baseline without exceeding 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?

The description states a specific verb and resource: 'read an entry back by id, including its verdict and the raw probe response.' It also explicitly ties the tool to deadman_register ('what you bought with deadman_register comes back over MCP'), which distinguishes its purpose from sibling read 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?

The description gives clear context for when to use this tool, namely after deadman_register and to retrieve an entry's verdict. It also describes the special edge case where a live probe may run synchronously. It does not explicitly name alternatives or state when not to use it, but the context is sufficient for an agent to select 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?

The annotations provide only readOnlyHint=false and destructiveHint=false, which are vague. The description compensates richly: it discloses the tool is paid, that the probe runs after lease expiry, that verdicts can be 'unresolved' when the probe cannot complete (explicitly never guessed as refuted), and that the raw probe response is published for verification. It also states there is no account or API key required and mentions the feedback channel. This is far beyond what annotations convey.

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 long, but it packs necessary information for a complex paid tool: payment flow, probe semantics, verdict outcomes, verification path, and feedback. The first sentence states the core purpose immediately, and each subsequent sentence adds a distinct, non-redundant detail. It is not needle-some, but the length is justified by the tool's complexity. Slightly shorter would be ideal, but it is still well-structured.

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 that involves irreversible intent, a lease, a probe, and payment, the description covers all essential aspects: the two-step payment flow, the lease semantics, the probe execution, the three possible verdicts including the honest 'unresolved' case, the raw response publication, and the feedback loop. It references sibling tools (deadman_confirm, deadman_read) appropriately. No output schema exists, but the description tells the user the receipt appears in _meta['x402/payment-response'], which is sufficient. I see no gaps that would prevent correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so each parameter has a description in the schema (e.g., url, leaseSeconds range, expectedStatus). The main description adds meaning beyond these: it explains the probe is 'GETted from OUR vantage point once the lease expires', that 'At least one of expectedBodyContains / expectedStatus is required' (though the schema also notes this), and how the verdict is determined. It also clarifies the payment-related _meta fields, which are not in the schema but are part of invocation. This enriches the schema without redundancy.

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 precise verb-object pair: 'register an intent you are about to act on irreversibly, with a lease and a verification probe.' It names the resource (an intent) and the mechanism (lease + probe). It distinguishes from siblings by explicitly mentioning deadman_confirm and deadman_read and by noting it is paid while they are free. This leaves no ambiguity about what the tool does.

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 explicit step-by-step usage: call once without payment to receive a price, then call again with a signed payment in _meta['x402/payment']. It also instructs when to confirm (before the lease expires) and when to read the result (via deadman_read). It clarifies the payment requirement and the flow, leaving no guesswork about when and how to invoke it.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false; the description adds that the call is free, requires no account, and returns the snapshot and when it was taken. The feedback-channel detail is peripheral but does not contradict the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Core behavior and rationale are front-loaded and efficient. However, the two-sentence feedback solicitation about 'POST /feedback' is extraneous to tool selection and invocation, preventing a higher score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter read-only tool, the description plus schema and annotations cover auth (no account), cost (free), error behavior (404 on unknown venue), and returned content (snapshot and timestamp). An output schema is absent, but the essential return semantics are described.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the single 'venue' parameter is already fully documented, including the free-404 edge case. The description itself adds no parameter-level detail beyond that, so it meets the baseline for full schema coverage.

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 identifies the resource as 'the baseline snapshot we hold for one venue' and its role ('what a paid check would diff against, and when it was taken'). It is clear and distinct from drift_check and drift_venues, though it lacks a direct action verb like 'get' or 'retrieve'.

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 states the intended moment of use: read the free baseline before making a paid check so the first call is not blind. It does not explicitly name sibling alternatives or give when-not-to-use conditions, but the 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?

Annotations only say readOnlyHint=false, openWorldHint=false, destructiveHint=falsehol. The description adds the essential behavioral traits: the call is paid and billed even when there is no drift, the comparison is from 'OUR vantage point', the x402 payment flow and receipt location in _meta, and the fact that no account or API key is needed. This far exceeds what annotations alone would tell an agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and billing model, which is good mud, but it includes extra support-channel boilerplate about posting to /feedback and stating that every report is read daily. While informative, those sentences are not needed for selecting or invoking the tool and make the description longer than necessary. A tighter ending would earn a higher score.

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 what the tool returns; it does so by describing the diff outcome and noting that 'no drift is still an answer'. It also covers prerequisites, the two-step x402 payment sequence, the receipt location, and authentication-free access, leaving no major gap for an agent trying to call 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?

The schema already provides 100% coverage for the single 'venue' parameter, including the fact that a never-snapshotted venue returns a free 404. The description reinforces this by saying the venue must have been snapshotted before)SkipEvent and references drift_venues, but it does not add new parameter-level syntax or constraints beyond what the schema already gives. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 're-fetch a venue' and 'return what changed since the baseline'. It further distinguishes the diff kind ('schema/rubric fields that moved, were added and were removed, not a byte diff') and names sibling tools drift_venues and drift_baseline so an agent can separate them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says to pair the tool with drift_venues and drift_baseline, and lays out the payment workflow: call once without payment to get the x402 price, then call again with a signed payment in _meta['x402/payment']. This gives concrete when-to-use and how-to-invoke guidance beyond a generic alternative list.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, which cover the safety profile. The description adds that it is free and a closed value set, consistent with openWorldHint=false. It also mentions a feedback channel, but that is tangential to the tool's core behavior. The description does not contradict annotations and provides minimal extra behavioral context beyond what annotations already offer.

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 main purpose is front-loaded in the first sentence. The description is about three sentences long, but includes a lengthy aside about the feedback endpoint and a philosophical note on 'paywall on discovery.' While informative, this extra content is not essential to the tool's operation and makes it slightly less concise than it could be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool is simple (no params, no output schema) and annotations cover safety, the description sufficiently conveys the core purpose and the data returned ('what we hold for each'). It is not explicit about the response format (e.g., list, map, field names), but for a discovery endpoint with zero parameters, the description provides enough for an agent to use 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?

The tool has zero parameters, and the schema is an empty object. With no parameters to document, the baseline is 4. The description does not need to elaborate on parameters; instead, it focuses on the output, which is appropriate. It explains that the tool returns the set of venue ids and associated holdings, adding meaning beyond the empty 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 description clearly states the tool lists 'every venue id drift_check can be aimed at, with what we hold for each.' This is a specific verb (list/discover), a clear resource (venue ids for drift_check), and it differentiates itself from siblings like drift_check (the operation) and drift_baseline. The phrase 'closed value set' also distinguishes it as a discovery endpoint.

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 implies this tool is a prerequisite for calling drift_check: without it, a caller cannot name a valid venue id. It states that otherwise 'a caller can honour the input schema and still never name something buyable,' which clearly signals the usage context. It doesn't explicitly name alternatives or exclusions, but the purpose is clear enough for an agent to infer when to use it.

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

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

Annotations indicate readOnlyHint=false, destructiveHint=false, and openWorldHint=false, but the description goes beyond by revealing the payment requirement (x402), network isolation, and the specific meta fields ('_meta['x402/payment']' and '_meta['x402/payment-response']'). It also states no account/API key needed, which is useful context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the critical paid execution flow, then adds the pricing details and feedback channel. It is concise given the complexity, but the feedback part could be seen as extra; still, it earns its place by clarifying how to escalate issues.

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 complex paid execution tool, the description covers the crucial payment flow, sandbox isolation, and return fields. It doesn't explain error cases beyond the payment required, but it references 'GET /quote' and service_card for runtime listings. Given no output schema, it could explain stdout/stderr format more, but it's adequate.

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 documents all parameters. The description adds minimal parameter-specific semantics, but it does mention that 'limits' affect the price and that 'runtime' can be looked up via quote or service_card. This slightly exceeds 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?

The description clearly states the tool runs code in an isolated sandbox and returns stdout, stderr, and exit code. It uses a specific verb ('run') and resource ('code'), and distinguishes itself from siblings like search_listings and service_card by its paid execution model.

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 provides explicit two-step usage: call once to get a price, then call again with a signed payment. It tells the agent to use 'service_card' to list runtimes and 'GET /quote' for pricing. It also explains the feedback mechanism as an alternative for complaints/questions.

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

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

The description discloses far more than the annotations alone: the x402 payment requirement, the free price-probe call, the signed payment in _meta['x402/payment'], the receipt in _meta['x402/payment-response'], 3-day retention, no-account/no-API-key operation, and the structural refusal of unverified done entries. This is exactly the behavioral context 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?

The description is dense and front-loaded with the 'PAID' warning, but it is a long paragraph that mixes core call mechanics with feedback-channel details such as 'Every report is read and analysed daily; there is no individual reply.' Useful information, but it could be trimmed or structured into sections.

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 description covers the payment flow, receipt location, readback symmetry, retention, account-free access, error behavior, and the four-section briefing structure. With no output schema, this fully equips an agent to call the tool in either the price-probe or paid-submission mode.

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 already defines each parameter, including confidence/evidence rules and the measured/unverified constraint. The description repeats the handoff framing and the 'structurally forbidden' rule, but adds little parameter-specific meaning beyond what the schema already states.

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 and resource: deposit a typed briefing for the successor process, organized into DONE, NOT DONE, IN FLIGHT, and PICK UP FIRST. It also differentiates itself from handoff_read, which is the free read-back counterpart, so an agent can distinguish the tool from its sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives concrete usage context: deposit for handoff, successor reads via handoff_read, and use POST /feedback for complaints and questions. It also explains the two-call paid flow (price probe first, then signed payment). It does not state explicit 'when not to use' exclusions, but the alternatives are clearly 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?

Annotations already mark it read-only and non-destructive, but the description adds substantial behavioral context: it is free and unauthenticated, deliberately requires no signature, and treats possession of the id as the entire authorization. Warning the agent to treat the id as a secret is meaningful beyond the schema.

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 is useful and front-loaded, but the description drifts into an unrelated feedback pitch about POST /feedback and daily analysis. That content does not help an agent select or invoke the tool and makes the definition longer than necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-required-parameter read tool, the schema, annotations, and description together cover purpose, authorization model, and parameter semantics. The description does not explicitly describe the return shape, but the tool's name and flow make the returned briefing content fairly obvious.

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 schema already documents id as returned by handoff_deposit, so baseline is 3. The description adds value by explaining that the id is not just an identifier but the sole authorization credential and a secret, which affects how the agent should handle 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?

The description states a specific verb and resource: 'read a briefing back by id.' It also anchors the tool in a clear flow by referencing handoff_deposit as the step that creates the briefing, making the tool's role and relation to siblings unambiguous.

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 usage context: this is how a purchased briefing 'reaches your successor over MCP,' implying it should be used after handoff_deposit. It does not explicitly name alternatives or state when not to use it, but the intended sequencing is evident.

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?

Beyond the generic annotations, it discloses the payment mechanism, wallet-ownership constraint, renewal extension behavior, receipt location in _meta, and the no-account/no-API-key requirement. This directly shapes agent expectations for a paid, state-changing call and adds significant value over the structured annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and payment flow are front-loaded and dense, and the extension behavior is relevant. The final feedback-channel sentences are off-topic for invoking this tool and add length without improving selection or call correctness, so it is not a perfect 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?

For a paid, two-step x402 operation with no output schema, the description covers discovery, quote, payment, completion, renewal, ownership, and response location. An agent has enough information to attempt the call correctly without guessing at protocol details.

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 baseline applies. The schema already describes id ownership and the duration enum with its price/window effect; the description reinforces those points but does not add materially new parameter-level meaning.

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 'buy paid placement for a listing you own in this directory' and immediately distinguishes the effect: it ranks above free rows and reads tier 'paid'. This separates it from sibling tools like search_listings and storage_buy because the verb, resource, and payment model are 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?

It gives an explicit two-step invocation protocol: call once without payment to receive the x402 PaymentRequired price, then call again with a signed payment in _meta['x402/payment']. It also states the ownership precondition, names search_listings for id/price/paidUntil discovery, and explains that renewing early extends rather than replaces the current placement. This is concrete when/how guidance with clear prerequisites.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context beyond that: it is free and unauthenticated, it returns a page plus an opaque cursor for pagination, and it references the exact underlying endpoint. This helps an agent understand network access and pagination mechanics, which annotations do not cover.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler. The first sentence front-loads the core purpose and data source; the second covers the return format. Every word earns its place, making it highly scannable for an agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only search tool with all optional parameters and an output schema (which presumably defines the page and cursor), the description is complete. It covers auth, cost, pagination, and data source. An agent has everything needed to invoke it correctly without further investigation.

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 all three parameters (tag, limit, cursor) are already documented. The description does not add new semantics beyond what the schema states, except for reaffirming the cursor is opaque and paginated, which the schema already says. Baseline 3 is appropriate since 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 description clearly states the verb (search), the resource (agent-exec's directory of paid agent-facing services), and even gives a direct endpoint reference for the same data. It distinguishes itself from siblings by being a search operation, whereas execute and service_card are different operations. No 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?

The description provides clear context that this is a search over the directory, implying it is for read-only discovery of listings. It does not explicitly name alternatives or exclusions, but the sibling tools (execute, service_card) are obviously different operations. The 'free, unauthenticated' note also signals it can be called without setup. Missing explicit 'use this when...' but context is sufficient.

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?

Beyond the readOnlyHint and non-destructive annotations, the description reveals that the call itself is free, moves no money, and returns payment URLs. It also discloses feedback handling behavior: reports are read daily and receive no individual reply. This is valuable behavioral context exceeding the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Every sentence earns its place: service/pricing summary, free call guarantee, purchase channels, and feedback process. The most important scoping information is front-loaded, and there is no redundant repetition of the title or schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read-only tool with an output schema and clear annotations, the description fully covers purpose, cost behavior, payment channels, and feedback expectations. Nothing essential is missing for an agent to invoke and interpret 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?

The tool has zero parameters and the schema coverage is 100%, so parameter-level documentation is unnecessary. The description correctly focuses on the tool's information payload rather than nonexistent inputs.

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 clearly states this tool presents an agent-exec service card covering what is sold, pricing, and payment location. It distinguishes itself from the paid execute tool and the HTTP execution path, making its informational role unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains that code execution should be purchased via the paid execute tool or plain HTTP, and directs feedback and questions to POST /feedback, clearly differentiating alternatives. It does not explicitly say 'use this tool when you need pricing/service information,' but that context is strongly implied.

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

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

Annotations only say readOnlyHint=false, openWorldHint=false, destructiveHint=false. The description adds valuable behavior: paid two-step x402 flow, wallet ownership, public readability, expiry return, receipt location, and auth requirements. This is consistent with readOnlyHint=false and adds substantial context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The core content is dense and front-loaded with the PAID nature and return value, but the closing feedback paragraph ('Complaints, questions, quote requests...') is off-topic for tool selection and invocation. It adds roughly a quarter of the text without helping an agent use the tool correctly.

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 covers the full call sequence, return values (object id and expiry), payment keys, ownership/readability model, and auth requirements. An agent has enough information to invoke this complex paid mutation correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and each parameter already has a description. The tool description adds meaning by linking plan to size/price, requiring decoded base64 size to fit the plan, and explaining the payment-related meta keys. That exceeds the baseline for fully-documented parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action and resource: 'store opaque bytes for the life of the plan you buy', qualified by PAID. It also differentiates from siblings by pointing to storage_read for retrieval and storage_renew for extension, so an agent can tell it apart without opening tool schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit usage steps: call once without payment to receive the price, then call again with a signed payment in _meta['x402/payment']. It also names the right siblings for follow-up operations and notes that no account or API key is needed.

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

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

Annotations already flag destructiveHint=true, and the description expands on this with 'no refund and no undo'. It also discloses the unusual first-call flow: a placeholder signature returns details.expected with the exact message to sign, including EIP-191 and ed25519 formats. This is substantial behavioral context beyond what the annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose is front-loaded, but the description is cluttered with a long, unrelated feedback pitch ('POST /feedback... Every report is read and analysed daily') that does not help an agent select or invoke storage_delete. The repeated 'FREE' phrasing and run-on sentence structure also reduce clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, but the description covers the destructive consequence, ownership requirement, auth behavior, and all required parameters through the schema. It could state what a successful deletion returns, but the information needed to call the tool 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 parameters are already documented. The description adds real value by explaining the signature workflow: send a placeholder signature once and the refusal returns the exact message to sign, with specific format variants for 'signature'. This goes meaningfully beyond the schema's generic parameter descriptions.

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 the exact action ('delete an object you own') and its consequence ('free its bytes'), which is specific and unmistakable. It also distinguishes storage_delete from its siblings (storage_read, storage_list, storage_buy, storage_renew) by being the only deletion operation.

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 states the precondition for use ('object you own', 'paying wallet', 'no account') and warns 'no refund and no undo', giving clear context for when deletion is appropriate. It does not explicitly name alternative tools such as storage_renew, so it stops short of full exclusionary routing guidance.

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

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

Even with readOnlyHint and destructiveHint annotations, the description adds substantial behavioral context: it is free, requires no account, proves ownership via the paying wallet, requires a nonce to prevent replay, returns paginated results, and explains the placeholder-signature challenge that yields the exact message to sign. This goes well beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence front-loads the core purpose and the second explains critical auth behavior. However, the final paragraph about POST /feedback and complaints is not relevant to selecting or invoking this tool, so the description is padded with nonessential promotional content.

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 no output schema, the description still states the listed fields and pagination, and the input schema covers after/nonce/signedAt/signature in detail. The auth challenge flow is explained sufficiently. It is nearly complete, though the output envelope (e.g., array shape and nextCursor) is only implied by the schema's after description.

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 each parameter already has a detailed description, so the baseline is 3. The description adds real value by explaining the unusual workflow: send a placeholder signature once and the refusal returns details.expected with the exact signing message in both EIP-191 and ed25519 forms. This clarifies how the required signature parameter is actually obtained.

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 clearly specifies the verb ('list'), the resource ('objects your wallet owns'), and the returned fields (id, label, size, created/expires). It does not explicitly differentiate this from siblings like storage_read or storage_usage, but the owned-objects listing scope is unambiguous enough for selection.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance about when to use this tool versus storage_read, storage_usage, or search_listings. The description focuses on authentication mechanics and free access, but never tells an agent when it should pick this tool or when it should 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?

Beyond annotations, it discloses the ownership-proving flow: no account, placeholder signature produces a refusal that carries details.expected, and the exact signable message formats for both wallet types. It also specifies the base64 return format. No contradiction with readOnly/destructive hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The first two sentences are front-loaded and efficient, but the final two sentences about '/feedback' and daily analysis are unrelated service promotion that does not help an agent invoke the tool. The core description is clear, but the irrelevant tail keeps it from being tighter.

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 four-parameter, authenticated read with no output schema, the description explains the auth challenge/response, ownership requirement, and base64 result. It could include a success-response shape, but what an agent needs to compose a request 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 already covers all four parameters at 100%, so a baseline of 3 applies; the description adds useful auth-flow context for the signature parameter (placeholder signature, details.expected, EIP-191 vs ed25519 formats). The other parameters rely on the schema, which is acceptable.

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 operation ('read back an object you own, as base64') and explicitly ties it to storage_buy as the retrieval counterpart, distinguishing it from sibling write/delete/renew tools. The verb and resource are unambiguous.

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?

Clearly frames the tool as the way to retrieve what was bought via storage_buy, establishing the primary use case and complementing the sibling set. It does not explicitly enumerate when to avoid it or compare to storage_list/storage_usage, so it stops at clear context with no 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?

Despite being a paid mutation (readOnlyHint=false), the description adds safety-relevant context the annotations don't carry: 'The object is untouched; only its expiry moves' confirms non-destructiveness, and it discloses the payment-before-action behavior, auth requirements ('No account, no API key'), and the receipt location in _meta['x402/payment-response']. This is substantial disclosure beyond the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The core action and payment flow are front-loaded and efficiently explained, and the x402 two-phase detail earns its place. However, the trailing feedback paragraph ('Complaints, questions, quote requests... every report is read and analysed daily') is roughly a quarter of the description and is irrelevant to selecting or invoking the 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?

For a paid, two-phase tool with no output schema, the description covers the full call sequence, where the price and receipt appear, the return values ('Returns the new and previous expiry'), and the auth prerequisites. It omits failure modes (unknown id, rejected or wrong-amount payment), but everything essential to driving the flow 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% and both parameters are well documented in the schema itself (id as the object id returned at purchase; plan as an enum setting size and price), so the baseline of 3 applies. The description adds only marginal color — 'buying it another plan term' frames plan as a renewal term — but does not carry meaning the schema lacks.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource — extending the expiry of 'an object you own' by buying 'another plan term' — and pins down the exact effect: 'only its expiry moves.' This distinguishes it from storage_buy (acquiring a new object) and storage_replace (changing content), so an agent can separate it from siblings without opening their schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The two-call x402 sequence is explicit: call once without payment to receive the price as a PaymentRequired, then call again with the signed payment in _meta['x402/payment']. That is strong invocation guidance, but the description never names alternative tools or states when not to use it, so it stops short of a 5.

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

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

The description discloses the x402 payment protocol, the two-phase call pattern, and where the receipt is returned (_meta['x402/payment-response']). It also explains label semantics (omit to keep, empty to clear). Annotations already mark destructiveHint=true, so the 'overwrite' wording is consistent; no contradiction. This adds significant behavioral detail beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose, then details label behavior, payment flow, account requirements, and feedback contact. Each sentence serves a function, and the structure is logical. It is somewhat long but information-dense, so it 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?

Given the tool is paid (x402) and involves a two-phase flow, the description explains how to obtain a quote and complete the operation, including where the receipt is returned. It also notes 'No account, no API key', which are prerequisites. With no output schema, this is reasonably complete for an agent to invoke 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 covers 100% of parameters, so baseline is 3. The description adds meaningful nuance for the 'label' parameter ('Omit label to keep the current one, pass an empty string to clear it'), which is not in the schema. Other parameters (id, plan, contentBase64) are adequately described in the schema, so the description provides incremental value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('overwrite'), resource ('contents of an object you own'), and scope ('keeping its id, and buy it a fresh plan term'). This clearly distinguishes it from storage_buy (buying a new object) and storage_renew (renewing without replacing content).

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: it is a paid operation with a two-phase payment flow (quote first, then complete), and it explains label behavior and the lack of account/API-key requirements. However, it does not explicitly compare to sibling tools or state when not to use it, 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds that a placeholder signature will be refused and the refusal contains the expected message to sign, which is a useful behavioral detail. However, the flow is not clearly explained, and the feedback promotion is irrelevant.

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 verbose and includes promotional content about feedback, complaints, and quote requests, which is irrelevant to the tool's function. The core purpose is stated first but then buried under a complex signature explanation and unrelated marketing, making it poorly structured and not concise.

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 requiring a specific signature flow and three parameters, the description is incomplete. It does not clearly explain the two-step process (send placeholder, get expected message, then send correct signature) and does not describe the return format or error behavior beyond the refusal. The feedback content adds no value and distracts from the core usage.

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 schema provides descriptions for all three parameters (signature, nonce, signedAt) at 100% coverage, so the baseline is 3. The description does not add additional meaning to the parameters beyond the schema; it only references the signature placeholder without clarifying the nonce or signedAt usage.

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 clearly states the tool returns the number of objects and bytes for the wallet's storage. The verb 'how many' and resource 'storage usage' are specific, and it is distinct from sibling storage_list which would list individual objects.

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 some usage context (free, no account, placeholder signature flow) but does not explicitly say when to use this vs alternatives like storage_list or storage_read. It doesn't mention any exclusions or conditions for choosing this tool over others.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: reading never triggers a poll, is never charged, and the id acts as a capability. This goes beyond the annotations, but the description also includes unrelated feedback promotion, which slightly dilutes transparency. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description includes a significant promotional paragraph about POST /feedback that is unrelated to the tool's function. This adds noise and reduces conciseness. The core function is explained in the first two sentences, but the extra content makes it less efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read tool with one parameter, the description covers the return state (active, matched, expired) and the observation that matched. It also explains the capability aspect and the free/non-polling behavior. Although there is no output schema, the description sufficiently describes the return information. The unrelated feedback content does not hinder completeness.

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 schema describes the id as 'The watch id returned by watch_register.' The description adds semantic meaning by explaining the id is a capability, which is important for understanding how it can be transferred. This goes beyond the schema's basic description.

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 clearly states the tool reads the current state of a registered watch (active, matched, or expired) and returns the matching observation. It implicitly differentiates from watch_register by focusing on the read operation, and the verb+resource is specific.

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 explains when to use this tool (to check a watch's state) and provides context about the id being a capability that can be passed to a successor process. It also notes reading is free and non-polling, but does not explicitly contrast with sibling tools like watch_register or others. The guidance is clear but lacks explicit 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?

Beyond the minimal annotations, the description extensively discloses behavior: it is paid via x402, the first unpaid call quotes the price, payment is supplied in `_meta['x402/payment']`, the receipt appears in `_meta['x402/payment-response']`, and no account or API key is needed. It also reveals that the wait is durable across process death and that the body is never returned, only the verdict.

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 information is front-loaded and the payment flow is explained clearly, but the description is verbose for a tool definition. The closing feedback solicitation ('Complaints, questions, quote requests...') is not needed for tool selection or invocation, so not every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex paid tool with no output schema, the description is remarkably complete: it explains the pricing model, the quote-then-pay sequence, where to put the payment, where the receipt will appear, how to read the result later, and that no account is required. The schema fills in the remaining parameter-level details.

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 input schema already covers all parameters at 100%, so the baseline is 3. The description adds meaningful context beyond the schema by explaining that price is a function of intervalSeconds × ttlSeconds and by framing the predicate as the condition that ends the watch, which helps the agent reason about how the parameters interact.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action: poll a URL from the service's vantage point on the caller's interval until a predicate matches or the TTL expires, then keep the verdict for collection. It clearly names the resource (a durable watch) and distinguishes itself from the sibling watch_read by explaining that the reply carries an id that watch_read can retrieve.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear when-to-use context: an agent needs a wait that survives its own process dying, which the tool uniquely provides. It also explains the two-step paid workflow and points to watch_read for retrieving the result, but it does not explicitly state when not to use it or compare it against other sibling polling/monitoring tools.

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