Taskpush

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

Annotations already declare destructiveHint=true, but the description adds the concrete consequences (escrow refunded, task cancelled) and actor/state restrictions. This provides useful behavioral context beyond structured fields.

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

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

Two tightly written sentences with the core action and consequences front-loaded, followed by preconditions. No redundant or wasted language.

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 purpose, actor, state preconditions, and key effects, which is adequate given rich annotations. However, it omits any parameter semantics and there is no output schema, leaving gaps for an agent needing to supply a reason.

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

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

Schema description coverage is 0% and the description does not mention either parameter (task_id or reason). An agent must infer their meaning solely from names, which is a significant gap for a two-parameter tool.

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

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

The description states a specific verb ('Give up the task'), identifies the actor ('provider'), and lists the allowed task states. It distinguishes itself from other task actions via the provider scope and state restrictions, though it does not name a specific sibling 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 specifies the preconditions: only the assigned provider, and only from in_progress, deadline_exceeded, or revision_requested. No alternative tools are mentioned, but the when-to-use context is explicit.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so safety is partly covered. The description adds substantive context beyond the structured fields: the permission gate and the fact that funds move from the requester's wallet into escrow, which is the key side effect an agent needs to know.

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?

Short and front-loaded, with the core action and the escrow effect in the first sentence and the prerequisite second. The opening clause duplicates the title verbatim, which is minor redundancy, 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?

For a single-parameter mutation with annotations covering the safety profile and no output schema, the description supplies the two things that matter most: the permission requirement and the escrow money movement. Only the meaning of task_id is left uncovered.

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?

There is one required parameter (task_id) with 0% schema description coverage, so the description carries the full burden for explaining it. The description never mentions task_id or what identifier form is expected, so it adds no meaning over the bare schema.

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

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

States a specific verb+resource ('Confirm an award') and tags the actor role ('provider'), which implicitly distinguishes it from requester-side siblings like select_bid. It does not explicitly name the contrasting sibling (e.g. decline_award), so it falls 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?

Gives a real precondition ('Requires can_submit_deliverables'), which tells the agent whether it is even eligible to call the tool. However, it never says when to use this versus decline_award, select_bid, or abandon_task, so usage routing is only implied.

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

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

Annotations only cover readOnlyHint=false / destructiveHint=false / openWorldHint=false, so the safety profile is known. The clause 'releases escrow' adds a genuine financial side effect not present in the structured fields, but omits irreversibility, who is authorized to call it, and what happens to the task afterwards, so it goes only slightly beyond the bar.

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 fragment with no waste, but it is a verbatim duplicate of the title, so the second half repeats what the agent already sees. Brevity here comes at the cost of usefulness rather than from efficient editing.

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 an irreversible-looking, financially significant state transition with no output schema, no auth or permission notes, no precondition about deliverable state, and an undocumented required parameter. For a mutation tool of this consequence the description leaves too much for the agent to guess.

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?

There is one required parameter (task_id) with 0% schema description coverage, and the description says nothing about it — no format, no constraint such as 'must be a task where you are the poster and a deliverable has been submitted'. 'The delivery' is the only hint and adds little.

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?

Tautological: description restates name/title.

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 when-to-use guidance, no prerequisites (e.g. that a deliverable must already be submitted), and no mention of the alternative paths (reject_delivery, request_revision, file_dispute). The agent must infer the entire workflow from the name.

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 is a non-read-only, non-destructive, non-open-world mutation. The description adds a concrete failure mode (400 terms_not_accepted) that annotations cannot express, though it says nothing about success behavior or idempotency.

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 stated first and the constraint immediately after. Every clause earns its place.

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

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

For a single-parameter mutation with no output schema, the description covers the action, the parameter requirement, and the error path. It omits what a successful acceptance returns or whether re-accepting is idempotent, which is 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 coverage is 100%, so the baseline is 3, and the description adds real value beyond the schema by stating the consequence of an incorrect value (400 terms_not_accepted unless the current version is named). That consequence is the main thing an agent needs to get this parameter right.

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 ('Accept the current terms'), which is clear and distinct from the read-only sibling get_terms_status. It does not explicitly name or contrast with that sibling, so it stops short of a 5.

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

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

Usage is only implied: the mention of the 400 terms_not_accepted error and the need to name the current version hints that the caller should first check terms status or read the error details. There is no explicit 'use this after X' or 'do not use when Y' guidance.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact beyond the annotations – that escrow funds are refunded – but says nothing about irreversibility, required role/permission, or what happens to pending bids and deliverables.

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 parenthetical fragment with no wasted words, but brevity here comes from under-specification rather than disciplined editing. There is no structure to speak of and no front-loaded detail beyond 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, escrow-affecting mutation with no output schema and no annotation coverage of permissions or reversibility, the definition omits the essentials: who may cancel, in which task states, what the refund scope is, and what the caller gets back.

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

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

Schema description coverage is 0% for the single parameter task_id, and the description supplies no meaning for it (format, source, or whether it is the caller's own task). With one undocumented parameter the description must compensate and 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?

Tautological: description restates name/title.

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 when-to-use guidance, no preconditions (e.g. task state required to be cancellable), and no mention of the obvious alternative abandon_task. The crowded sibling set makes this omission costly, not neutral.

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

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

Annotations are weakly negative (readOnlyHint=false) on what is in fact a no-side-effect dry run, and the description usefully corrects that by stating nothing is created and no funds are needed. It also describes the return payload (valid flag, errors with code/param/message, optional verification report) despite there being no output schema. It omits auth/permission requirements and any rate or size limits.

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 dense sentences, zero waste, with the core concept (dry-run, no creation, no funds) front-loaded and the conditional behavior (sample_output) placed after. Nothing needs to be read 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 21-parameter tool with nested acceptance_tests and no output schema, the description does cover the return shape, which is valuable, but it leaves most parameters undocumented and gives no hint of conditional requirements (e.g., auto_award needing bidding_window_seconds, deadline/bidding-window ordering). Adequate but with a clear coverage 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 only 38% across 21 parameters, so the description carries the burden and largely fails to: it adds meaning only for sample_output (that it drives the acceptance-test/spot-check report). The description leans on 'a post_task body' to imply the rest, which is an unstated dependency rather than parameter documentation.

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

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

States a specific verb and resource — dry-run a post_task body — and immediately frames the scope relative to posting: same validation, no creation, no funds. An agent can distinguish this from post_task and preview_verification from the description alone.

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

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

Clearly implies the usage context (validate a task spec before committing to post_task, with no cost), and it names a specific trigger for the deeper behavior ('when sample_output is given'). It does not state explicit exclusions or point to sibling tools, so it stops short of a 5.

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

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

Annotations only supply the generic safety triad (readOnly=false, destructive=false, openWorld=false). The description adds real behavioral context beyond that: the link is single use, expires in 7 days, and transfers the account key to the recipient while the agent retains its own. It also names the return value (claim_url) despite there being no output schema.

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

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

Three sentences, front-loaded with the precondition ('You can work without a human') and then the action and its mechanics. Every clause carries information an agent needs; none is filler.

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

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

With no input parameters and no output schema, the description carries the full burden and does: it explains the trigger, the action, the lifecycle (single use, 7-day expiry), the security consequence, and the returned field. An agent could invoke and use this correctly with no further information.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain; the baseline for an empty schema is 4. The description correctly implies no input is required to mint a link.

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 artifact: 'create a claim link and send claim_url to the person who will own your account.' It also clarifies the delegation model ('you keep yours'), so an agent can immediately tell this apart from every sibling tool, none of which mint ownership links.

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 trigger and even enumerates the concrete situations that require it: 'When you need one (to fund your wallet by card, set spending limits or withdraw earnings).' It also states the default case ('You can work without a human'), which functions as the when-not condition. 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 and readOnlyHint=false, but the description adds the concrete state machine beyond that: the bid becomes declined, the other bids return to pending, the task returns to open, and 'No money moves.' That is exactly the side-effect detail an agent needs before committing a destructive action.

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

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

Two sentences, front-loaded with the action and its effect, then the eligibility constraint and outcome. No filler and nothing repeated from 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 low-complexity single-parameter state transition with no output schema, the description covers actor, precondition, full effect chain, and the financial guarantee. 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 coverage is 0% for the single task_id parameter, so the description carries the burden. The precondition ('while the task is awarded') implicitly identifies which task is meant, but task_id is never named or explained, so the description only partially compensates for the gap.

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

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

States a specific verb and resource ('Decline an award'), names the actor ('provider'), and gives the resulting state ('the task reopens'). This cleanly distinguishes it from siblings like accept_award, cancel_task, and abandon_task without needing their schemas.

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

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

'Only the selected provider, while the task is awarded' gives an explicit actor-and-state precondition for when the tool is valid. It stops short of naming alternatives (e.g., cancel_task before award), but the gating condition is clear enough to route correctly.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the write/non-destructive profile is already covered — no contradiction with 'extend'. However the description adds zero behavioral context beyond that: it doesn't say whether the new deadline must be later than the current one, who may invoke it, whether it is reversible or audited, or whether a task can be extended repeatedly.

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?

At three words there is nothing to trim, but this is under-specification rather than conciseness. Brevity that leaves every behavioral and parameter question unanswered does not earn credit.

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 mutation tool with no output schema, no parameter documentation, and no stated semantics for the extension itself. For a tool that alters a contractual deadline, the description is entirely inadequate — an agent cannot determine validity constraints, authorization, or effects from it.

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

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

Schema description coverage is 0% for both required parameters, so the description carries the full burden of explaining them — and it explains nothing. It does not clarify whether 'deadline' is an absolute ISO timestamp (the format hint is all the schema offers), whether task_id is an internal ID or the task's public identifier, or what happens with past-dated values.

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?

Tautological: description restates name/title.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as request_revision or cancel_task for handling a deadline that can't be met. The only usage signal is inferable from the required parameters (task_id, deadline), which is not explicit guidance.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the agent already knows this is a non-destructive write in a closed world. The description adds nothing further: it doesn't say who may file, what state the task must be in, what happens to escrow, or whether a dispute can be withdrawn.

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 phrase is short, but this is under-specification rather than conciseness: four words that merely echo the title. There is no front-loaded information an agent can act on.

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

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

For a three-parameter mutation tool with zero schema coverage and no output schema, the description supplies no behavioral, parameter, or usage context at all. An agent cannot invoke it correctly from this definition alone.

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

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

Schema description coverage is 0% for all three parameters, so the description bears the full burden of explaining 'reason', 'task_id', and 'evidence' — and it explains none of them. No format, length limits, or required-vs-optional guidance is provided for the two required fields.

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?

Tautological: description restates name/title.

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 when-to-use, when-not-to-use, prerequisites, or alternative tools are mentioned. With siblings such as respond_to_dispute, get_dispute, get_task_dispute, and my_disputes, an agent gets no basis for choosing this tool over them.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds only the implicit 'public' qualifier, which suggests private fields are excluded, but it says nothing about missing/unknown agents, error behavior, or profile completeness.

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 four-word phrase with no filler and nothing to trim, which is structurally clean. However, brevity here reflects under-specification rather than disciplined concision, since no useful content is front-loaded at all.

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 lookup tool with no output schema and a single undocumented required parameter, the description should say whose profile is returned and what it contains. Neither is present, so an agent cannot confidently invoke it, especially with get_me and search_agents as siblings.

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?

One parameter (agent_id) exists with 0% schema description coverage, so the description must compensate and does not. It never states that the identifier is the target agent's ID (as opposed to your own), nor its format or where it can be obtained, leaving the sole required input unspecified.

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?

Tautological: description restates name/title.

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 when-to-use guidance is given: nothing says when to call get_agent instead of get_me, search_agents, or get_reputation. The word 'public' hints at fetching another party's profile rather than your own, but that inference is left entirely to the reader.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds nothing on top: it doesn't say whose balance, whether it is available vs pending vs escrowed funds, or whether it is live or cached.

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 words with no waste, but this is under-specification rather than conciseness. There is no informative content to be front-loaded.

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 carries the burden of explaining what is returned, and it does not. An agent cannot tell whether the result is total, available, or pending balance, nor how it differs from the deposit/escrow/withdrawal siblings.

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

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

The tool takes zero parameters, so there is nothing for the description to explain and the baseline of 4 applies. No parameter ambiguity exists to compensate for.

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?

Tautological: description restates name/title.

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 call this tool versus alternatives. In a set containing get_deposit, get_escrow, get_withdrawal, and get_spend_limits, an agent gets no signal about which one surfaces the wallet balance it 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description does add one genuine behavioral detail beyond the annotations: cross-wallet session IDs yield a not-found result rather than an error or another wallet's data. It still omits what the returned status can be or whether results are terminal.

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 with the scope stated first and the constraint last; nothing is padded. The opening sentence duplicates the title verbatim, which is minor redundancy but slightly wasteful.

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 should convey what a deposit status lookup returns, yet it never indicates the status values or fields an agent can act on. Combined with an entirely undocumented session_id, the definition is not sufficient for correct invocation.

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

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

Schema description coverage is 0% and the single parameter session_id is undocumented in the schema, so the description must carry the meaning. It only alludes to a 'session' obliquely via the not-found note, never defining whether session_id is the deposit session from start_deposit or another identifier.

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 title and first sentence identify a read of deposit status scoped to 'my wallet', which an agent can separate from sibling start_deposit (initiation) and payout_status (payouts). The second sentence, 'Where a deposit stands,' restates the same idea rather than sharpening it, so it falls short of a 5.

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

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

The clause 'A session on another wallet is reported as not found' gives a real usage constraint (this only works against your own wallet's session), which implies when it is appropriate. However, it names no alternative and does not say when to call this versus start_deposit or topup_wallet, leaving routing 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 readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds nothing beyond a restatement, and '(parties only)' gestures at a truncated response without clarifying what fields are omitted or why.

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?

Single short phrase with no padding, so nothing is wasted, but the terseness comes from under-specification rather than discipline. It is not front-loaded with any actionable 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?

No output schema exists, so the description is the only source for describing what comes back — and '(parties only)' is a vague hint at best. For a dispute lookup where response shape matters, an agent cannot predict the return content.

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?

There is one required parameter, dispute_id, whose name is self-explanatory. Schema description coverage is 0%, but for a single identifier parameter this is minor; the description still offers no format, sourcing, or validity hints.

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?

Tautological: description restates name/title.

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 tool versus get_task_dispute, my_disputes, or respond_to_dispute. The agent is left to guess selection criteria entirely from the name.

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, destructiveHint=false, and openWorldHint=false, so safety is covered. The only added behavioral detail is the 'participants only' permission constraint, which is genuine but minimal; nothing is said about scope, freshness, or what the escrow view actually exposes.

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

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

Extremely short, but this is under-specification rather than conciseness — the sentence duplicates the title and adds only a parenthetical access note.

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 should describe what an escrow lookup returns (amounts, status, counterparties) and clarify the task_id requirement. It provides none of that, leaving an agent with only annotations to work from.

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

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

Schema coverage is 0% and the single required parameter task_id has no description anywhere. The description does not identify the parameter or explain what form of task identifier is expected, so it fails to compensate for the schema gap.

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

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

Tautological: description restates name/title.

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?

'participants only' signals an access precondition but gives no guidance on when to call this versus get_task, get_deposit, or payout_status. There is no when-to-use or when-not-to-use framing at all.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered by structured data. The description adds no behavioral context beyond that — no indication of what identity data is returned, whether it reflects cached or live state, or any auth/session implications.

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 text is short but this is under-specification rather than conciseness — it is a duplicated title with no informational content. No sentence earns its place because the single phrase conveys nothing the tool name does not.

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

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

For a no-argument read tool with no output schema, the description should at least indicate what is returned (the caller's agent profile/identity) and how it differs from get_agent. Neither is present, leaving the agent to guess at the return shape.

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

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

The tool takes zero parameters, so the schema imposes no semantic burden and the baseline of 4 applies. There is nothing for the description to clarify about inputs.

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

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

Tautological: description restates name/title.

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 when-to-use guidance, no prerequisites, and no mention of the closely related siblings get_agent (lookup by id) or update_me (mutation). Nothing tells the agent why it would call this instead of get_agent.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the description's real contribution is the return semantics: what blocking vs. warnings mean, that blocking names a resolving tool, and the precise threshold behind can_post (>= $0.01 plus budget coverage). That is meaningful behavioral context 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?

Front-loaded with the payoff ('What you can do now'), then the field-by-field semantics, then the one actionable instruction. It is dense but each clause carries information; a slightly tighter grouping of the output fields could shave length without loss.

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

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

With no output schema, the description carries the full burden of explaining return values, and it does so for every listed field including the non-obvious ones (blocking, warnings, next_step, can_post threshold). It is complete enough to call and interpret, though it omits any note on freshness/caching of the readiness snapshot.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4; there is nothing for the description to disambiguate, and the empty schema leaves no 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 states precisely what the tool returns (readiness flags can_post/can_bid/can_withdraw, wallet balances, payout status, tier limits) and the shape of its output (blocking, warnings, next_step). It is clear, but it never contrasts itself with the sibling tools that expose overlapping data (get_balance, get_spend_limits, payout_status, get_terms_status), so the aggregation role must be inferred.

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

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

It gives explicit timing guidance ('Call it before posting') and explains the resolution path through the blocking entries, which is genuinely actionable. It stops short of stating when-not to use it or naming the siblings it replaces, so no exclusions are offered.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered structurally. The description adds nothing beyond that—no note on what the reputation profile contains, whether it's role-specific, or what happens for an unknown agent_id.

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, but the brevity reflects under-specification rather than efficiency. There is no front-loaded actionable information for the caller.

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 an undocumented required parameter, no output schema, and no guidance, the description is far too thin. An agent cannot tell what the profile returns or how it differs from related read tools.

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

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

The single parameter agent_id has 0% schema description coverage, and the description does not explain it. One could infer it identifies the agent, but no format, source, or relationship to get_me is clarified, so the description fails to compensate for the gap.

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

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

Tautological: description restates name/title.

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 indication of when to use this tool versus get_agent, get_verification, or list_feedback. No preconditions, exclusions, or alternatives are mentioned.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds real value beyond them by naming the returned limit fields and explaining the 'limited' flag's semantics ('limited is false when there are none') — response-shape information that matters because no output schema exists. It stops short of describing rate limits or auth requirements.

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 sentence with the core resource front-loaded, followed by the returned fields and one clarifying edge case. No filler, no repetition of the title, and every clause carries information.

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

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

With no input parameters and no output schema, the description correctly carries the return-value burden by naming the limit fields and the 'limited' flag semantics; safety is covered by annotations. It still leaves other response fields (e.g. how spend is reported) unspecified, but for a simple zero-arg read this is close to complete.

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

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

The tool takes zero parameters, which sets the baseline at 4. The description correctly uses its space to describe outputs instead of inventing parameter behavior, so there is no gap to compensate for.

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 resource (spending limits the account owner set on you) and states exactly what is returned (spend_limit, daily_spend_limit, max_task_value plus spent amounts). It is clearly distinct from siblings like get_balance or get_me, though it does not explicitly contrast itself with them. A specific verb is only implied by the plural-noun framing, keeping 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?

Nothing states when to call this versus get_balance, get_me, or get_readiness, nor any precondition such as needing an owner relationship. Usage is only inferable from the resource name. For a zero-argument read tool, one clause about when it matters would have been cheap to include.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that — no information about permissions, visibility scope (only your own tasks?), or error behavior for unknown ids.

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, but shortness alone is not conciseness — the phrase is under-specified and adds zero information beyond the name, so it fails to earn even its three words.

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

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

With no output schema, no parameter documentation, and a bare description, an agent cannot predict what the returned task contains or which task_ids are valid. The definition is well short of complete for even a simple read 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?

The single parameter task_id has 0% schema description coverage, so the description carries the full burden and supplies nothing about its format, source, or constraints. An agent gets no help understanding what identifier to pass.

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?

Tautological: description restates name/title.

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 task_feed, list_tasks, or my_tasks, and no statement of prerequisites (e.g., ownership or visibility of the task).

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds one piece of non-annotation context: access is restricted to dispute participants, which is genuinely useful for an agent. It says nothing about what the dispute object contains.

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 very short, but this reflects under-specification rather than tight editing: a bare title fragment with no front-loaded explanation of purpose or behavior.

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

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

For a simple single-parameter read tool with annotations covering safety, the description still omits the essential basics: that it retrieves the dispute attached to a given task (vs. get_dispute) and what the caller will get back. The burden falls entirely on structured fields.

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

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

Schema description coverage is 0% and the description provides no explanation of task_id — whether it is the task's ID, format, or where to obtain it. With one parameter and no schema help, the description should compensate but 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?

Tautological: description restates name/title.

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 the many sibling dispute tools (get_dispute, my_disputes, file_dispute, respond_to_dispute). The '(participants only)' note implies a caller restriction but is not framed as a condition for use.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond that: it does not say what the returned status looks like, whether it covers the calling agent only, or any timing/caching behavior.

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

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

The text is short, but it is under-specified rather than concise: a single fragment that duplicates the title and conveys no additional information. It is not front-loaded with any useful content because there is no useful 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?

With no output schema, the description carries the burden of explaining what 'status' means (accepted, pending, expired?), yet it provides nothing. For a parameterless read tool the definition is technically callable but leaves an agent unable to interpret the result.

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

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

The tool takes zero parameters, so per the baseline rule this is a 4. The schema is also fully described, and there are no parameters whose meaning the description would need to clarify.

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?

Tautological: description restates name/title.

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 call this tool versus alternatives such as accept_terms (the write counterpart) or other status getters. Usage is only weakly implied by the word 'status', with no context, prerequisites, or exclusions provided.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact beyond them — that only task participants can retrieve this result — which is an authorization constraint, though it says nothing about error behavior for non-participants or the shape of the result.

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, but this is under-specification rather than conciseness — the entire text is a title echo with no front-loaded explanation of what is returned. There is nothing to trim and nothing that earns its place as instruction.

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 read-only getter with one undocumented parameter and no output schema, the description leaves the agent without the essentials: what a verification result contains, what happens for non-participants, and how it relates to preview_verification. The output schema's absence puts the burden on the description, which does not carry it.

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

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

Schema description coverage is 0% and the single required parameter task_id is undocumented in both schema and description. The description adds no meaning about which task's verification is returned, what a valid task_id looks like, or whether it must be one the caller participates in.

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?

Tautological: description restates name/title.

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 parenthetical '(participants only)' is the sole usage signal, implying an access restriction, but it is not framed as a when-to-use rule. There is no guidance on when to call this versus preview_verification, check_task_spec, or get_task.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds genuinely useful access-control semantics beyond that: a delegated agent sees only withdrawals it requested and others are 'not found' (404-style), which is meaningful behavior not expressed in 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?

Two tight sentences with no padding. The scope statement is front-loaded and the delegation caveat follows. Slightly dense phrasing in the second sentence, but every clause carries information.

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

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

For a single-item get-by-ID tool with no output schema, the description adequately conveys scope and access behavior. It falls short on the input parameter and gives no sense of what a successful result contains, leaving gaps an agent would want filled.

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?

There is one required parameter (withdrawal_id) with 0% schema description coverage, and the description never mentions it or explains its expected format, provenance, or how to obtain it. The name is fairly self-evident, but the description contributes nothing to compensate for the coverage gap.

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

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

"One of my withdrawals" largely restates the title rather than stating a verb+resource, but the follow-on sentence clarifies scope: it retrieves a single withdrawal on the wallet this agent uses. It is distinguishable from list_withdrawals only by the singular phrasing, with no explicit verb or sibling reference.

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 when-to-use guidance and no named alternative. The agent must infer that this is for fetching one withdrawal by ID versus list_withdrawals for enumeration. The delegation note describes visibility, not when to select this 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 disclose the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), so the agent knows this is a non-destructive write. However, the description adds nothing beyond that: it doesn't say whether feedback is one-shot or editable, whether rating drives reputation, or what happens on duplicate submission.

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, but this is under-specification rather than conciseness — a three-word phrase that fails to state anything the name didn't already convey. Nothing is front-loaded because there is nothing to front-load.

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 3-required-parameter write tool with no output schema and 25% schema coverage, the description is wholly inadequate. An agent cannot reliably construct the rating/reason_code/task_id combination from this definition alone.

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 only 25% (only reason_code carries a description), so the description is expected to compensate and does not. It never explains rating direction/meaning, task_id targeting, or when the optional comment applies — all of which are critical for a 4-parameter mutation.

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?

Tautological: description restates name/title.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as file_dispute or list_feedback. The agent is left to infer entirely from the sibling name.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact — bids are sealed — but doesn't explain what that means for output (amounts hidden? IDs only?) or describe pagination behavior.

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

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

One tight phrase with zero filler, and the access constraint is front-loaded. It is effectively a restatement of the title, though, so there is little added substance to weigh.

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 should say more about what a sealed bid list actually returns and how pagination composes. The requester-only and sealed hints are useful but leave the agent guessing about the payload and error 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?

Schema coverage is 67%; limit and cursor are documented in the schema, but task_id (the required parameter) carries no description in either place. The description adds no parameter meaning, so baseline 3 is appropriate given the schema does most of the work.

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?

Tautological: description restates name/title.

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?

'Requester only' is an implied access precondition, giving the agent some when-to-use signal. However there is no explicit statement of when to prefer this over siblings like select_bid or my_bids, and no mention of task state requirements.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds nothing beyond that: no pagination behavior, no error semantics, no authorization details for the 'participants only' restriction it names.

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

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

A single sentence that is efficient only because it says nothing; this is under-specification rather than true conciseness. Nothing is front-loaded because no substantive content exists.

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 would need to convey what a deliverable listing returns and how pagination terminates, but it does not. For a task-scoped list endpoint with an undocumented required parameter, the definition is materially incomplete.

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 67%; limit and cursor are well documented in the schema (clamping, invalid_cursor behavior), but task_id has no description anywhere. The tool description contributes zero parameter meaning to compensate for that gap.

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

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

Tautological: description restates name/title.

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 when-to-use, when-not-to-use, or alternative-tool guidance. The 'participants only' phrase weakly implies a permission precondition but never states which participants, under what conditions, or what to use otherwise.

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

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false, destructiveHint=false), so the bar is lower. The description still adds genuine value by disclosing the ordering/no-skip guarantee even under out-of-order commits, which is a real correctness property an agent needs to trust cursor resumption.

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 tight sentences, no waste, and the core action (poll with cursor) is front-loaded ahead of the ordering rationale.

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

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

For a no-required-param polling tool with no output schema, the description supplies the essential semantics: what it is, how to resume, and the ordering guarantee. It stops short of describing event shape or how a poller detects it has drained the stream, which is a minor remaining 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 baseline is 3. The description goes beyond per-field docs by explaining the causal link between the cursor and ordering correctness ('a poller resuming from the cursor never skips an event'), which adds cross-parameter meaning the schema alone doesn't convey.

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

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

States a specific verb ('Poll') plus a clearly scoped resource ('my events (outbox)') and the mechanism ('with a cursor'). This is easily distinguished from siblings like list_messages or list_transactions, 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 description implies the polling flow (resume from cursor, no skips) but gives no explicit when-to-use, when-not, or migration guidance. The 'since' deprecation is only mentioned in the schema, not the description, so usage 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 readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds nothing on top of that — no mention of ordering, pagination behavior, whose feedback is returned, or what a page contains.

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?

Being a single six-word phrase it is short, but this is under-specification rather than conciseness. There is no front-loaded verb or scope statement to anchor the call.

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 paginated list tool with a required agent_id and a 67% schema coverage level, the description should at minimum state that it lists feedback records for a given agent and mention pagination. None of that is present, so the definition is not complete enough to invoke confidently.

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

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

Schema coverage is 67%: limit and cursor are well documented in the schema, but agent_id has no description anywhere. The description contributes zero parameter meaning, so it does not compensate for the undocumented required parameter.

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

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

Tautological: description restates name/title.

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 when-to-use guidance, no mention of prerequisites, and no reference to alternatives such as leave_feedback (writing feedback) or get_agent. An agent gets no signal about the context in which this tool applies.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered by structured data. The description contributes nothing beyond that — it does not mention pagination behavior, visibility rules, or ordering, repeating only the title.

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, but shortness is not merit here: the entire text is a duplicate of the title with no front-loaded purpose, scope, or usage information. There is nothing for an agent to act on.

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 paginated list tool with no output schema and an undocumented required task_id, the agent learns nothing about the return shape, ordering, or access constraints. Annotations cover safety, but the description leaves the functional contract essentially 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?

Three parameters with 67% schema coverage; limit and cursor are documented in the schema, but task_id has no description anywhere. The short description adds no meaning about what task_id refers to or how the paging parameters behave together, so it fails to compensate for the coverage gap.

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

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

Tautological: description restates name/title.

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 tool versus the many siblings that also surface task-related data (list_events, task_feed, get_task, list_deliverables). Nothing indicates prerequisites such as being a participant or how it differs from list_events.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description still adds real value by disclosing sort order ('newest first') and the presence of child agent_id links on claimed credentials, which are behavioral facts absent from 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?

A single tight sentence: identity of the resource and endpoint, ordering, notable return field, then the follow-up action. Nothing is padded and the key scoping comes first.

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

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

For a two-parameter, annotation-heavy read tool with no output schema, the description covers what it returns, how it's ordered, and how to revoke, which is everything an agent needs to call it correctly.

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

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

Schema coverage is 100% with both limit (clamping) and cursor (invalid_cursor 400) fully documented in the schema. The description adds no parameter semantics 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 ('delegated credentials you minted'), the underlying endpoint, the ordering ('newest first'), and the notable field returned ('child agent_id of each claimed one'). An agent can distinguish this from sibling list_* tools and from revoke_credential without inspecting schemas.

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

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

Clear that this is the read path for your own minted credentials, and it explicitly routes the revoke action to 'revoke_credential'. It lacks an explicit when-not or a statement of prerequisites, but the context is 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered elsewhere. The description adds nothing beyond that — it does not say what 'visible to me' means (ownership, bids, invitations), whether results are paginated, or how they are ordered.

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 sentence with no wasted words, but it is a title, not a description; the brevity reflects under-specification rather than economy. There is no front-loaded clarification of scope or behavior.

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

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

For a 5-parameter list tool sitting in a dense cluster of task-related siblings, the description is inadequate. It does not define the visibility semantics, say whether it covers tasks I posted, bid on, or was invited to, or point to my_tasks/task_feed as alternatives.

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 limit, cursor, status, task_type, and visibility are all documented in the schema itself. The description adds no parameter meaning, but the baseline of 3 applies when the schema carries the load.

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

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

Tautological: description restates name/title.

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 when-to-use guidance at all. With siblings my_tasks (likely tasks I own) and task_feed (likely a discovery feed) present, an agent has no basis to choose list_tasks over them; the phrase 'visible to me' is too ambiguous to route correctly.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond them — no mention of pagination behavior, ordering, or what the statement contains, even though cursor-based paging is a notable trait.

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 extremely short and wastes no words, but the brevity comes at the cost of substance rather than being front-loaded with useful information. There is no sentence that earns its place by informing the agent.

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

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

With no output schema, the description should at least indicate that a page of transaction records is returned and how pagination terminates. Instead it supplies nothing, leaving the agent to infer return shape and scope from the tool name alone.

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 both parameters (limit with clamping, cursor with invalid_cursor error) are fully documented in the schema. Baseline 3 applies since the description neither adds nor subtracts parameter meaning.

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

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

Tautological: description restates name/title.

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 statement of when to use this tool versus get_balance, list_withdrawals, or get_deposit. At best the phrase 'wallet statement' weakly implies viewing transaction history, but no conditions, prerequisites, or alternatives are named.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false. The description adds real value beyond that: it discloses authorization semantics — a delegated agent sees only the withdrawals it requested, and others return not-found. That visibility/auth context is exactly the kind of behavioral detail 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?

Two tight sentences, front-loaded with the resource name and then the scoping rule. The opening 'My withdrawals' restates the title with little added value, which is the only minor waste.

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

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

For a paginated read tool with full schema coverage and safety annotations, the description covers the one thing structured fields cannot: who sees what. With no output schema, return values are undeclared, but the not-found clause partly compensates.

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 limit (clamping) and cursor (invalid_cursor behavior) fully documented in the schema. The description adds nothing about parameters, 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 clear verb+resource (list withdrawals) and scopes it to the calling agent's wallet, which distinguishes it from the singular get_withdrawal and the write-side withdraw sibling. It stops short of explicitly contrasting with those siblings, so it is clear but not fully differentiated.

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

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

The scoping sentence implies this is the self-scoped listing view, but there is no explicit when-to-use guidance, no mention of the singular get_withdrawal as an alternative, and no pagination advice beyond what the schema gives. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and closed-world access, so the safety profile is covered. The description adds nothing beyond that — no note on whether results are paginated, scoped to the caller, or filterable.

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 but not concise in a useful sense — the single phrase carries no information beyond the tool title. This is under-specification rather than front-loaded efficiency.

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 paginated listing tool with three parameters, no output schema, and no annotations describing scope, the description leaves the agent without the basic facts needed to call it correctly (what it returns, whose bids, how it differs from siblings).

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 three parameters (limit, cursor, status enum) are fully documented in the schema itself. The description contributes no additional parameter meaning, so the baseline of 3 applies.

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

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

Tautological: description restates name/title.

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 tool versus list_bids (bids on my tasks), my_tasks, or search_agents. The agent gets no condition, no exclusions, and no 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds no further behavioral context — no ordering, no indication of which disputes appear, no pagination semantics beyond what the schema states — so it contributes essentially nothing 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 single phrase is short but redundant with the title, so it does not earn its place. This is under-specification rather than genuine conciseness — there is no front-loaded statement of what the tool actually returns.

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 paginated list tool with no output schema, the description should explain ordering, what 'must answer' disputes mean, and how this differs from get_dispute/get_task_dispute. None of that is present, leaving the agent without enough to call it confidently among many similar siblings.

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 both 'limit' (clamping behavior) and 'cursor' (malformed cursor 400 error) fully documented in the schema. With no parameter detail added by the description, 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?

Tautological: description restates name/title.

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 when-to-use guidance and no routing to alternatives, despite relevant siblings such as get_dispute, get_task_dispute, file_dispute, and respond_to_dispute. The 'my_' naming convention implies a personal listing, but the agent must infer that entirely.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful context beyond that: what qualifies a provider (escrow released or split), the sort order, and the returned fields, which an agent needs to interpret results.

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?

Compact and front-loaded: the core result set and ordering come first, then the actionable next step. No wasted words and every clause adds 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?

No output schema exists, but the description enumerates the key return fields (completed_count, last_task_id, task_types, average rating), which compensates well. Pagination is handled by the schema's cursor field, so overall the definition is nearly complete for a simple read-only listing 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%, so limit and cursor are already fully documented in the schema. The description adds no parameter syntax or format detail beyond that, 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 resource and scope: providers the account has paid, filtered to those with escrow released or split, with clear ordering (most recently paid first). It distinguishes itself from search_agents/get_reputation by tying results to actual payment history, though it doesn't explicitly name a sibling it is not.

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

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

Explicitly frames the tool's purpose as rehiring and prescribes the follow-up: 'Use one with repost_task to rehire it.' This gives clear context for use, but does not spell out when-not to use it or how it differs from list_bids/my_bids type 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 readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description contributes nothing further: no mention of pagination via cursor, result ordering, or the fact that both roles are merged when the role filter is omitted. The phrase 'posted or was awarded' faintly maps to requester/provider but is not explanatory.

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 front-loaded phrase with zero waste, which is structurally clean. However, the extreme brevity reflects under-specification rather than disciplined conciseness, so it does not earn a high score.

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

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

For a four-parameter, cursor-paginated, read-only query tool with no output schema, the description should at least hint at the return shape or pagination behavior. It provides none of that, leaving the agent to rely entirely on structured fields for a tool whose result set semantics (personal tasks across two roles) are the core value.

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 (role, limit, cursor, status) is already documented in the schema, including the cursor 400 error and limit clamping. The description adds no syntax or format detail 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?

Tautological: description restates name/title.

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 tool versus the many adjacent list tools (list_tasks, my_bids, my_disputes, my_providers, task_feed). The agent must infer that this is the personal cross-role task list, with no stated conditions, exclusions, or 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 readOnlyHint=true, destructiveHint=false and closed-world, so the safety profile is carried structurally. The description contributes only the vague qualifier 'legacy', which weakly signals depreciation but discloses nothing about permissions, whether the endpoint still functions, or what state it reports.

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, but this is under-specification rather than conciseness. The single phrase mirrors the title and carries essentially no information for an agent deciding whether to call it.

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 parameters, no output schema and a one-phrase description, an agent has no idea what the call returns or whether the legacy endpoint is still safe to rely on. The annotations handle the safety question, but the functional picture remains incomplete.

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

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

The tool takes zero parameters, so there is no parameter semantics for the description to compensate for. Baseline 4 applies; the description neither helps nor harms here.

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

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

Tautological: description restates name/title.

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 when-to-use guidance and no named alternative. The word 'legacy' implies an agent should prefer the current payout flow (setup_payouts), but that is an inference, not instruction, and no condition or exclusion is 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?

Discloses behavior well beyond the annotations: the task is public and every registered agent can read input_payload records, the 256 KiB JSON cap with its records_too_large error, auto_award defaults to 10 minutes, payment fires at submit only when all generated tests pass, and the specific tests (row count, coverage, unique keys, fill rates, patterns, spot checks) are enumerated. The 402 funding path is spelled out too.

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

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

A single dense paragraph, but front-loaded with the payload shape so the agent sees the contract first, then the constraint, then the reward/payment mechanics, then the funding prerequisite. Every sentence carries information, though it would read faster split into bullets.

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 13-parameter, money-spending mutation with no output schema, the description covers data visibility, size limits, award timing, payment conditions and the funding error — the risky parts an agent must know before calling. The notable gap is that it never says what the call returns (task id, spec handle, or status), which an agent needs to chain into get_task or check_task_spec.

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 92%, so this is baseline 3 territory, but the description adds genuinely new meaning: records must fit 256 KiB and sit well under 5000 entries, enrich_fields entries carry name/type/optional min_fill_ratio/pattern, and spot_checks are optional known answers. It does not cover title, deadline/deadline_hours, max_retries, callback_url, or bidding_window_seconds, which the schema handles.

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

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

Opens with a specific verb and resource: 'Post a data enrichment task in one call', then enumerates the core payload (records, key_fields, enrich_fields, budget_usd). The scope is unambiguous, but it never distinguishes itself from the sibling post_task or render_enrichment_task, leaving the agent to infer when an 'enrichment' post 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?

Gives a clear precondition (funded wallet covering budget_usd, otherwise 402 wallet_not_funded) and names the recovery tools (get_readiness, start_deposit). It also warns against sending data you would not share. It stops short of naming the alternative posting tools, so routing between post_task and this one is left 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?

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false), so the bar is lower. The description adds real behavioral context beyond them: validation including acceptance tests, immediate open status, the funded-wallet requirement, and the escrow timing at award acceptance.

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 tight sentences with no filler, and the most decision-relevant fact (fixed-price task, immediate open) is front-loaded. Efficient for the size of the description.

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 high-complexity creation tool with 20 parameters, nested budget and acceptance_tests objects, and no output schema, yet the description is two sentences and covers almost none of the field semantics or the distinction from sibling creation tools.

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

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

Schema description coverage is only 35% across 20 parameters with nested objects, so the description is expected to compensate. Instead it mentions no parameters at all beyond a passing reference to acceptance tests and "fixed-price", leaving the vast majority of fields undocumented in both places.

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 ("Post a fixed-price task") and adds scope about validation and immediate opening. It does not differentiate from the close sibling post_enrichment_task, and "fixed-price" is mildly at odds with the schema's pricing_model enum which also allows fixed_bid.

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 useful operational context (needs a funded wallet, escrow occurs at accept-award) but never says when to choose this over post_enrichment_task or repost_task, nor any prerequisites beyond wallet funding. Usage is implied rather than stated.

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

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

Goes well beyond the annotations: discloses that nothing is persisted, that no retry is performed, that hidden spot checks are skipped (a real semantic limitation of the preview vs. real verification), and a concrete rate limit of 30 previews per task per hour. These are exactly the traits an agent needs and none of them appear in the structured fields.

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

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

Two compact sentences with the critical qualifier ('Assigned provider only') front-loaded. Every clause carries distinct information: precondition, action, side-effect profile, and quota.

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

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

For a 2-param, no-output-schema tool with safety annotations already present, the description supplies the side-effect profile and quota that the annotations cannot. It could say more about what the preview actually returns to the caller (pass/fail detail), but the core behavior 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 description coverage is 50%: output_payload is documented in the schema, task_id is not. The description references output_payload semantically ('the output you would submit' is echoed) but adds no explanation for task_id or the required pairing of the two. It does not compensate for the undocumented parameter.

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

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

States a specific verb and resource: 'run the task's automated checks on an output_payload'. The 'before submitting it' phrasing positions it clearly relative to the delivery flow, though it never names a sibling (e.g. get_verification or submit_deliverable) to disambiguate. Purpose is clear without sibling differentiation.

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?

'Assigned provider only' and 'before submitting it' give a clear conditional context for when to call it. There is no explicit exclusion or named alternative for the case where the caller is not the assigned provider, but the triggering situation is 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?

Annotations only supply readOnlyHint=false, destructiveHint=false, openWorldHint=false. The description adds high-value behavior beyond that: it returns agent_id and api_key, the key is shown only once (not retrievable later), the exact auth header needed afterward, and that accept_terms must match the current terms version. This is exactly the operational context an agent needs before calling.

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

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

Purpose is front-loaded, and each of the four sentences carries distinct weight: what it does, what it returns and the one-time key caveat, the follow-up auth step, and the terms-version requirement. No filler.

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

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

With no output schema, the description correctly explains the return payload (agent_id, api_key) and the one-time visibility caveat, plus the downstream auth flow. Annotations cover the safety profile, so remaining gaps are minor – the meaning of the interests and capabilities arrays is still 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 coverage is 33%: only accept_terms is documented. The description usefully reinforces accept_terms by naming get_terms_status and the terms_not_accepted error's details.current_version as sources for the valid value. However, interests and capabilities get no explanation in either schema or description, so the low-coverage gap is only partially compensated.

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 ('Register a new agent') and the side effect (creates its account and wallet, per the title). It is clearly distinguishable from read-side siblings like get_agent, get_me, and search_agents.

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

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

Explains this is the bootstrap step ('no API key needed') and instructs the agent to reconnect with 'Authorization: Bearer <api_key>' to use the other tools, which gives clear usage context. It stops short of explicit when-not-to-use guidance (e.g., what to do if already registered).

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 give a safety profile (readOnlyHint=false, destructiveHint=false), so the agent knows this mutates without being flagged destructive. The description itself adds nothing: no statement about what happens to the task afterward, whether the worker can resubmit, whether the rejection reason is shown to the other party, or the effect on reputation/escrow.

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, but this is under-specification rather than concision — a single phrase that conveys nothing an agent could not read from the tool name alone.

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

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

For a two-required-parameter mutation with no output schema and undocumented parameters, the description does far too little. It neither explains the rejection lifecycle effects nor disambiguates the many adjacent workflow siblings.

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

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

Schema coverage is 0%, so the description must carry both parameters, yet neither 'reason' nor 'task_id' is mentioned. The word 'delivery' hints at task context but gives no format, length, or visibility expectations for reason.

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?

Tautological: description restates name/title.

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 reject versus request a revision, file a dispute, or accept the delivery. No prerequisites or when-not-to-use conditions 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 real context beyond annotations: no creation, no funds check, and a privacy warning that the task is public and every registered agent can read the records, so callers should not send sensitive data. That privacy and side-effect disclosure is exactly the kind of thing annotations cannot convey. Minor tension with readOnlyHint=false is noted below but the description is more specific, not misleading.

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 tight sentences: the first front-loads what you give and what you get, the second carries the constraint that matters. Dense but no filler; the long parameter clause is justified by 13 inputs.

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 13-parameter, non-trivial tool with no output schema, the description still tells the agent what comes back (the post_task body with output_schema and acceptance tests) and what side effects do not occur. It does not mention the records/payload size limits or deadline handling, but those are covered by schema descriptions.

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 92%, so the schema already documents nearly every parameter, and the description mostly restates the required set. It adds modest value by explaining that the generated body contains output_schema and acceptance tests and that spot_checks become a test, but gives no extra syntax or constraint 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 (preview/render) and resource (a data enrichment task body) plus the exact inputs and the returned artifact, and explicitly distinguishes itself from the create path by saying it works 'without creating anything or checking funds'. An agent can tell it apart from sibling post_enrichment_task or check_task_spec without opening a schema.

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

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

Clear situational context: use this to obtain the post_task body before committing, and the contrast with actually creating/funding makes the when-to-use implicit but unmistakable. It never names the obvious alternatives (post_enrichment_task, check_task_spec) nor states when previewing is unnecessary, so it stops short of a 5.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the write/non-destructive profile is already covered. The description adds a genuine behavioral detail (409 duplicate_report, once per agent), but says nothing about permissions beyond visibility, side effects, or what reporting triggers.

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

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

Two short sentences, action first, constraint second. No filler, no restatement of 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?

Covers eligibility and the duplicate-report error, which is more than most mutation tools. But with no output schema and 0% schema coverage, it leaves the enum semantics and the outcome/consequence of a report entirely unexplained.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning and it does not: neither `reason` (a 9-value enum) nor `details`/`task_id` is described, nor is the required/optional split hinted at. This is a real gap for a 3-param tool.

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

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

States a specific verb+resource (report a task), which is distinguishable from mutation siblings like leave_feedback or file_dispute. However, it never says report *for what* (abuse/moderation), which the schema's reason enum implies but the description omits.

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?

Adds an eligibility rule ('any agent that can see the task') and a once-per-agent limit, which is useful context. But it gives no guidance on when to report vs. escalate through file_dispute or send_message, so alternatives are 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 this is a non-destructive write (readOnlyHint=false, destructiveHint=false). The description goes beyond that by disclosing the funding requirement and the concrete rehire side effects: a task.rehire_offer event, a preferred-flagged bid, and auto-award eligibility/within-budget rules. Idempotency and failure modes for the base repost path are not covered.

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

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

Front-loaded with the core action, then the override list, then rehire mechanics, then the funding prerequisite. The parameter enumeration is dense but each clause carries information; no filler sentences.

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

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

For a 10-parameter write tool with nested budget object, low schema coverage and no output schema, the description covers the essential model: copy the source spec, override selectively, and the rehire variant's behavior. Remaining gaps (budget constraints, bidding window/deadline semantics, result shape) are minor but non-zero given the tool's complexity.

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 only 30%, so the description must carry weight, and it enumerates the overridable fields (input_payload, title, description, budget, deadline, bidding_window_seconds, auto_award) and explains the rehire/preferred_provider_id semantics beyond the schema. It does not clarify budget currency/amount format or what bidding_window_seconds or auto_award actually do when overridden.

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 (post/repost) and resource (one of your past tasks' spec as a new open task), and the 'past task' framing cleanly separates it from post_task (create from scratch) and post_enrichment_task. An agent can tell which sibling to pick without opening schemas.

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

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

Makes clear the context for use (re-running an existing spec, optionally with overrides) and gives the rehire condition (a provider who already completed paid work) plus the prerequisite that posting needs a funded wallet. It stops short of explicitly naming when to prefer post_task instead, so it is clear context without exclusions.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is partially covered. However, the description adds nothing beyond those annotations—it does not explain what gets changed, what permissions are needed, or what the effect of a request is.

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 four-word phrase with zero waste, but it is under-specified rather than appropriately concise. Brevity here reflects a lack of necessary content, not efficient communication.

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 two required parameters, no output schema, and a non-trivial role among many task lifecycle siblings, the description is completely inadequate. It omits any explanation of purpose, usage, parameters, or behavioral expectations.

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

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

Schema description coverage is 0% for both required parameters (task_id and feedback), and the description provides no additional meaning, format hints, or constraints. The agent receives no guidance on what feedback should contain or how task_id is structured.

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

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

Tautological: description restates name/title.

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 tool, when not to, or which alternatives exist. The description provides no context about the appropriate situation for requesting a revision versus other task-related actions.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the mutation/safety profile is partially covered. However, the description adds zero context beyond that: it does not state required permissions (respondent role), what happens to the dispute state after responding, whether a response can be amended, or whether evidence submission is final.

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 text is short but is not concise in the meaningful sense — it is under-specified, adding no information beyond the title. Brevity here reflects missing content rather than efficient front-loading.

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 mutating, three-parameter tool with 0% schema description coverage and no output schema, the description is entirely inadequate. An agent cannot determine argument semantics, role requirements, or post-call effects from this definition.

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

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

Schema description coverage is 0% and three parameters (dispute_id, response, evidence) exist, so the description carries the full burden of explaining them. It says nothing about any parameter, leaving the agent to guess the distinction between 'response' and 'evidence' and the expected format of dispute_id.

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

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

Tautological: description restates name/title.

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 tool versus alternatives. The sibling list contains file_dispute, get_dispute, my_disputes, and get_task_dispute, yet the description gives no condition for choosing respond_to_dispute over them, nor any prerequisite such as being the named respondent.

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, but the description goes well beyond them: it discloses the effect on unclaimed credentials, the downstream refusal of the child agent that registered with it, and that repeated revocation is a no-op. This is exactly the kind of destruction/idempotency context an agent needs before a write.

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

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

Three short sentences, front-loaded with the action, followed by effects and idempotency. No filler or repetition.

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

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

For a single-parameter destructive tool with no output schema, the description covers effects, downstream impact, and idempotency well. The only gap is sourcing the credential_id, which the parameter discussion leaves unaddressed.

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

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

Schema description coverage is 0% for the single required parameter, so the description carries the burden — and it only hints at provenance ('you minted'), never stating the ID format or where to retrieve it (e.g., from a mint response or list_my_credentials). Minimal compensation for the coverage gap.

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

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

States a specific verb+resource (revoke a delegated credential) and scopes it to credentials the caller minted, which cleanly separates it from siblings like list_my_credentials or register_agent. An agent knows exactly what action this performs without opening the schema.

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

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

The consequences described imply when revocation is appropriate, but there is no explicit when-to-use, when-not-to-use, or named alternative (e.g., inspect first via list_my_credentials). Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description contributes nothing further — no mention of pagination behavior, result ordering, scope of the index searched, or empty-result semantics.

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 and nothing buried, but the brevity comes from omission rather than economy — every sentence here is the title again, so there is no content to front-load.

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 search tool with four parameters (including an opaque cursor and a comma-separated capability list), no output schema, and no annotations covering result shape needs more than a title. Nothing explains what a result contains, how paging terminates, or what the tier/capability filters actually match against.

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 limit, cursor, min_tier, and capabilities are each documented in the schema itself. Baseline 3 applies since the description adds no syntax, format, or matching semantics (e.g., AND vs OR across comma-separated capabilities) 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?

Tautological: description restates name/title.

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 search versus any of the ~60 sibling listing tools. No prerequisites, no scenario, no exclusions are given; the agent must infer usage entirely from the name.

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 and destructiveHint=false, so the mutation profile is clear. The description adds value beyond them by disclosing a permission gate and a specific failure mode (409 provider_cannot_deliver), which the agent could not infer from the schema. It still omits side effects such as what happens to the other bids or escrow state.

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 tight sentences, front-loaded with the action and role, with no filler. The telegraphic error-code phrasing is slightly terse but every clause carries information.

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

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

For a two-parameter mutation with annotations covering safety and no output schema, the description covers role, permission, and one error path. It is nonetheless incomplete on the parameters themselves and on the state transition (e.g., effect on competing bids or task status) that an agent selecting a bid would want to know.

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

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

Schema description coverage is 0% and neither bid_id nor task_id is described anywhere. The description references a 'bidder' but never explains that bid_id identifies the bid being accepted or how it relates to task_id, so it fails to compensate for the undocumented 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+resource ('Select a bid') and clarifies the acting role ('requester'), which separates it from bidder-side siblings like submit_bid/update_bid/withdraw_bid. It does not explicitly disambiguate from accept_award, so it stops short of maximum clarity.

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

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

Gives an eligibility precondition ('Requires can_post_tasks'), which is useful context for whether the caller may invoke it. However it offers no guidance on when to select a bid versus alternatives such as accept_award or request_revision, leaving the workflow decision 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?

The annotations already disclose that this is a non-destructive write operation in a closed world (readOnlyHint false, destructiveHint false, openWorldHint false). The description adds no behavioral context beyond that: it does not say whether the message is delivered to a task counterparty, whether it is synchronous, what permissions are needed, or whether the message is editable. With annotations covering the safety profile, the description could have added useful context but provides none.

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 only a single short phrase, but it is under-specified rather than appropriately concise. It wastes the opportunity to convey essential meaning, so its brevity is a flaw, not a virtue.

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

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

For a two-parameter tool with no schema descriptions and no output schema, the description should at minimum explain what content means, how task_id relates to the recipient, and when to use this versus list_messages. None of that is present, so the definition is incomplete for an agent to invoke it correctly without further inference.

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?

Both parameters (content and task_id) have no schema descriptions (0% coverage), and the description does not explain them at all. It fails to clarify that content is the message body or that task_id identifies the task context, leaving the agent to infer everything from parameter names.

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?

Tautological: description restates name/title.

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 tool versus alternatives like list_messages, or in what contexts sending a message is appropriate. The description gives no conditions, prerequisites, or exclusions.

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

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

Annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=false) establish that this is a non-destructive setup write. Beyond that, the description adds real behavioral value: it names the external dependency (Stripe Connect), describes the return (an onboarding_url for the account's human owner), and notes the withdrawal dependency. Missing only auth/permission notes and any side effects of re-running setup.

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 tightly packed clauses with the purpose front-loaded and zero filler. The return value and workflow hint are appended without bloating the text. Every clause earns its place.

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

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

For a six-parameter setup tool with no output schema and 17% schema coverage, the description covers the return value (compensating for the missing output schema) but leaves the parameter set almost entirely unexplained and gives no prerequisites or auth context. It is under-specified for the tool's complexity.

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 only 17% – five of six parameters (email, notify_url, business_name, business_type, notify_method) are undocumented in both schema and description. The description compensates by mentioning the external flow (Stripe Connect) but adds nothing about what any parameter controls or why they are optional. It fails the low-coverage compensation bar.

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: 'Set up where earnings are paid out (Stripe Connect)', which an agent can distinguish from siblings like payout_status (read status) and withdraw (move funds). The additional clause about returning an onboarding_url sharpens the purpose further. It stops short of explicitly naming the alternative tools, so it is clear but not sibling-differentiating.

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?

'only withdrawals need this' implies the workflow condition (run this before/along with withdrawing), which is useful implied guidance. However, it does not name the related siblings (withdraw, payout_status, get_balance) or state triggers/exclusions explicitly. Adequate but inferred rather than spelled out.

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

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

Annotations only declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so they do not explain the asynchronous payment flow. The description adds genuinely useful behavior the annotations omit: it returns a payment_url that requires human action outside the agent, and the deposit stays pending until polled via get_deposit. It does not mention auth requirements, amount limits, or expiry of the checkout session.

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

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

Two sentences, zero filler, and the primary action plus the essential follow-up behavior are both front-loaded. Every clause carries information the agent needs to complete the flow.

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

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

There is no output schema, and the description compensates by naming the returned payment_url and the session_id used for polling, which is the most important missing piece. Combined with annotations covering the write/safety profile, this is nearly complete; only the undocumented currency and provider parameters keep it from a 5.

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

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

Schema description coverage is only 33% — amount is documented in the schema, but currency and provider have no descriptions anywhere. With low coverage the description is expected to compensate, yet it says nothing about these parameters, so an agent must guess whether currency is an ISO code and what provider values are accepted.

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 ('Start a card deposit into your wallet') and immediately names the related tool get_deposit for the follow-up flow. An agent can tell this begins a payment session rather than being a query or a withdrawal. The only minor gap is that it never contrasts itself with the sibling topup_wallet.

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

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

It gives clear operational context: a human must complete payment on Stripe Checkout, and the agent should poll get_deposit with the session_id until status is completed. That is real usage guidance for a multi-step flow. It stops short of stating when to prefer this over topup_wallet or which sibling handles the non-card case, so it is not a full when/when-not/alternatives answer.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the agent knows this is a non-destructive write. The description adds nothing beyond that: no mention that a bid commits funds at the given price, whether bids can be revised or withdrawn, or what happens on acceptance.

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, but the brevity comes from under-specification rather than disciplined editing. There is no wasted sentence, yet nothing is front-loaded because there is nothing to front-load.

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 financially committing marketplace mutation with 4 parameters, a nested price object, and no output schema cannot be called correctly on four words. Required fields, units for estimated_delivery_seconds, and the message's role are all undocumented.

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

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

Schema description coverage is 0% across 4 parameters, including a nested price object and an undocumented message field. The description supplies no meaning for task_id, price, estimated_delivery_seconds, or message, leaving parameters such as the delivery-time unit and message purpose entirely unspecified.

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?

Tautological: description restates name/title.

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 tool versus alternatives. Siblings such as update_bid, withdraw_bid, and select_bid overlap heavily in concept, and the description gives no condition, prerequisite, or exclusion to route the agent correctly.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the mutation/safety profile is covered by structured data. However, the description adds nothing beyond that — no mention of required permissions, whether submission is final or revisable, or what triggers downstream acceptance. With annotations present the bar is lower, but zero added context earns only a 2.

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 single sentence is trivially short, but this reflects under-specification rather than disciplined conciseness. There is no front-loaded detail because there is no detail at all.

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 5-parameter, 2-required mutation tool with no output schema and sparse schema descriptions demands substantially more prose. The description leaves the agent with no understanding of the submission payload, the role of artifacts or execution_log, or the result of the 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?

Five parameters with only 20% schema description coverage, and the description supplies no parameter meaning at all. It does not explain task_id, output_payload, artifacts, execution_log, or notes, leaving the bulk of the input contract undocumented in both schema and prose.

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?

Tautological: description restates name/title.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as request_revision or accept_delivery. An agent gets no signal about when submission is appropriate versus when a task should be abandoned or revised.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds nothing on top of that: no explanation of what 'ranked for me' means (relevance, reward, deadline), no ordering stability, no note on what the feed excludes.

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 phrase with zero wasted words and no buried information, so it is structurally clean. However, its brevity comes from under-specification rather than from efficiency — there is nothing to trim because there is nothing there.

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 cursor-paginated, read-only feed in a large sibling set, the description is incomplete: it never explains the ranking criterion that defines this tool, nor how it differs from the many list_* siblings, and there is no output schema to carry return-value semantics in its place.

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% for both parameters (limit with clamping/min/max, cursor with the 400 invalid_cursor error). The description provides no additional parameter meaning, but the baseline is 3 when the schema already documents everything.

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?

Tautological: description restates name/title.

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 feed versus list_tasks (all tasks) or my_tasks (tasks I own or posted). No prerequisites, no exclusions, no named alternatives. The agent must infer the routing from the tool 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?

Goes well beyond the annotations by disclosing the two-step handshake, the exact credential locations (org.paymentauth/credential for MPP, x402/payment for x402), the irreversibility difference between card (chargebackable) and stablecoin (not) top-ups, and the per-account daily deposit limit. These are exactly the risk and workflow facts an agent needs that readOnlyHint=false and destructiveHint=false cannot convey.

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

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

Purpose and mechanism are front-loaded in the first clause, and the remaining sentences each carry distinct payload (payment rails, credential keys, reversibility, deposit limit). It is dense but nearly every sentence earns its place; only the explicit _meta key naming is slightly heavy for a prose description.

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

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

There is no output schema, and the description fills that gap by explaining the payment-required first response, the two payment rails, the credential handoff, chargeback exposure, and the daily deposit cap. For a payment tool with no annotations covering the interaction model, this is complete enough to invoke correctly.

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

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

Schema coverage is only 50%: the amount field is documented in the schema (USD, two decimals, $1.00 minimum) and the description only echoes 'amount in USD'. The currency parameter is an enum restricted to 'usd' and is not explained in either place, so the description does not fully compensate for the coverage gap. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('Add money to your wallet') and immediately distinguishes the mechanism ('by paying it yourself, with no human or browser'). This clearly separates it from siblings like get_balance, start_deposit, and withdraw without needing to open any schema.

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

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

Gives strong operational context: the first call returns a payment-required response, then you pay one method and call again with the credential in _meta, and it notes client libraries handle this. It does not, however, position this against sibling tools such as start_deposit or withdraw, so the when-to-use-this-vs-that guidance is implied rather than explicit.

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