AgentMart core tools

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 meaningful operational context: an ack from agentmart_tools is required and nothing runs without it. It also discloses blocklist semantics at /mcp/core, which goes beyond 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?

The purpose is front-loaded, but the second half is a dense, semicolon-heavy sentence about /mcp/core and block semantics that is difficult to parse. The information is useful, but the structure makes it harder to extract quickly.

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 dispatcher tool with four parameters and no output schema, the description covers the critical gating requirement (ack) and the main routing alternatives. It stops short of stating what the tool returns or how the result mirrors the invoked tool's output, but otherwise gives enough 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 parameters are already documented in the schema. The description reinforces that the caller must supply the tool, its ack, and arguments, but it does not add syntax or usage detail beyond what the schema provides, and it omits passport_token entirely.

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: running one read-only AgentMart tool that is not in the caller's list. It distinguishes itself from in-list tools by telling the agent to call those directly, and it implicitly contrasts with agentmart_write, though the contrast is not as crisp as it could be.

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

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

It clearly says to use this only for tools not in your list and to call in-list tools such as buy directly. It also explains the /mcp/core blocking behavior and points to /mcp as an alternative, giving concrete when-to-use context without spelling out every exclusion.

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 establish read-only, non-destructive, closed-world behavior. The description adds useful behavioral context: an exact tool name returns arguments/ack/run metadata, and listed tools should be invoked directly rather than through this tool. It does not fully describe the search result shape, but there is no contradiction.

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?

It is short and front-loaded: discovery scope first, then parameter modes, then the direct-call alternative. The category list and awkward "ack and run tool" phrasing make it denser and less clear than ideal, but every sentence contributes.

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 read-only discovery tool with no output schema, the description gives enough to understand when to use it and what an exact-name lookup provides. The return shape for word/group searches remains slightly underspecified, but the core invocation guidance 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 description coverage is 100%, so parameter meanings are already well documented. The description reinforces the words/group/tool modes, but adds little beyond the schema and does not explain passport_token beyond what the schema already says.

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

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

Starts with a specific verb and resource ("Find AgentMart tools") and scopes it to tools not already in the agent's list; the category examples and direct-call sentence distinguish it from invoking listed tools. However, the phrase "ack and run tool" makes the exact operation less crisp.

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

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

Explicitly says to use this when a tool is not in the agent's list and to call listed tools such as buy directly. It also explains the three lookup modes (words, group, exact tool name), giving a clear condition for choosing this tool over 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 already declare destructiveHint=false and openWorldHint=true, but the description adds substantive behavior: the hard guarantee that destructive or spending tools are never run, that an ack from agentmart_tools is mandatory, and that a block on the underlying single tools does not carry over at /mcp/core. It stops short of describing what is returned on failure or whether the wrapped call's errors are surfaced.

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 the destructive/spend guard are front-loaded in the first sentence, and every sentence carries load-bearing information. The final sentence, however, is a long semicolon-spliced construction about /mcp/core routing that takes effort to parse and slightly muddies the otherwise crisp opening.

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 router tool with a nested free-form arguments object and no output schema, the description covers selection, the required ack handshake, the safety envelope and deployment-specific routing. What's missing is what a call returns or how wrapped-tool failures are reported, though the schema's ack description partially covers that.

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

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

Schema description coverage is 100%, so the schema already documents ack, tool, arguments and passport_token in detail, including the enum. The description only restates the triple of tool/ack/arguments and adds no syntax or format detail beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ("Run one AgentMart tool") plus the precise scope of what it will and won't execute: changes or reaches outside, never destroys or spends. An agent can distinguish it from agentmart_read, agentmart_tools and buy without opening any schema.

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

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

Explicitly names the condition for use (a tool not in your list), the exclusion (a tool in your list, such as buy, should be called directly), and the alternative for non-mutating calls (agentmart_read). It also gives routing guidance for /mcp/core versus /mcp, which is exactly the kind of when-to-use context an agent needs.

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

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

Beyond the annotations (destructiveHint=true, idempotentHint=true) the description discloses real behavioral substance: validation against the stage schema and prior stages, that database DDL is actually executed against PostgreSQL, and that failures are atomic ("nothing is saved") with path-annotated errors. It leaves unstated what happens to a previously saved stage when you re-save one, which matters given destructiveHint=true.

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

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

Four short sentences, front-loaded with the purpose, then ordering, then validation semantics, then the one special-case trigger. The stage list duplicates the schema enum but does so to reinforce sequencing, which is the kind of repetition that 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 destructive, nested-payload mutation with no output schema, the description covers the failure path and atomicity well enough that an agent can retry correctly. The remaining gap is overwrite semantics — whether re-saving an existing stage replaces or errors — plus any auth prerequisite around passport_token, neither of which the description addresses.

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

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

Schema coverage is 100%, so baseline is 3, and the description still adds value: it explains that `stage` values are ordered and interdependent, and gives a concrete sentinel for `data` when stage=tasks (send {"tasks": []} to have the list built). It adds nothing for instance_id or passport_token, and the pointer to blueprint_method for the data shape lives in the schema rather than the 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 opens with a specific verb and resource ("Save one stage of your blueprint") and enumerates the six stage values, so the agent knows exactly what unit of work this performs. It does not explicitly route away from siblings like blueprint_delete_stage or blueprint_update_task, relying on the agent to infer the distinction from the word 'stage'.

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?

"in order: concept, features, pages, database, tech_spec, tasks" encodes a hard prerequisite sequence, which is the key when-to-use rule for this tool, and the retry loop is spelled out ("fix them all and call again"). No named alternatives or explicit when-not-to-use cases, but the ordering constraint carries most of the guidance burden.

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=false, destructiveHint=true and idempotentHint=true, so safety and repeatability are covered structurally. The description adds useful context that the change is visible to the human on the plan page, but it does not disclose that an update overwrites the task's existing status, which is the behavior behind the destructive hint.

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

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

Two short sentences, the lifecycle rule front-loaded and the visibility note second. No redundant or filler 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?

For a 4-parameter mutation tool whose schema fully documents each field and whose annotations carry the safety profile, the description covers the core semantics an agent needs. It stops short of describing the return value, but there is no output schema, so that gap is modest.

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%, including a description of the status enum and provenance for task_id and instance_id. The description's status text is essentially a restatement of the enum description already in the schema, so it adds little beyond the structured fields; baseline 3 applies.

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

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

States a concrete verb+resource ('Set a blueprint task to doing/done/todo') and encodes the lifecycle meaning of each status value. It is distinguishable from blueprint_tasks (listing) and blueprint_put_stage (stage-level), though it never names those siblings explicitly.

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

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

Gives clear when-to-use triggers for each status: 'doing when you start it', 'done when its tests pass', 'todo undoes'. It does not state exclusions or point at alternative tools, but the trigger conditions for each mode are unambiguous.

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

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

Far beyond the annotations: it discloses the pending_approval flow (HTTP 202, nothing taken, owner emailed, 24-hour window), the full set of terminal order statuses, idempotency retry semantics, secret handling (write-only, encrypted, deleted on close), and the zero-cost update rule. This is exactly the operational context a mutation tool needs.

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

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

Front-loaded with the core action and dense with useful facts, but the semicolon-chained sentences covering approval, human services, site tests, docs, and version updates run together, making it harder to scan than it needs to 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?

For an 8-parameter, nested-object, no-output-schema purchase tool, the description covers the money/approval lifecycle, the human-services sub-flow, the kit update exemption, and where to read outcomes (get_order, get_job). Nothing an agent needs to call it safely is missing.

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

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

Schema coverage is 100%, so the schema alone documents all eight parameters and the baseline is 3. The description adds workflow meaning the schema lacks: when instance_id means renew versus new, that brief/secret/max_price_cents apply only to human services, and that brief must be shaped by details.brief_schema from get_item.

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

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

States a specific verb and resource ('Buy an item from your balance') and immediately differentiates variants: utilities start immediately, kits return a download link, and passing instance_id renews instead of creating. An agent can distinguish this from buy_site_badge, top_up, and get_order without opening any schema.

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

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

Explicit routing rules: quote_human_service first for human services, verify_job_sites before website tests, get_order to follow approval status, get_item for details.brief_schema, and instance_id to renew rather than repurchase. It also names the free-update exemption for kit version bumps, which prevents unnecessary purchases.

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 declare write/destructive/open-world; the description adds the substantive behavior: exact costs and term lengths, the daily-check cadence, that results are published on a PUBLIC page with a badge image and signed copy (a real external side effect), the ~10 minute latency for the first result, and the owner-approval gate above a daily limit. It also clarifies that a repeated idempotency_key is a retry rather than a duplicate order, which usefully sharpens the `idempotentHint: false` annotation rather than contradicting it.

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

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

Dense but front-loaded: the price and term open the description, then prerequisites, then behavioral caveats. Semicolon-chained clauses such as 'renew with buy and the badge's instance_id ($3 per 30 days)' take a re-read, but no sentence is filler.

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

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

No output schema, and the description compensates by routing to `get_utility` for the first result and its timing, and by describing what the purchase produces (public page, badge image, signed copy). Gaps remain around failure/refund behavior and whether the paid term is cancellable, which matter for a destructive spend tool.

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

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

Schema coverage is 100%, so the baseline is 3; the description goes beyond by explaining that the same idempotency_key and domain produce a retry rather than a second order, and by tying the domain argument to a prior `prove_domain` call within 7 days. It does not explain max_price_cents behavior (what happens if the price exceeds the cap) or clarify how the badge's instance_id used for renewal relates to the inbox_instance_id parameter, leaving a small ambiguity.

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 a specific transaction (spending balance) for a specific resource (a badge tied to daily site checks) at a specific price and term. It also implicitly separates itself from the sibling `buy` tool by explaining that renewal goes through `buy` with the badge's instance_id, and from `prove_domain` by naming it as a prerequisite. It never states the verb+resource plainly ('buys a badge subscription'), which keeps it just short of a 5.

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

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

Explicit preconditions ('Needs the domain proved with prove_domain in the last 7 days'), an explicit alternative for renewal ('renew with buy'), an exclusions statement ('Not a security audit'), and an escalation path ('Above the daily limit it waits for your owner's approval'). An agent has everything needed to decide use vs. not-use and vs. which sibling.

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

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

Annotations already flag destructive and idempotent, but the description adds substantive context beyond them: the full price returns as store credit immediately, the job closes with closed_reason cancelled_unproved, an artifact (cancel_jws) is produced, and repeats are safe. It also specifies the exact error code for the wrong state. This is a complete behavioral picture of a mutation.

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

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

Efficient: the precondition and outcome are front-loaded, and the trailing sentence covers the failure mode. Slightly dense with nested parentheses, but every clause carries information an agent needs.

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

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

With no output schema, the description supplies the full post-call state (refund to store credit, closed reason, signed statement) and the error case (409). Combined with complete parameter docs and annotations, nothing needed to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so job_id and passport_token are already documented in the schema. The description only implicitly references the job being cancelled and adds no format or sourcing detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb (cancel) and resource (a website test/job), plus the exact precondition status (needs_verification). This lets an agent distinguish it from accept_job, dispute_job, or claim_refund without opening any schema.

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

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

Explicitly defines the use condition (status needs_verification) and the alternative outcome for any other status (409 job_not_cancellable), which functions as clear when-not guidance. It does not name sibling tools like dispute_job as the alternative path for other statuses, keeping it just short of a 5.

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

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

Despite annotations already covering safety hints, the description adds substantial behavioral context: pricing and credit structure, consent requirement, asynchronous processing, owner approval for larger orders, concurrency and daily limits, and the fact that no email is ever sent. These are exactly the operational details an agent needs beyond the annotation flags.

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 remains focused on operational constraints, pricing, consent, and follow-up behavior. It is dense and lengthy in a single paragraph, and could be organized more clearly, but most sentences earn their place given the tool's complexity.

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

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

With no output schema, the description compensates by explaining the returned statuses and reasons, the polling flow via get_email_check, pricing, consent, limits, and approval behavior. An agent has enough context to invoke the tool correctly and understand what happens afterward.

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 is 3. The description adds useful semantics beyond the schema by explaining that pricing is counted by different entries, that some lists may cost only $1, and by emphasizing that consent must be truthfully asserted; it does not explain every parameter such as label or inbox_instance_id, so it is not a full 5.

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

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

The description states a specific verb and resource: checking the owner's own email addresses, up to 1000 at a time, returning valid/invalid/risky/unknown outcomes. It also distinguishes this operation from the follow-up status tool by saying to call get_email_check until completed.

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

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

It clearly says when to use the tool (before sending to an owner-owned opt-in list) and gives the required follow-up action, as well as explicit exclusions about never supplying or sending to addresses. However, it does not name competing sibling tools such as check_sender or suppression_check, so alternative selection is largely implicit.

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

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

With annotations declaring readOnlyHint=false and destructiveHint=true, the description explains *why* it is a mutating call: it spends from the balance ($1 per domain), is rate-limited, and may require owner approval. It also discloses that only public DNS is queried and nothing is sent, and honestly bounds what a pass means (reputation, content, engagement still matter) — context no annotation provides.

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

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

Purpose and price lead, then parameters, then limits, then caveats — a sensible front-loaded order with no filler sentences. It is dense and somewhat run-on (long parentheticals and semicolons), which slows scanning but does not waste 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?

No output schema exists, yet the description describes the return shape (score, per-check verdict, plain summary, exact DNS records to add), payment/approval behavior, and rate limits — everything needed to decide and call correctly. The residual caveat about inbox deliverability is a useful boundary rather than a gap.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics on top: provider 'ADDS that provider's DKIM selectors and return path to the search' and 'the common selectors are always tried too', plus the SES-specific instruction to pass the three Easy DKIM tokens via dkim_selectors. That tells the agent what leaving provider blank costs (wider, slower selector search), which the schema does not.

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

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

Opens with a specific verb+resource ('Check how the domain your owner sends email from is set up') and enumerates the nine record types inspected, plus the enumerated deliverable (score, pass/warn/fail per check, exact DNS records). It doesn't explicitly distinguish this purchasing tool from the sibling readers get_sender_check / list_sender_checks, so the agent must infer that this one starts a paid run rather than fetching an existing report.

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

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

Gives concrete gating context: $1 per domain from the balance, 30 checks per owner per 24h, one domain at most 5 times an hour, and larger orders land in pending_approval. It also tells the agent how to use the provider parameter (including the Amazon SES three-token case). It stops short of naming the alternative path for retrieving an existing result (get_sender_check/list_sender_checks), which is the one routing decision the siblings create.

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?

Adds substantial context beyond the annotations: a 24-hour window, that the vendor verifies via its own test run or service logs before crediting, and that the payout is store credit rather than a card refund. This is consistent with destructiveHint=true (claiming consumes the guarantee) and non-idempotent hints. It doesn't say what happens on a rejected claim or whether the claim can be repeated, so not a 5.

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

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

Four short sentences, front-loaded with the core action and the time limit. The 24-hour constraint and payout-type caveat both earn their place, though the terse fragments ('Within 24 hours.') read a bit clipped rather than maximally 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 mutation tool with no output schema and fully documented params, the description covers the key unknowns: deadline, verification process, and payout form. Missing only post-call details such as what a successful or denied claim returns and whether the guarantee is one-shot per order.

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

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

Schema description coverage is 100% and all four parameters are documented in the schema, so the baseline is 3. The description's mention of 'our own test run' loosely points at the test_output parameter but adds no format, requiredness, or interaction detail beyond the schema.

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

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

States a specific verb (claim) and resource (store credit for a purchase) plus the triggering condition (a purchase that did not work). It clearly distinguishes itself from listing/lookup siblings like get_order or list_orders, though it never names a specific alternative such as dispute_job or top_up.

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 a real usage condition: within 24 hours of a purchase that did not work. It also implicitly excludes card-refund seekers by stating the guarantee pays store credit, not card refunds. It stops short of explicit when-not rules or named alternative tools.

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 annotations' destructiveHint/idempotentHint, it discloses the actual effect: the link renders a closed page, stops accepting picks including in-chat cards, and previously made picks survive readably via get_owner_picks with status closed. It also adds an ownership constraint ('Only the passport that made it') that no annotation carries.

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

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

Front-loads the action and its origin, then packs consequences, idempotency, and the ownership constraint into two dense but waste-free sentences.

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

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

No output schema exists, yet the description fully describes the post-call state (closed page, no more picks, picks still readable and where to fetch them). For a 2-param mutation with annotations covering safety, nothing an agent needs is missing.

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

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

Schema coverage is 100% with window_id explicitly tied to show_shop_to_owner (shw_...), which the description reinforces. It says nothing extra about passport_token, which the schema already documents, so baseline-plus holds rather than a higher score.

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

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

States a specific verb-and-resource (close a pick link) and names the creating sibling show_shop_to_owner, so an agent can distinguish it from reopen_shop_window and show_shop_to_owner without opening either schema.

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

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

Gives concrete situations to use it (human already answered, or the link was shared by mistake) and points to get_owner_picks for reading remaining picks. It does not mention the inverse sibling reopen_shop_window or state explicit when-not conditions, so it stops short of full alternative routing.

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

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

Beyond the annotations (readOnlyHint=false, idempotentHint=false), the description discloses the critical behavioral trait that the returned token is shown only once and must be kept, and that no email or password is involved. The 'Call once' instruction is consistent with idempotentHint=false rather than contradicting it.

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

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

Three short sentences, zero waste, and the eligibility gate is front-loaded before the action and the one-time-token warning. Ordering matches the agent's decision sequence: should I call this, what happens, what do I do after.

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, yet the description carries the one thing that matters about the return value: a token is returned and displayed only once. With zero required parameters and full schema coverage, nothing else is needed for a correct call.

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

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

Schema description coverage is 100%, so the schema already explains `nickname` in full, and the description's 'No email, no password' correctly signals that no credential parameters are needed. The baseline is 3; slight credit for pre-empting the most likely agent confusion about auth fields, though `nickname` itself is never mentioned in the 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 names a specific verb and resource ('create your passport (your identity here)') and immediately distinguishes it from the sibling `whoami` by naming the condition under which the agent already has an identity. An agent can tell exactly what this tool produces without opening the schema.

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

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

It gives an explicit gating condition ('Only for MCP apps that cannot sign in to AgentMart') plus an explicit exclusion with the alternate path ('When your app signed in (whoami works without a token)... do not call this'). Both the when and the when-not are stated, along with the sibling that resolves the alternative case.

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

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

Beyond the readOnlyHint annotations, the description discloses authentication behavior: passport sign-in via Authorization header or passport_token unlocks update_available and owner promo data. It also clarifies null behavior for update_available when no newer free version exists.

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

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

The core purpose is front-loaded in the first sentence. The remaining sentences are dense but each carries relevant conditional-return information, though the long nested clause about update_available could be easier to parse.

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 authentication and special owner-specific fields, but without an output schema it does not fully describe the general item payload or error/not-found behavior. It is adequate for invocation but leaves return-value expectations partially vague.

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

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

Schema coverage is already 100%, so the schema documents both parameters. The description still adds useful semantic context for passport_token by explaining that it substitutes for app sign-in and changes which owner-specific fields are returned.

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 retrieval action: 'Full details of one item by slug.' It distinguishes this lookup from search_catalog by noting that search_catalog always shows the general offer while this tool can show owner-specific promo and update_available data.

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 slug parameter is tied to search_catalog, which gives clear usage context, and the description explains when passport-authenticated calls reveal additional owner-specific information. It does not explicitly state when not to use this tool, but the intended lookup vs. search flow is clear.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is mostly covered. The description adds useful context by stating the concrete effect that the ping address stops answering. It does not add further detail about auth needs or irreversibility 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 definition is two short sentences with zero waste, and the core action is front-loaded. The second sentence adds a concrete behavioral effect rather than repeating structured data.

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?

This is a low-complexity removal tool with complete schema descriptions and annotations covering destructiveness and idempotency. The description explains the action and its immediate effect, which is adequate for correct invocation. It could mention that removal is final, but destructiveHint already signals that.

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

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

Schema description coverage is 100%, so all three parameters, including the optional passport_token, are already documented in the input schema. The description adds no parameter-specific meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: 'Stop watching a job.' It also adds the effect 'Its ping address stops answering,' which clarifies what removal means. It is clear enough to distinguish from heartbeat_add and heartbeat_status, though it does not explicitly contrast with heartbeat_update.

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 usage by saying 'Stop watching a job,' but it gives no explicit when-to-use guidance, prerequisites, or alternatives. It doesn't clarify whether heartbeat_update could also stop monitoring, leaving the agent to infer the correct sibling 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 destructiveHint=true and idempotentHint=true, so the description's job is to add specifics, which it partly does: 'Fields left out stay' discloses merge-not-replace semantics and 'The forwarding key comes back once, as forward_secret' discloses a one-time secret return that no output schema documents. It doesn't spell out what is actually destroyed (e.g. rotating invalidates the old key, null turns off forwarding), which is a gap given destructiveHint=true.

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

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

Front-loads the verb and resource, then packs the field list and the two behavioral notes into a tight, semicolon-delimited sentence set with no filler. Minor cost: 'same address' for inbox_instance_id is opaque and briefly slows the reader.

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

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

For a 7-parameter mutation tool with nested objects and no output schema, the description covers what can be set, that omitted fields persist, and the one returned value an agent must capture (forward_secret). Annotations carry the safety profile, so the remaining omissions (auth fallback, rotation consequences) are secondary.

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

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

Schema description coverage is 100% and the nested verify/forward/handshakes properties are documented in detail in the schema itself, so the schema already does the heavy lifting. The description restates the same shapes at a glance (preset list, {url} or null) but adds no semantics beyond it; baseline 3 applies.

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

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

States a specific verb ('Set') and resource ('your webhook inbox pro plan') and enumerates exactly which fields are configurable: forwarding, signature verification and handshakes. The 'Set' framing plainly contrasts with the read-side sibling inbox_pro_get, so an agent can pick between them without opening either schema.

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

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

Usage is implied by the field list: call this to configure forwarding, verification or handshakes, and 'Fields left out stay' signals partial-update semantics. But nothing states when NOT to use it, when to pair it with inbox_pro_get, or when rotate_forward_secret/passport_token matter, so the agent must infer routing.

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 destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds nothing beyond a restatement of 'delete': it doesn't say whether deletion is permanent, what happens when the key is missing, whether folders are removed, or that passport/instance auth is needed. For a destructive operation this is thin.

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

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

One short, front-loaded sentence with zero waste. It is efficient, though its terseness leaves the gaps noted in other dimensions.

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 destructive, idempotent delete with no output schema, the description should at least clarify permanence and missing-key behavior. Annotations and schema carry most of the load, but the description itself is too minimal to be considered complete for this operation.

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

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

Schema description coverage is 100%, with key format, the instance_id source (buy or list_utilities), and the passport_token fallback fully documented. The description adds no parameter meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource: deleting a key from the memory locker. It is clearly distinguishable from locker_put/locker_get/locker_list by the verb, though it never names those siblings explicitly.

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

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

No guidance on when to use this versus alternatives such as locker_put (overwrite) or delete_utility_data, and no prerequisites or warnings. The agent must infer the correct context from the name alone.

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

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

Annotations already flag destructiveHint=true and idempotentHint=true; the description adds value beyond that by disclosing persistence across sessions and the optimistic-concurrency behavior (etag returned, if_match guards against clobbering). It stops short of describing what happens to a hidden/unmentioned content_type on overwrite or the exact write-vs-update failure modes, so not a 5.

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

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

Three short sentences, front-loaded with purpose, then the value/value_base64 rule, then the concurrency hint. Nothing is padded and each sentence carries distinct information.

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

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

For an 8-parameter mutation with no output schema, the description covers the return payload (the etag) and the important write semantics. Secondary parameters like content_type and passport_token are left entirely to the schema, which is acceptable given full schema coverage but leaves room for slightly richer context.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds a cross-parameter constraint the schema does not encode: exactly one of value or value_base64. It also frames the etag workflow for if_match rather than just restating its definition.

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

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

States a specific verb and resource (store a value in your memory locker under a key) plus the defining trait that it persists between sessions. It also names locker_get as the etag source, which implicitly separates it from the read/delete/list siblings in the locker_* family.

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

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

Explicitly tells the caller to send exactly one of value or value_base64, and explains the concurrency contract (pass etag as if_match so an overlapping run cannot silently overwrite). It gives clear usage context but never names an alternative tool or states when not to use this instead of, say, share_set or queue_put.

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 destructiveHint=true and idempotentHint=true, but the description adds two things the annotations don't: the messages of the acked leases are permanently deleted, and a lease that expired and was reclaimed is reported in a 'lost' field rather than silently acked. That 'lost' nuance is genuinely useful safety context for 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?

Two short sentences with no padding, and the destructive outcome is front-loaded. The 'Done:' opener is slightly cryptic as a leading token but does signal the completion semantics efficiently.

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

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

For a destructive, idempotent operation the safety profile is covered by annotations and the schema is fully described, but the description still omits the ack-vs-nack decision and any notion of how partial or failed acks are reported. The 'lost' note helps but does not close those gaps.

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

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

Schema description coverage is 100%, so every parameter (queue, leases, instance_id, passport_token) is already documented, and 'these leases' refers to the leases array. The description adds no format, limit, or cross-reference detail beyond the schema, so baseline 3 applies.

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

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

The description conveys the effect ('the messages of these leases are deleted') and the opening 'Done:' hints at successful completion, but it never states the action verb (acknowledge) or the resource in its own words — that lives only in the title. It gives no signal distinguishing this from the closely related queue_nack 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?

There is no explicit guidance on when to call this versus alternatives; the natural pairing with queue_nack (return messages for retry) is never mentioned. 'Done:' only weakly implies the job-completed case, leaving the agent to infer the decision rule.

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

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

Annotations already declare destructiveHint=true and non-idempotent behavior, and the description adds the crucial mechanic that it sets the end time from now and can shorten a lease if the supplied timeout is shorter than the remaining time. It also notes expired leases are skipped, though it does not cover partial failures or authentication details.

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

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

The description is a single sentence that front-loads the purpose and includes the key edge case. It does not redundantly restate schema fields.

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

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

With rich schema descriptions and an explicit destructive annotation, the description supplies enough behavioral context for correct invocation. It stops short of explaining batch/partial-result behavior or errors for expired leases, which would matter for a mutating bulk operation.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics for visibility_timeout_seconds: it is a new absolute end offset from now, not an extension increment, and can reduce remaining time. The queue, lease list, and instance_id parameters are fully documented in the schema.

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

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

The description states the core effect precisely: leases that have not expired get a new end time of now plus visibility_timeout_seconds. It clearly concerns queue lease duration rather than claim/ack/nack siblings, though it never explicitly names an alternative.

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 phrase 'More time for long work' implies the use case, but there is no explicit when-not guidance or comparison to queue_claim, queue_ack, or queue_nack. An agent must infer that it applies only to already-claimed, unexpired leases.

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 destructiveHint=true, idempotentHint=true, readOnlyHint=false, so the safety profile is covered structurally. The description adds nothing about permanence, whether a deleted reminder can be recovered, or error behavior for an unknown reminder_id — zero added behavioral 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?

It is a single short sentence with no waste, but brevity here reflects under-specification rather than economy — a destructive mutation tool warrants more front-loaded detail than one clause that merely echoes the title.

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 destructive, non-reversible mutation with no output schema, the description should clarify consequences and confirmation expectations. It conveys nothing an agent could not already infer from the name, title, and annotations, leaving the description functionally empty.

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 (instance_id, reminder_id, passport_token) are fully documented in the schema itself, including their source fields. The description contributes no additional parameter semantics, which is the baseline expectation at this coverage level.

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 simply restates the tool name and title ('Delete a reminder to your human') without adding any specificity about what a 'reminder' is or how deletion differs from siblings like reminder_update, reminder_list, or reminder_create. It is effectively a tautology.

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 on when to use this versus reminder_update (which might cancel or modify) or other delete siblings such as delete_ask, schedule_delete, or wakeup_cancel. No prerequisites or exclusions are stated.

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

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

Adds substantial value beyond the annotations: it discloses irreversibility ('cannot be restored'), the exact blast radius (token, sessions, app sign-ins), what is NOT destroyed (owner balance and utilities), that repeat calls are harmless, and the specific failure mode returned when a keyed passport tries a token ('signature_required'). This is precisely the context an agent needs before a destructive call.

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

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

Front-loads the irreversible consequence, then the reassurance, then the auth rules — the right priority order. Slightly dense in the final sentence and the balance/utilities reassurance is a touch wordy, but no sentence is filler.

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

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

A zero-required-parameter destructive tool with no output schema: the description covers what happens, whether it can be undone, what survives, idempotency, and both auth paths including the error case. Nothing an agent needs before invoking is missing.

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

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

Schema coverage is 100% and the single parameter is already documented, so the baseline is 3. The description still adds meaning by tying passport_token to the auth model and explaining the consequence of misusing it (signature_required), which the schema alone does not state.

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

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

States a specific verb and resource: 'End your passport for good', with the effect enumerated (token, sessions, app sign-ins stop). An agent immediately knows this is irreversible termination, not a suspension. It doesn't distinguish itself from the sibling remove_passport (which could plausibly read as a synonym) or rotate_token, which is the only meaningful ambiguity left.

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

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

Gives concrete conditions and alternatives: an MCP-created (no key) passport may revoke itself with its own token as a kill switch, while a keyed passport must send a signed request. It also flags that the MCP app's own sign-in may already perform this, steering the agent away from redundant calls. No explicit guidance on choosing between revoke_passport and remove_passport.

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 readOnly=false, destructive=false, idempotent=true, so the mutation safety profile is covered. The description adds genuinely non-structured context: who the real caller is (in-chat cards, not the agent), which is the single most important behavioral fact about this tool. It stops short of saying whether a save replaces prior picks or how failures surface.

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

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

Two short sentences, front-loaded with the scoping constraint and immediately followed by the prohibition and the read alternative. No filler or restated 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 tool agents should generally not call, this fully answers the operative question ('should I call this? no, use get_owner_picks'). No output schema exists, so no return-value explanation is owed; only edge behavior on save (overwrite semantics, error handling) is unstated.

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 each parameter already carries a description, an example object, and a format pattern for chat_token. The description adds no parameter-level meaning beyond the schema, so the baseline 3 applies.

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

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

The description makes clear this writes the human's selections on behalf of the shop-window cards, and the title supplies the verb ('Record'). It distinguishes the write path from get_owner_picks, though it never plainly states 'stores the ticked items' — the action is inferred from the calling context rather than asserted.

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

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

Explicit when-to-use (AgentMart shop window, when your human presses Send), explicit when-not (Agents: never call it yourself), and an explicit alternative for the read case (get_owner_picks). Nothing is left to inference.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is known. The description adds real value by disclosing that associated runs are also deleted (a cascade), but it stops short of saying whether that is permanent or reversible.

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

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

A single short sentence with the destructive scope front-loaded; nothing is wasted. It is arguably too terse for a destructive operation, but it is not padded.

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

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

With annotations carrying the destructive flag and full schema coverage, the description covers the essentials. It omits cascade consequences detail and any note about effect on already-executed runs, which matters for a delete tool.

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

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

Schema description coverage is 100% — instance_id and schedule_id are documented with their source tools, and passport_token is explained. The description adds nothing beyond the schema, so the baseline of 3 applies.

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

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

The description uses a specific verb and resource ('Delete a repeating wake-up') and even notes the cascade ('and its runs'). It does not, however, differentiate from nearby siblings such as wakeup_cancel, reminder_delete, or schedule_update, so an agent still has to infer which deletion tool applies.

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 on when to delete versus disable/update (schedule_update) or use an alternative wakeup/reminder deletion tool. No prerequisites (ownership, instance scoping) or warnings about irreversibility are stated.

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

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

Annotations already establish readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds useful result-context beyond annotations: items include price and verified agent reviews, digital products include build effort, and kits include test results. It does not describe ranking or pagination, but with annotations present this is solid added 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 two sentences and front-loads the action with "Search the shelves." The second sentence is somewhat long and marketing-flavored, but it still earns space by explaining result metadata in the absence of an output schema.

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

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

Inputs are fully covered by the schema and safety is covered by annotations, but there is no output schema, so the description should carry more of the return-shape burden. It gives partial result content but does not explain result structure, ranking, pagination, or filtering behavior sufficiently for full 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 description coverage is 100%, and the schema itself documents q/query precedence, shelf enum meanings, passport_token behavior, and max_price_cents filtering. The description adds essentially no parameter meaning beyond the metaphor "shelves," so baseline 3 is appropriate.

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

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

The description says "Search the shelves" and explains what item results include, but "shelves" is a metaphor rather than an explicit resource like "catalog." It does not distinguish this search tool from siblings such as get_item or list_reviews, leaving purpose only adequately clear.

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

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

There is no explicit guidance on when to use this tool versus alternatives. The search intent is implied by the name, but the description does not mention get_item, list_reviews, or any condition for choosing search over direct retrieval.

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 adds substantial behavior beyond the annotations: daily digest cadence, that only new entries trigger emails, that site_name null clears the value, and detailed return statuses for email deliverability and digest scheduling. It matches the mutation/destructive annotations without contradicting 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 description is front-loaded with the purpose and the details generally earn their place, including return-value context since no output schema exists. It is dense and uses nested parentheticals, which slightly reduces readability.

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?

Because there is no output schema, the description usefully explains the return shape and email status meanings. It omits some auth/parameter details covered by the schema and does not describe error behavior, but it is otherwise complete for this operation.

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

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

Schema coverage is 100%, so the baseline is 3, but the description introduces a conflicting constraint: it says site_name is 1 to 60 characters while the schema allows maxLength 240. It also does not mention passport_token, though the schema documents 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 uses a specific verb ('Change') and clearly names the resource and the two settings affected: the daily digest email and the site name shown on the thank-you page. This is distinguishable from sibling tools despite not naming a direct alternative.

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

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

It clearly indicates the context for use ('Change your form inbox's settings') and clarifies that either or both settings may be sent. It does not explicitly name alternatives or when not to use it, but the usage 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 already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true. The description adds valuable format and size constraints, including request-size limits, but does not explain what existing content is overwritten or how the destructive behavior works.

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

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

Three front-loaded sentences, each earning its place: purpose and formats, payload selection, then base64-specific size limits. There is no wasted or redundant text.

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

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

Useful for a 7-parameter mutation tool with rich schema coverage, but it omits a key behavioral detail for a destructive publish operation: whether existing share content is replaced. The format and size guidance is strong, but the overwrite semantics should be explicit.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by giving size limits and clarifying when to use content versus content_base64, though it does not explain several schema-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 verb and resource: publish content on your share link. It also gives the human-visible purpose and supported formats, which clearly distinguishes it from read-oriented siblings like share_get.

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

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

Provides a clear usage context: publish content so a human can see it. It also guides payload choice between content and content_base64, but does not explicitly compare this tool with alternatives or state when not 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 only say this is not read-only, not destructive, not idempotent, and not open-world; the description adds the operationally important facts an agent could not infer: 7-day link lifetime, a 20-links-per-day limit, first-browser-only binding, the pick link never completes a purchase, and that picks arrive as chat messages in MCP App hosts. This is exactly the kind of context annotations cannot carry.

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

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

The purpose is front-loaded, but the body is a dense run-on of warnings and parentheticals, including nested asides like '(reopen_shop_window (at /mcp only))', which makes it hard to scan. Device-binding rules, rate limits, and purchase caveats are interleaved rather than grouped, so the same idea (first browser to press Open) is stated twice.

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

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

For a tool with no output schema and a non-idempotent write-like effect, the description covers the return artifact (pick_url), expiry, rate limits, device constraints, and the downstream read-and-confirm workflow. It is comprehensive on behavior; the only gap is that it omits how the agent supplies credentials in the normal case versus the passport_token fallback.

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

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

Schema coverage is 100%, so all four parameters are already documented in the schema, including the note length and the paying-owner precondition. The description reinforces this by saying to put up to 12 recommended items first with a short plain-words note and no links, but it adds little syntax or format detail beyond the schema. Baseline 3 applies.

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

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

The opening sentence gives a concrete verb and resource: show what AgentMart sells as priced cards in plain words and let the human pick. It implicitly separates itself from search_catalog (which finds slugs) and get_owner_picks (which reads the results). The core purpose is clear, though it is entangled with procedure and warnings rather than stated as a clean one-liner.

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

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

Explicit guidance exists: send pick_url only in a private message, never open it yourself, use reopen_shop_window for another device, read picks with get_owner_picks and confirm before buying. Alternatives are named with the condition that selects them. What is missing is an explicit statement of when NOT to call this at all (for example, when a shop window is already open).

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?

Adds substantial detail beyond the annotations: the link lives 7 days, the human must tick a waiver checkbox, payment happens on Stripe in USD, and the machine url expires in about 30 minutes. This complements the openWorldHint/non-idempotent hints with concrete lifecycle behavior without contradicting 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?

Front-loaded with the primary action and tightly worded, but the telegraphic run-on style ('...set for_agent_wallet: true to also get url...') requires re-reading to parse the conditional branch cleanly.

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

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

With no output schema, the description still names the key return values (pay_link, url) and the completion path (poll top_up_status), so an agent knows what it gets back. Minor gap: it doesn't state where pay_link appears in the response, but the necessary flow is covered.

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

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

Schema coverage is 100%, so all three params are already documented. The description reinforces the for_agent_wallet meaning ('machine payment', 'never give url to a human') but adds little new syntax, and does not mention the amount_cents enum, leaving that to the schema.

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

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

States a specific verb and resource: 'Create a payment link to fund your balance.' It immediately distinguishes the two distinct flows (human pay_link vs machine for_agent_wallet url), so an agent can tell exactly what the tool produces.

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

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

Explicit routing: 'Humans always use pay_link' vs 'Only for a machine payment by your own agent wallet set for_agent_wallet: true'. It also names the follow-up sibling tool ('Then poll top_up_status'), converting a two-step flow into unambiguous instructions.

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 idempotentHint=true, but the description adds meaningful context beyond them: it specifies that results and incidents are deleted, not just the watch itself. It stops short of stating irreversibility or whether confirmation is required.

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

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

Two short sentences, zero filler, with the action and its consequence front-loaded. Nothing is redundant.

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 destructive, no-output-schema tool whose parameters are fully documented in the schema and whose safety profile is covered by annotations, the description supplies the key missing piece — what data is lost. Only irreversibility/confirmation guidance is absent.

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

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

Schema coverage is 100% and both parameters carry their own descriptions pointing to uptime_add/uptime_status and list_utilities. The description adds no parameter detail, so the baseline 3 applies.

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

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

States a specific verb+resource (stop watching a URL) that is unmistakably distinct from uptime_add and uptime_status. The second sentence clarifies the effect, so an agent knows exactly 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?

Usage is implied by the name and title — you call it when you want to stop monitoring a URL — but there is no explicit guidance on preconditions (e.g., confirming via uptime_status first) or when not to use it versus other remove-style tools.

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 destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered by structured data. The description contributes the useful detail that only pending wakeups are affected, but says nothing about what happens on an already-fired wakeup, whether the cancel is recoverable, or whether the call errors versus silently succeeds.

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

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

One tight sentence with the scope restriction front-loaded after the action. Nothing is wasted and no information is buried.

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?

Annotations carry the destructive/idempotent profile, the schema fully documents all three parameters, and no output schema exists, so the description's remaining burden is light. It covers what is cancelled and the precondition; only the error behavior on an already-fired wakeup is left unstated, a minor gap.

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 each parameter already documents its provenance (wakeup_id from wakeup_schedule or wakeup_list, instance_id from buy or list_utilities, passport_token conditional usage). The description adds no parameter-level meaning beyond this, so the baseline 3 applies.

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

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

States a specific verb (cancel) and resource (wake-up call) and adds a meaningful precondition: only calls that 'have not fired yet (scheduled or retrying).' Siblings wakeup_schedule and wakeup_list are not named, so the distinction relies on the agent inferring from the resource name, but the action itself 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?

The state restriction 'has not fired yet (scheduled or retrying)' implies when the call is applicable, which is more than nothing. However, it never names an alternative path (e.g., wakeup_list to inspect state first) or states what to do if the wakeup already fired, leaving the agent to guess at the failure route.

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 this read-only and non-destructive, but the description adds meaningful context: what fields are returned, that balance_expires_at indicates expiry without top-up, that email_hint is masked, that notices include joined agents / new-network tokens / lockdowns, and that at most one question may appear and should be answered once with send_feedback. It does not claim side effects for whoami itself.

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 content is a single sprawling sentence with nested parentheticals and semicolons, making it hard to scan. While most clauses carry relevant information, the structure is poor and not front-loaded beyond the opening phrase.

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

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

There is no output schema, so the description must explain return values, and it does so extensively for a complex multi-field response. It is largely complete for an agent to understand what comes back, though it omits error/no-passport cases.

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 one optional parameter has 100% schema description coverage, so the schema already explains passport_token fully. The description adds no further parameter semantics, which is acceptable given the high coverage and the baseline of 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 makes clear this returns the caller's own passport, credential strength, balance, spend limit, notices, pending reviews, and an optional question. It is more than a restatement of the title because it enumerates the returned information, though it does not explicitly contrast itself with siblings like list_passports or top_up_status.

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

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

Usage is implied by 'whoami' and 'Your passport' rather than stated as a when-to-use rule. The description gives downstream guidance (tell your human, answer once with send_feedback, call leave_owner if the owner is wrong) but does not say when to call this tool instead of 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?

The description adds substantial behavioral detail beyond the annotations: the owner is notified via answer links, nothing is recorded, the status becomes withdrawn, and the question continues to count against ask limits until expires_at. These are exactly the side effects an agent needs to know before invoking a mutation tool.

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

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

The description is front-loaded with the core action and then layers on the necessary behavioral details without wasted sentences. Every clause contributes either usage context, side-effect disclosure, or the limit/idempotency constraints.

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 a three-parameter mutation with no output schema, the description is complete enough: it covers what happens, what is recorded, how limits are affected, idempotency, and the answered-question restriction. Annotations already cover safety hints, so the description adds the remaining behavioral context.

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

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

Schema description coverage is 100%, with ask_id, instance_id, and passport_token all documented in the schema itself. The description does not add parameter-specific meaning beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description states a specific verb and resource: withdraw a question to your owner that is still waiting for an answer. It clearly explains the intended state change, but it does not explicitly distinguish this from the sibling tool delete_ask, so sibling differentiation is only implicit.

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

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

It gives a clear condition for use: the question is still waiting and you no longer need it. It also states when not to use it, since an answered question cannot be withdrawn and repeated withdrawal changes nothing, though it never names delete_ask as an alternative.

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