Agent Bounties

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

Annotations already declare the mutation profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=true), so the safety burden is largely covered. The description usefully adds that accepting 'does not grant signing authority,' clarifying the scope of the state change, but says nothing about failure modes (e.g., accepting a task not assigned to you) or the resulting 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 short sentences, both front-loaded and free of filler; the constraint about signing authority is stated immediately after the action. Nothing is wasted, though the brevity comes partly from under-specification rather than tight 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?

Annotations cover the safety profile and no output schema exists, so return values need not be explained. However, for a mutation tool with 0% schema description coverage, the description omits error behavior, prerequisites, and what state change accepting produces, leaving real gaps.

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

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

Schema description coverage is 0%, so the description carries the burden for the single `id` parameter and provides nothing beyond the schema's `string`/`uuid` typing. For a one-parameter tool where the id is self-evidently the review task identifier, this is minimally acceptable but adds no real meaning.

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

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

The description names a specific verb+resource ('Accept a task') and scopes it to 'your authenticated principal,' which is more precise than the bare name. It doesn't explicitly contrast with siblings like assign_review_task or list_review_tasks, 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?

It implies a precondition (the task must already be assigned to your principal) but gives no explicit when-to-use guidance, no when-not to use it, and never names alternatives such as list_review_tasks or assign_review_task. An agent must infer the workflow context from the sibling names 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?

The description adds useful context beyond the annotations: comments are public, should not contain sensitive data, and do not change canonical lifecycle state. However, it does not reconcile this with destructiveHint=true or explain the mutating nature implied by readOnlyHint=false. No outright contradiction exists because it only denies canonical lifecycle changes, not all state changes.

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

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

The definition is two front-loaded sentences with no filler. The when-to-use trigger comes first, followed by a privacy warning and a behavioral note; every sentence earns its place.

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

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

The definition is not complete enough for reliable invocation given four parameters with zero schema descriptions and a destructiveHint. It covers the core intent and required fields, but leaves optional parameters and side-effect expectations unclear; the presence of an output schema only helps with return values, not input semantics.

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?

With 0% schema description coverage, the description needed to compensate, but it only loosely maps to bounty_id and body via 'one bounty' and 'public comment.' The optional author and comment_id parameters—their purpose, nullability, and UUID behavior—are completely unexplained.

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

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

The description clearly identifies the action: publishing a bounded public comment on exactly one bounty. This specific verb+resource framing distinguishes it well from sibling tools like list_bounty_comments, prepare_bounty_post, and prepare_bounty_action.

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

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

It explicitly states when to use the tool: when the person explicitly wants to publish a public comment on a bounty. It also adds a privacy constraint about secrets and restricted personal data, but it does not name alternative tools or give when-not-to-use conditions.

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 a non-idempotent, open-world mutation, and the description adds real context beyond them: the assignee must accept readiness (so the call is a pending hand-off, not a completed delegation) and the caller's existing wallet still signs the verdict on a first-party page. It does not mention repeat-call behavior for a non-idempotent operation, but the workflow disclosure is genuinely useful.

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 and the key precondition, with no filler. Slightly under-specified for a two-parameter mutation, but nothing is wasted.

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

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

Covers the assignment workflow and the signing/acceptance behavior, which is the hardest part to guess. However, with 0% parameter coverage, no output schema, and no indication of what happens on a rejected or duplicate assignment, an agent still lacks everything needed to invoke it precisely.

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 two required parameters, and the description explains neither: it never says what 'id' identifies (the task?) nor what form 'assignee_principal' takes or how a principal is verified. With no schema-level documentation, the description had to 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?

States a clear verb+resource: assign a review task to a verified agent principal, which an agent can distinguish from the sibling accept_review_task. It stops short of explicitly naming the counterpart tool, so differentiation is inferred from 'the agent must accept readiness' rather than stated.

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

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

Implies the scenario (delegating a review task to another principal) and hints that assignment is not final until acceptance, but gives no explicit when-to-use, when-not, or named alternatives among the many sibling review/bounty tools. 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 destructiveHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is covered externally. The description adds the meaningful caveat that publishing must be explicitly requested, reinforcing the destructive nature, but does not say what exactly is destroyed, what happens on repeat calls, or what authorization the 'authenticated solver' requires.

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 core operation is front-loaded ahead of the publishing caveat. Efficient, though the terse phrasing leans on unexplained jargon.

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 five-parameter, fully-required mutation with no output schema, zero schema coverage, and an open-world destructive profile, the description is too thin. It omits parameter meaning and workflow placement, leaving an agent under-informed about the inputs it must supply.

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 five required parameters (id, round, network, bounty_contract, publish_files). The description only alludes to publish_files ('Publish files only when explicitly requested') and never explains id, round, network, or bounty_contract, 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?

The description names a specific verb and resource: 'Link stored files to an indexed canonical submission by its authenticated solver.' That is more than a restatement of the name. It does not, however, distinguish itself from the very similar sibling prepare_artifact_submission, leaving the agent to infer the boundary.

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 one conditional: publish files only when explicitly requested, and warns that a broadcast is not confirmation. That is useful guidance for the publish_files decision, but there is no statement of when to use this tool versus prepare_artifact_submission or how it fits the surrounding workflow.

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 indicate read-only, idempotent, non-destructive behavior. The description adds relevant behavioral context by stating that sharing 'changes no funding, claim, verification, settlement, or payment state' and by explaining how the original image remains attached when bounty_image_url is passed. No contradiction with annotations.

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

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

The description is compact at three sentences, front-loads the main use case, and avoids generic filler. Each sentence adds meaningful guidance, though the parameter guidance is limited.

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 when to use the tool, the no-side-effect guarantee, and the key image parameter. However, with 8 parameters and only 25% schema coverage, more context about how to populate required fields or how the share card relates to sibling tools would make it more complete. The presence of an output schema mitigates some of this gap.

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

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

Schema description coverage is only 25%, with only stage and bounty_image_url described in the schema. The description adds guidance for bounty_image_url but does little to explain the meaning or expected format of the other parameters, such as title, status, bounty_url, reward, and payment_state. Since coverage is low, the description needed to compensate more.

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 purpose: producing a factual social-ready caption and card intent after a bounty step. It clearly identifies the tool's resource (share bundle/card) and the user goal, though it does not explicitly differentiate it from sibling tools like prepare_bounty_post or prepare_bounty_action.

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

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

The description gives an explicit trigger: 'Use this when the person wants a factual social-ready caption and card intent after a bounty step.' It also clarifies that sharing is optional and has no state-changing effects. However, it does not mention when not to use it or name alternative tools for related intents.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered structurally. The description adds one genuinely useful behavioral fact: these checks do not approve payment, clarifying the decision boundary. It says nothing about staleness of returned checks or how versions relate, so it adds some but not rich context.

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

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

Two short sentences with no filler, and the substantive content (what the tool returns) is front-loaded before the caveat. The only minor cost is the unexplained 'versioned broad checks' phrasing, which adds density without clarity.

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

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

For a zero-parameter, read-only discovery tool with no output schema, the description adequately conveys the shape of what comes back: check versions, parameter schemas, limits, and the proof each check provides. It omits any mention of version selection or result structure, but nothing essential to invoking it is missing.

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

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

The tool takes zero parameters, so there is no parameter semantics for the description to carry and the baseline is 4. Nothing in the description contradicts or confuses the empty schema.

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

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

States a specific verb (find) and resource (versioned checks) plus the payload it returns: parameter schemas, limits, and what each check proves. This reads clearly as a discovery/catalog operation. It falls short of 5 because it never names the sibling it should not be confused with, notably run_verification_checks or get_verification_run, and the phrase 'versioned broad checks' is slightly opaque.

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

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

There is no explicit when-to-use guidance and no routing to alternatives, despite a crowded sibling set (run_verification_checks, validate_verification_plan, get_verification_run). The only usage signal is the boundary caveat 'Checks do not approve payment', which tells the agent what this tool is not for but not when to reach for it.

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

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

Annotations already provide idempotent and non-destructive hints. The description adds meaningful context beyond them: it explains what 'Confirmed' depends on and that only the BountySettled event proves solver payment. It does not contradict the annotations.

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

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

The description is two sentences, front-loaded with the usage trigger, and every clause carries semantic weight. There is no filler or repetition of schema details.

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

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

Given the output schema exists, the one-parameter input, and the annotations, the description covers the key trigger, the meaning of Confirmed, and the decisive event. It could be more explicit about the relationship between intent_id and the action/card, but overall it is adequate for a simple status-check 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 input schema has one required parameter, intent_id, with no description coverage, and the tool description never mentions intent_id or explains what it represents or how it should be obtained. The agent must infer its meaning from the tool name and context, which is a notable 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?

The title and description clearly indicate this tool checks the canonical status of a bounty action, and the description adds the specific confirmation criterion (exact indexed event; BountySettled proves solver payment). It does not explicitly name or contrast sibling tools, 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?

The description explicitly says to use it when the person returns from first-party authorization and the card needs canonical status. It gives a clear trigger condition but does not mention when not to use it or point to an alternative tool among the siblings.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description reinforces the non-mutating nature ('No draft approval or signature') but adds little beyond that, and does not describe return contents or refresh 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?

Two tight sentences: the first front-loads what is read, the second delimits scope by exclusion. No padding, though 'first-party posting journey' is mildly jargon-heavy.

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 parameterless, read-only tool with rich annotations and no output schema, the description is nearly sufficient. It enumerates what is returned, but without an output schema it could say a bit more about the shape of the returned choices.

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 no parameters (Parameter count: 0), so no parameter explanation is required; baseline for zero params is 4. The description correctly does not fabricate 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 (Read) and enumerates the resources returned: review choices, costs, wallet requirements, and the first-party posting journey. An agent understands this is an informational lookup tool, though it does not name or distinguish itself from siblings like get_posting_status or prepare_bounty_post.

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 trailing clause 'No draft approval or signature' implicitly routes the agent away from write/draft tools like prepare_bounty_post, which is useful. However, there is no explicit statement of when to call this versus get_posting_status or other read siblings, so usage 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 already declare readOnly/idempotent/non-destructive, so the bar is lowered, yet the description adds real non-obvious context: it returns a first-party continuation URL and warns against treating an empty index as a failed transaction or restarting payment. The terms are somewhat cryptic (what 'empty index' refers to is unexplained), keeping it from a 5.

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

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

Two tight sentences with the purpose front-loaded and no filler. The caution clause is dense but earns its place; some phrasing is oblique rather than verbose.

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 does state the key return value (the existing continuation URL) and the safety profile is covered by annotations. What 'posting progress' concretely contains remains unspecified, so it is not fully 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?

Schema description coverage is 100% and each parameter is richly documented in the schema (wallet, protocol gating, operation_id session requirement, bounty_contract). The description adds no parameter-level syntax or format detail, so the baseline 3 applies.

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

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

States a specific verb (Read) and resource (canonical posting progress and gas sponsorship) and notes the returned continuation URL, so an agent knows what it retrieves. It does not explicitly distinguish itself from close siblings like get_bounty_action_status, 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?

There is no statement of when to call this versus the many sibling status/read tools (get_bounty_action_status, get_posting_options, etc.). The warnings about not inferring failure or restarting payment are behavioral cautions, not usage 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?

The annotations already declare readOnlyHint, idempotentHint, destructiveHint, and openWorldHint, so the safety profile is covered. The description adds that the manifest is 'authorized' (implying access control) and 'immutable' (cannot change), which is useful but minimal extra context.

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

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

The description is a single front-loaded sentence with no wasted words. It is appropriately concise structurally, though its brevity leaves important details for other dimensions.

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

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

For a simple one-parameter read tool with rich annotations and no output schema, the description gives a basic sense of the operation. However, it lacks parameter meaning, sibling differentiation, and any indication of what the manifest contains, leaving clear gaps.

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

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

Schema description coverage is 0%, so the single 'id' parameter (a UUID string) has no semantic explanation in the schema. The description does not clarify what the id refers to or how it should be obtained, failing 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?

The description states a specific verb (Read) and resource (authorized immutable file manifest), which is clearer than a tautology. However, it does not name verification artifacts explicitly or differentiate from sibling tools like get_verification_run or get_verification_review.

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. It does not mention any prerequisites, exclusions, or sibling tools, leaving the agent to infer usage 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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description's only addition is the cryptic claim that draft/signature/broadcast/confirmed states "stay separate," which gestures at state scoping but never explains what that means for the caller.

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, so it is not bloated, but the second sentence is low-information jargon that occupies space without paying off. Front-loading the read action is fine.

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 must convey what a caller gets back; instead it leaves the return shape and the meaning of the separate states unexplained. For a read tool with one undocumented parameter, this is underspecified.

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 schema only supplies type=string, format=uuid. The description adds that the id identifies a review the caller authored or may sign, implying an access constraint, but gives no naming convention or format 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?

The verb+resource ("Read a review") is identifiable, but the second sentence ("Drafts, signatures, broadcasts and confirmed outcomes stay separate") is domain jargon that does not clarify what is actually returned. It does not distinguish this tool from siblings like get_verification_artifact, get_verification_run, or list_review_tasks.

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 versus list_review_tasks or save_verification_review, nor any stated prerequisites. The phrase "you authored or may sign" hints at an access condition but is never framed as a usage rule.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior. The description adds genuinely useful interpretation context beyond annotations: 'Pass is limited to each check's claim; missing review is not approval' warns the agent not to over-read a passing result. It stops short of explaining the report's structure, but it meaningfully extends what the annotations convey.

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

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

Two short sentences with no filler; the primary action is front-loaded. The second sentence is terse but earns its place as a caveat, though it is slightly cryptic in wording.

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

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

For a single-parameter read tool whose annotations carry the safety profile and with no output schema, the description is adequate but thin: it omits what the stored report contains (per-check claims/status) and how the agent should consume it, leaving the interpretation caveat as the only substantive guidance.

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 sole 'id' parameter is never mentioned in the description. Even though one trivial param lowers the burden, the description does not clarify whether 'id' identifies the run, the report, or a check, so it does not 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?

The description states a verb (Read) and a resource ('the caller's stored check report'), scoping it to the caller's own data. However, it never ties 'check report' back to the tool name 'get_verification_run' or distinguishes this from siblings like get_verification_review, get_verification_artifact, and find_verification_checks, leaving an agent to infer which retrieval tool applies.

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

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

There is no explicit when-to-use guidance. With several sibling read tools (get_verification_review, get_verification_artifact, find_verification_checks), the description does not say when this run report is the right target versus those 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=false, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the mutation and idempotency profile is covered structurally. The description adds genuinely new context: caller authentication is required and the source must be a public repository. It still omits side effects (what entity gets created) and any rate/quota 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?

Two sentences, zero filler, and the hard constraint ('branch name is not accepted') is front-loaded before the requirements. 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 4-required-param mutating tool with 0% schema coverage and no output schema, the description covers the most dangerous traps (wrong revspec, missing idempotency key, auth) but says nothing about the result of an import or how the imported files feed the downstream verification tools. Adequate but not 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?

Schema description coverage is 0%, so the description carries the full burden, and it partially does so: it clarifies that 'commit' must be an exact SHA (not a branch) and that idempotency_key and authentication are mandatory. It adds nothing about 'repository' beyond public-availability, nothing about the 64-item 'paths' cap, and no format examples, leaving real gaps.

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 ('Import selected files from an exact public GitHub commit'), which is specific enough for an agent to know what the tool does. It does not differentiate itself from verification-flow siblings like prepare_artifact_submission or run_verification_checks, so it falls short of a 5.

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

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

Usage is implied by the phrase 'Import selected files', and it usefully states a precondition ('A branch name is not accepted'), which steers the caller toward a valid commit SHA. However, it names no alternative tool and gives no when/when-not guidance relative to the many sibling verification tools, so it is only implied 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 readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so safety and repeatability are covered without the description. The description's only added behavioral signal is the implicit point that unfiltered listing returns non-claimable/unfunded lifecycle states, which is modest but real. With annotations carrying the safety profile, this is adequate but thin.

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

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

Two sentences with no filler: the usage condition comes first and the key parameter guidance second. It is well front-loaded and appropriately sized, though 'canonical lifecycle inventory' is a phrase that costs more reading effort than it repays.

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 only two optional parameters, full schema coverage, and an output schema that carries return-value detail, the description does not need to explain results. It covers the primary invocation decision and the one meaningful flag, leaving only sibling differentiation absent.

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

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

Schema description coverage is 100%, so both parameters are already documented, making 3 the baseline. The description reframes claimable_only as 'currently funded and open to solve' (slightly different from the schema's 'fully funded unclaimed'), which adds marginal clarity, but it says nothing about the network parameter or defaults.

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 plus name establish that this lists bounties, and the description frames it as returning 'funded Agent Bounties work or canonical lifecycle inventory.' However, 'canonical lifecycle inventory' is jargon that doesn't precisely say what is returned, and it never distinguishes this list tool from siblings like get_bounty_feed or render_bounty_feed. Purpose is inferable but not stated sharply.

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

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

It gives a usage cue ('use this when the person wants funded Agent Bounties work') and a concrete sub-case routing ('set claimable_only=true for work that is currently funded and open to solve'). But it never names an alternative tool or an exclusion condition, so the agent gets implied rather than explicit guidance on when to pick this over get_bounty_feed.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful interpretation: results are conversation context and never funding/verification/settlement/payment evidence, and it specifies the single-bounty scope. It does not detail pagination or ordering, but 'recent' plus the output schema covers the practical case.

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

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

Two sentences with no filler; the usage trigger is front-loaded and the semantic caution earns its place by preventing misuse.

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

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

For a single-parameter read tool with strong annotations and an output schema, the description is complete: it gives the trigger condition, scope, and interpretation of the returned data. Nothing needed to call it correctly is missing.

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

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

Schema description coverage is 0%, so the description must carry the burden. It says 'for one bounty,' which communicates that bounty_id identifies the target bounty, but it does not describe the expected format or how to derive the identifier. The meaning is adequate but not fully explicit.

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

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

The description states a specific verb ('read'), resource ('recent public comments'), and scope ('for one bounty'), and the added caution that comments are conversation context rather than funding or payment evidence clearly separates this read tool from monetary verification/settlement siblings.

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

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

It explicitly says when to use the tool: when a person or mounted feed needs recent public comments for one bounty. It does not name alternative tools such as add_bounty_comment, but the trigger condition is clear enough.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so safety is covered. The added sentence 'Assignment grants no wallet signing authority' is a permission caveat, but it concerns assignment rather than listing, making its relevance to this call unclear, and nothing is said about pagination or result shape.

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

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

Two short sentences with the core purpose front-loaded. The second sentence is terse but tangential to listing, so it earns its place only marginally.

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

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

For a zero-parameter read-only list tool with full annotation coverage, the definition is adequate but thin: it never says what a review task record contains or whether results are scoped to the caller, and there is no output schema to fill that 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?

The tool takes zero parameters, so the baseline of 4 applies; there is no parameter semantics for the description 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?

States a specific verb and resource — listing pending review tasks plus deadlines — which is clear at a glance. It does not explicitly distinguish itself from siblings like get_verification_review or list_bounty_comments, but the resource is specific enough to avoid confusion.

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 word 'pending' suggests a first-stop call to see outstanding work, but there is no explicit when-to-use or when-not-to-use guidance and no mention of the natural alternatives (accept_review_task, assign_review_task, get_verification_review).

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

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

The description adds genuinely useful behavior not in the annotations: the cleanup-pause side effect, the authorization constraint, and that the bounty outcome is unaffected. But 'Returns your existing open dispute on retry' describes a repeated call producing no additional effect, which conflicts with the declared idempotentHint=false. Annotations also don't say what state the artifact/dispute enters or what happens to cleanup when the dispute is later resolved.

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, front-loaded sentences with no filler. The most important effect (pausing cleanup) and the permission constraint come first, and each sentence carries distinct information.

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

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

There is no output schema, so the description should carry more of the return/state story; it touches on retry behavior and outcome effects but omits the resulting dispute state and what 'id' refers to. Combined with 0% parameter coverage and a mutation tool (readOnlyHint=false), the definition is adequate but leaves real gaps.

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

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

Schema description coverage is 0%: neither 'id' nor 'reason' is documented in the schema. The description does not compensate—it never says what the id identifies (artifact? bounty? submission?) or what the reason field is for or its 2000-char limit. An agent must guess the identifier's referent.

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 communicates the action and its effect ('pause file cleanup while your dispute is open') and implicitly distinguishes itself from the sibling resolve_artifact_dispute by framing the dispute as becoming open. It never states the verb 'opens a dispute' outright, so the core action is inferred rather than named, but an agent can still tell it apart from the resolve counterpart.

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 owner or a granted participant may do this' gives a clear authorization precondition for using the tool. However, it gives no guidance on when to open a dispute versus calling resolve_artifact_dispute, nor any prerequisite about the artifact's state before opening one.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is partly covered. The description adds genuinely new context: the operation rechecks stored bytes, prepares but does not sign or broadcast, and signing is deferred to first-party wallet pages — a meaningful security boundary an agent would otherwise not 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?

Three tight sentences, front-loaded with the core action and followed by the two key constraints. No wasted words, though 'Recheck stored bytes' is cryptic enough to cost a little clarity.

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

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

For a five-parameter mutation tool with no output schema and zero schema description coverage, the description omits all parameter semantics and gives no indication of what the prepared submission result looks like. The signing/broadcast boundary is covered, but 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 description coverage is 0% across five required parameters, so the schema provides no semantic help. The description only indirectly gestures at bounty_contract ('existing-contract'), solver_wallet ('authenticated solver') and evidence ('stored bytes') without defining any of them, and says nothing about network or id. 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?

The description states a specific verb ('prepare') and resource ('an existing-contract submission') scoped to 'the authenticated solver', which distinguishes it from the confirm_artifact_submission sibling by implying this is the pre-confirmation step. It does not, however, explicitly contrast itself against the many other prepare_* siblings (prepare_bounty_action, prepare_bounty_post), so the differentiation is inferential rather than stated.

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

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

The phrase 'existing-contract submission' implies a precondition (a contract must already exist), and 'This does not sign or broadcast. Sign only on first-party wallet pages' clarifies the boundary of what this tool will and will not do. But there is no explicit when-to-use-this-vs-alternatives guidance relative to the sibling prepare/confirm tools, leaving routing largely 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 description adds useful behavior beyond annotations: it establishes a first-party authorization session and forbids collecting wallet or verifier signatures in ChatGPT. It also clarifies that prepared status is not completion. There is no contradiction with idempotentHint=true, and the read/destructive hints are consistent with a non-read, non-destructive prepare operation.

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 with no padding, and the use-condition is front-loaded. The action-value list is a bit run-on and ambiguous ('solve or claim'), but the overall length is appropriate for the safety-critical content.

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

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

Given nine parameters, a nested details object, and a sibling cluster, the description is incomplete: it omits parameter semantics, does not distinguish prepare_bounty_action from prepare_bounty_post, and contains a schema mismatch. Output schema and annotations reduce some burden, but correct invocation still requires undocumented 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?

Schema description coverage is only 11%, so the description had to carry parameter meaning, but it does not explain idempotency_key, bounty_id, actor_wallet, network, amount_base_units, opportunity_id, or bounty_contract. The only parameter-related content is the list of action values, which also includes unsupported 'claim.' Required fields other than action are left to the agent to infer.

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 conditional trigger (details gathered and explicit confirmation) and a specific outcome: create one idempotent first-party authorization session. It is not a tautology and clearly targets bounty actions. However, it does not distinguish itself from sibling prepare_bounty_post, and the action list includes 'claim' even though the schema enum omits it.

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

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

Provides explicit when-to-use preconditions: details gathered conversationally and explicit confirmation of the action. It also adds strong guardrails, such as never requesting wallet or verifier signatures in ChatGPT and never describing prepared status as completion. It does not name sibling alternatives or state when to choose prepare_bounty_post or get_bounty_action_status, so exclusions and alternatives are missing.

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

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

Even though annotations already mark the tool as non-read-only, idempotent, and destructive, the description adds valuable behavioral context: it is a preparation step, not a publishing/funding action; posting_operation_id should be reused when resuming; and creator review gives the creator settlement authority. It also explains the deterministic fallback visual and image-field coupling beyond what the annotations provide.

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

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

The description is long but front-loaded with the trigger condition and packed with mode-specific rules. Nearly every sentence earns its place, though a few constraints, such as creator-mode omissions and image fallback behavior, are partially repeated from the schema.

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

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

For a 19-parameter tool with nested objects, an output schema, and two review modes, the description covers the key scenarios and invariants: resuming, creator review, parent preservation, image fallback, and the non-publishing boundary. An agent has enough context to invoke it correctly without additional discovery.

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%, but the description adds essential cross-parameter semantics: supply benchmark with evidence_schema, supply image fields together or omit all three, preserve parent bindings, and in creator mode omit automated fields and set a timezone-offset delivery_deadline. These grouping and mode-dependent rules are critical for constructing a valid call.

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

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

The description clearly identifies the verb and resource: prepare a bounty for wallet review after complete terms and explicit approval, and it closes with 'This prepares a reviewable handoff.' It does not explicitly name or contrast sibling tools such as prepare_bounty_action, so it stops just short of full 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?

It gives an explicit precondition: use when the person's AI has gathered complete bounty terms and received explicit approval. It also clarifies what the tool does not do—publish, move funds, request a secret, or prove a bounty exists—but it does not explicitly route to an alternative sibling tool by 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 cover read-only/idempotent/non-destructive behavior, and the description adds meaningful policy context: it only produces a first-party handoff, must not collect sensitive data, and must not conflate a purchase with funding. No contradiction with annotations.

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

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

One dense sentence that front-loads the trigger condition and then states hard constraints. No filler or repetition of schema/annotation 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 3-parameter tool with an output schema and safety annotations, the description covers trigger, scope, authorization requirement, and misuse prevention. An agent has what it needs to use the tool correctly.

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

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

With 67% schema coverage and no explicit parameter explanations in the description, the required bounty_contract and amount_base_units rely on their names and the schema pattern/min-max. The description's Base USDC context supports amount_base_units, but it does not add detail about units or the contract's role.

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 action (prepare a first-party MoonPay handoff) and a specific trigger (person funding one canonical Base bounty needs Base USDC), which clearly separates it from sibling prepare_bounty_action/post tools. It also uses 'only' to delimit the tool's scope.

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

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

It gives an explicit when-to-use condition ('Use this when a person... needs Base USDC') and explicit prohibitions ('never request card data... never treat a MoonPay purchase as bounty funding... require a separate canonical funding authorization'). This tells an agent when and when not to invoke the tool.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the mutation profile is covered. The description adds genuinely new behavioral context: only the caller's own dispute is withdrawn, other participants' holds persist, cleanup resumes, and canonical outcomes are unaffected — precisely the effect scope an agent needs for a destructive call.

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

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

Three tight sentences, front-loaded with the action and effect. No filler, though the outcome caveat could be merged more economically.

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 effect scope is well explained for a destructive operation, but for a mutating tool with no output schema the description omits authorization requirements, what the response returns, and whether the withdrawal is reversible. Adequate but with clear gaps.

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

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

Schema description coverage is 0%, so the description must carry the load. It only gestures at 'reason' and never mentions 'id' or clarifies that id targets the dispute rather than the artifact. The schema supplies types/formats (uuid, 1-2000 chars) but neither source explains 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?

States a specific verb (withdraw) and resource (file-retention dispute) with a scope qualifier (your own). An agent can distinguish this action from open_artifact_dispute, though the description never names that sibling explicitly.

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

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

'your own' implies an ownership precondition and the reason requirement hints at prerequisites, but there is no explicit when-to-use guidance and no named alternative (e.g. open_artifact_dispute, or what to do instead if you are not the owner). 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 beyond the annotations with three real facts: queued runs are deduplicated against identical inputs (elaborating idempotentHint), a verified session is required, and solver-supplied test outcomes are rejected – an integrity guarantee an agent could not derive from structured fields. It does not describe what happens to the queued run afterward or its lifecycle, so it falls short of full disclosure.

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

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

Three short sentences, front-loaded with the core action and followed by the dedup behavior and the auth/integrity constraints. No filler, every sentence carries distinct information.

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

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

The auth requirement and dedup behavior are usefully covered, but for a tool with an undocumented nested plan object, 0% schema coverage and no output schema, the description should explain what plan contains and roughly what the returned run looks like. The gap around plan is the main shortfall.

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 plan parameter is an undescribed nested object. The phrase 'queue checks on exact durably stored files' hints that artifact_id points at a stored artifact, but nothing explains the shape or purpose of plan, so the description does not 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?

States a specific verb+resource: queue checks on durably stored files, and adds a distinguishing behavior (returns an existing run for identical inputs) that separates it from find_verification_checks and get_verification_run. It never explicitly says the checks are verification checks on a stored artifact, so the connection to artifact_id is left implicit.

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

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

States a prerequisite (verified website or wallet session) and a constraint (no solver-supplied test outcomes), which gives context for when the call will succeed. But it names no alternatives and does not say when to use this versus validate_verification_plan or find_verification_checks, leaving sibling selection 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 declare a non-read-only, idempotent, non-destructive, open-world write, and the description adds real context beyond that: authorization requirements, that wallet signing is deliberately NOT performed here, and that a legacy assessment hash must be preserved. Missing details on failure modes or what exactly gets persisted, keeping it below a 5.

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

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

Four short, front-loaded sentences with no filler; the action and the eligibility constraint lead. Slightly telegraphic ('Preserve the legacy assessment hash') but every sentence carries an 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 mutation tool with nested objects, no output schema and 0% schema coverage, the description covers authorization and the wallet-signing boundary but leaves the structure of assessment/attestation and the meaning of previous_report_id entirely undocumented. Adequate but with clear gaps that the schema cannot fill.

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 schema contains two nested objects (assessment, attestation) plus network and previous_report_id, none of which are explained. The description alludes to 'criteria', 'evidence' and 'assessment hash' but maps none of this to the four parameters, 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?

States a specific verb ('Save') and resource framing ('each criterion's explanation and evidence'), which tells an agent this persists review content tied to verification criteria. It does not explicitly name a sibling alternative, but 'verification review' vs the many prepare_/get_/list_ siblings is reasonably distinguishable.

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

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

Provides timing and access context ('before wallet signing', 'Authorized reviewer or accepted assigned agent only'), which is genuinely useful for deciding eligibility and ordering. It never names an alternative tool (e.g., get_verification_review or prepare_bounty_action) or states when not to call it, so usage remains 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.

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

Annotations already declare readOnly=false, idempotent=true, destructive=false, but the description adds what the annotations cannot: an exact byte-preservation guarantee, the 2 MiB remote-request ceiling (including base64 encoding overhead), the 100 MiB alternative path, and the mandatory idempotency key. These are exactly the constraints an agent must respect 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?

Four tight sentences with the core guarantee front-loaded and constraints following. The 'Base64 input.' fragment is terse but earns its place by flagging the encoding contract; nothing else is wasted.

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

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

For a write tool with annotations covering safety and no output schema, the description supplies the size limits, encoding requirement, and idempotency contract that structured fields omit. It stops short of indicating the natural next step (confirm_artifact_submission) or what a successful store returns, but nothing critical for invocation is missing.

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

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

Schema description coverage is 0%, so the description carries the parameter burden. It explains that input is base64 and that the idempotency key is required, which is real added meaning, but it never clarifies the 'path' field or the files-array semantics (up to 1024 entries, exact bytes per path). Baseline 3 given partial compensation for a 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+timing: 'Store authenticated exact file bytes before a submission transaction.' That cleanly separates it from read siblings (get_verification_artifact) and from prepare_artifact_submission/confirm_artifact_submission, which handle the submission lifecycle rather than byte storage.

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

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

Gives explicit preconditions ('before a submission transaction') and names the fallbacks for cases it cannot serve: larger files go through the API/CLI (100 MiB total) or exact GitHub commit import. An agent knows both when to pick this tool and when to route elsewhere.

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

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

Annotations already establish the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description is not the primary source of behavioral information. It adds the gating context that the creator must accept the meaning before funding, but says nothing about what a failed validation reports or how coverage/compatibility are judged.

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 core purpose front-loaded and no filler. Each sentence carries a distinct instruction (what it validates, where to get the schema, the funding precondition).

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 validation tool with a nested-object parameter at 0% coverage and no output schema, the definition should explain what a validation result contains (errors, coverage gaps, compatibility failures) and what constitutes a valid plan. It leaves both the input shape and the return behavior unspecified.

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 'plan' parameter is an untyped nested object with no property descriptions. The description only points to find_verification_checks for the schema rather than describing the plan's structure, so an agent still cannot construct the argument from this text.

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+resource ('Validate ... plan') and narrows it to two concrete aspects: 'complete criterion coverage' and 'checker compatibility'. It also implicitly distinguishes itself from find_verification_checks by casting that sibling as the schema source rather than the validator.

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 provides workflow context (get the plan schema from find_verification_checks; the creator must accept the meaning before funding), which implies when the step belongs in the flow. However, it never explicitly states when to call this versus alternatives or when a plan is ready to validate, so usage is only implied.

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