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

With no annotations, the description carries the full burden and largely succeeds: it discloses that the MCP signs the authorization and pays a separate deploy fee, that the budget is frozen on an escrow, that the operation is idempotent once frozen, and that unsupported configs return 409. Minor gap: it does not describe the response shape or what happens if the task is already frozen (beyond 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?

The description is dense but every clause earns its place: it front-loads the core action and then packs in rail restrictions, fee percentages, execution modes, error conditions, and idempotency in three sentences. There is no filler or redundancy.

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

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

Given the tool's complexity and no output schema, the description covers the flow position, both invocation modes, fee details, a specific error case, and idempotency. It is missing a description of what the function returns and any state prerequisites beyond being the second step, but it is still remarkably complete for a tool of this depth.

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 description adds essential relational semantics not present in the schema: it specifies that auth_intent and deploy_fee must be passed together for MCP auto-signing, and that signed_payment with fee_tx_hash is the alternative. This transforms the schema's flat property list into actionable call patterns, going far beyond the 80% schema coverage.

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

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

The description opens with a specific verb+resource ('Freeze the bounty budget on-chain') and explicitly identifies the tool as the second step of the FCFS flow. This clearly differentiates it from siblings like post_task (creation) and review_submission (reviewing), making its purpose unambiguous.

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

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

The description provides explicit flow context: it is the second step after post_task and before review_submission. It also states the only supported rail (non-custodial POOL escrow) and the 409 error condition for unsupported configs, giving clear when-to-use and when-not-to-use guidance.

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

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

With no annotations provided, the description carries full responsibility and excels: it discloses the refund calculation (unfilled units × per-unit reward), non-refundable deploy fee, idempotency on already-closed tasks, operator dependence, and fallback behavior. This goes far beyond basic side-effect disclosure.

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

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

The description is compact (about 70 words) and front-loaded with the primary action, followed by critical details. Every sentence adds value—refund math, fee policy, idempotency, and operator fallback—without fluff. The parenthetical is effective for the alternative tool reference.

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

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

For a tool with no annotations and no output schema, the description is remarkably complete. It covers what, who, when, and what happens next, including edge cases (idempotency, operator downtime). No critical gaps are apparent for a single-parameter mutation 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 schema has only 'task_id' with no description (0% coverage). The description compensates by clarifying that the tool operates on an FCFS pool bounty, making it clear that task_id is the unique identifier of that bounty. While not explicitly mapping the parameter, the context strongly implies its role, adding some meaning beyond the schema.

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

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

The description clearly states the verb ('Close'), the resource ('your FCFS pool bounty'), and the scope ('poster-only'), along with the key effects (refund unfilled budget, stop submissions). It also distinguishes itself from sibling tools by directly naming 'reclaim' as an alternative, making the purpose unmistakable.

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 'poster-only', indicating who should use it, and provides an alternative path: 'if the operator is ever down, use `reclaim`'. It also implies the timing ('after the authorization deadline') for the fallback, giving clear decision-making context.

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

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

With no annotations, the description discloses behavioral traits such as the polling behavior, the significance of the 'pending' status, and the visibility scope ('as poster'). It does not detail error handling or side effects, but 'get' implies read-only, and the workflow context adds value beyond a bare 'get'.

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 primary purpose and followed by actionable usage context. Every word earns its place with no redundancy.

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

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

There is no output schema, but the description explains the return contents at a high level and provides the essential workflow context. It lacks edge-case details like error behavior, but the agent can correctly invoke and use the tool based on the description 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?

The schema has one parameter (task_id) with no description coverage. The description implicitly references the task_id in the workflow ('after authorize_task') but does not explicitly define the parameter beyond its name. Since the parameter is self-explanatory and the workflow context adds meaning, this is adequate but not enhanced.

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

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

The description clearly states the tool's purpose: 'Get the live state of a task' including the task row, submissions, and per-unit claims. It specifies the agent's visibility and distinguishes it from siblings by tying it to the authorize_task and review_submission workflow.

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

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

Explicit guidance is given: 'Poll this after authorize_task until a submission with status pending appears' and then proceed to review_submission. This provides precise when-to-use context and names the follow-up tool, making the alternative clear.

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

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

With no annotations, the description carries the burden. It discloses that the operation is static and makes no network calls, reducing risk perception. It also specifies the content returned (categories), which is valuable behavioral context.

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

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

The description is two sentences, front-loading the main purpose and adding usage guidance. No redundant information; every sentence serves a purpose.

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 zero parameters and no output schema, the description provides all necessary context: what it lists, examples, and when to use it. Completely sufficient for an agent to invoke correctly.

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

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

The tool has zero parameters, so the schema is empty. The description adds meaning by explaining what the output contains, which is more than the schema provides. Baseline for zero parameters is 4, and the description meets this baseline.

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

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

The description clearly states the tool lists kinds of quests humans can complete, with specific examples. It distinguishes itself from sibling tools by focusing on the valid category values rather than task operations.

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

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

Explicitly says to use it to learn valid category values before posting a quest, giving a clear usage context. Does not mention alternatives, but the purpose is distinct enough that no exclusion is necessary.

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

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

With no annotations, the description fully discloses side effects: generates a wallet, writes config with 0600 permissions, mints a key shown once, and notes idempotency behavior. It also explains the non-custodial budget freezing, providing deep behavioral context.

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

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

The description is long but every sentence adds unique value: purpose, process, security, return values, alternatives, idempotency. It is front-loaded with the key 'BOOTSTRAP' identifier and structured logically.

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

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

Despite no output schema, the description explicitly states what is returned (wallet address, key, next steps). It covers prerequisites, workflow, security, and idempotency, making it fully self-contained for a complex setup 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 tool has zero parameters, so the schema already provides complete coverage. The description mentions CLI flags (--import/--create) but these are external, not for this tool, so baseline 4 applies.

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

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

The description opens with 'BOOTSTRAP' and explicitly states it works without an existing key, being the one tool that self-onboards. It details the full onboarding sequence (wallet generation, SIWE, key minting, config save) and clearly differentiates from sibling task-oriented tools.

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

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

It explicitly specifies when to use (when no existing key) and provides next steps (post_task → ...), making the intended workflow clear. It also names the CLI alternative for users wanting to import their own wallet, satisfying the when/when-not guidance.

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

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

No annotations are provided, so the description carries the full burden. It discloses that funds are NOT charged at post, that budget is frozen later at authorize_task, that deployFee is a separate non-refundable fee tx, that settlement is limited to a non-custodial POOL escrow, and the specific 422 settlement_unavailable error for non-real tokens.

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 dense single paragraph with front-loaded purpose, structured qualifiers, and backticked param names. Every sentence contributes essential information—funding model, timing of charges, return payload, fee structure, and settlement constraints—without fluff.

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

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

Despite having no output schema, the description fully covers return values (task id, authIntent, deployFee), the required next step (authorize_task), fee details, and error conditions. It also explains the FCFS bounty model and settlement rails, making it complete for a complex 12-parameter 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?

Description adds significant meaning beyond schema for key params: reward_usd is the total budget while quantity is the number of identical units, each unit holding reward_usd/quantity with a per-unit minimum of $0.01. It also explains pay_token settlement options (USDC/BNKR/GITLAWB) and invalid tokens. Schema coverage is 75%, so remaining params are already documented, but these enrichments are valuable.

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: 'Fund a quest on the engagement marketplace (an FCFS pool bounty).' It clearly differentiates from siblings by noting 'NO direct hire and NO agent-picks-human — every quest is an open bounty,' and clarifies the action is creating a task that returns an id.

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 context: 'you freeze a budget, ANY eligible verified-X human submits first-come-first-served.' It excludes direct hire/agent-picks flows and explicitly directs the follow-up step: 'pass BOTH to authorize_task.' It also warns about invalid token/config returning 422, which is a clear usage constraint.

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

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

With no annotations provided, the description fully discloses the on-chain behavior: the wallet calls AuthCaptureEscrow's payer-only reclaim(paymentInfo) directly, signs and sends on Base, and waits for receipt. It also mentions what could go wrong (too early, already settled, not payer) and the return shape, giving complete behavioral transparency.

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?

Although lengthy, the description is packed with necessary operational details and is front-loaded with the core promise. Every sentence adds critical context (how it works, requirements, error cases, return value), so it earns its length without redundancy.

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

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

For a complex on-chain recovery tool with no output schema, the description covers all essential aspects: mechanism, prerequisites, error conditions, network (Base), and the return structure. It is complete enough for an agent to both select and safely invoke the 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 schema only defines task_id with no description, and schema coverage is 0%. The tool description compensates by explaining that it reads escrow_payment_info from GET /api/tasks/[id], making it clear that task_id identifies the task whose escrow info is needed. It does not explicitly state 'task_id is the task's UUID', but the context strongly implies it, which is sufficient for a single parameter.

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

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

The description uses a specific verb ('reclaim') with a clear resource (unfilled budget from audited escrow) and distinguishes itself from close_task by framing it as a backstop requiring no operator. The purpose is unmistakable and well 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?

It explicitly states when to use this tool (only after authorization deadline, operator down, as backstop) and contrasts it with close_task as the normal path. It also lists hard requirements (must be payer, expiry passed) and error conditions, providing excellent usage guidance.

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

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

With no annotations, the description carries the full burden. It discloses the key state-changing effects: approve:true captures one unit and consumes a slot; approve:false reopens the slot, preventing spot-blocking. It does not mention idempotency or error handling, but covers the critical consequences.

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 that front-loads the purpose and packs in workflow and behavioral detail. No wasted words, though a bit long; the structure could be slightly improved with line breaks but remains effective.

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 absence of an output schema, it provides very useful workflow context (how to handle pending submissions, when to close). It doesn't explain return values or failure scenarios, which would round it out, but it is largely complete for a settlement action.

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

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

Schema covers 100% of parameters with descriptions. The description reinforces approve semantics and submission_id source, but adds no new parameter details beyond schema, so baseline 3 is appropriate.

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

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

The description clearly states this is 'THE settle tool' for approving/rejecting a submission, with a specific verb and resource. It distinguishes itself from siblings by explaining it is the payment mechanism and referencing get_task/close_task for workflow.

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

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

Explicitly says poster-only, describes when to use (poll get_task, review each submission) and when to use alternatives (call close_task when budget consumed). It also states 'there is no direct hire' to prevent misuse.

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