Verifi

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

Discloses polling behavior and retry logic ('Honor retry_after_seconds'), but without annotations, the description carries full burden. Lacks details on side effects, error states, or what 'ready' and 'failed' mean.

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

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

Extremely concise: two sentences with no redundancy. Front-loaded with purpose, then behavioral note.

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

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

Given no output schema and no annotations, description omits expected return values, error handling, and completion semantics. Incomplete for a tool with minimal structured data.

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%. Description does not explain the sole parameter 'verify_id'. Parameter name is somewhat self-descriptive, but no additional context is provided.

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?

Description clearly indicates a polling action ('Poll until ready or failed') on a verification resource. It distinguishes from siblings like unlock_verify and verify_claim by implying a status-checking role, but could be more explicit.

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

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

No guidance on when to use this tool versus siblings. Does not mention prerequisites or alternative scenarios.

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 the full transparency burden. It explicitly discloses the cost (2.90 USDC), the x402 payment flow (omit first, retry automatically, or manual signature), and a key security warning. It does not mention potential side effects on the chain state beyond 'passing' the gate, but the critical behavioral aspects are covered.

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

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

The description is four sentences, each earning its place. It front-loads the purpose, then provides necessary payment and security details without redundancy. It is appropriately concise for the complexity involved.

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 and annotations, the description provides a solid overall picture: purpose, cost, payment flow, and a security note. It mentions 'return the human result' but lacks detail on the output format or failure modes. For a paid gate tool, the essentials are covered, but some specifics are 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 compensate. It does a thorough job for payment_signature, explaining the omit-first behavior and x402 signature handling, and explicitly warns against passing a private key. However, verify_id is only implied ('a ready chain') and not directly explained in terms of format, source, or required value, leaving a 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 uses a specific verb ('Pass gate 2') and identifies the resource ('a ready chain'), making the core action clear. It does not explicitly distinguish itself from sibling tools like get_verify or verify_claim, but the gate-passing action is conceptually different enough to avoid ambiguity.

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

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

The description provides clear context on how to use the tool ('Pass gate 2 for a ready chain', payment handling steps) and even includes a security note ('Never pass a private key'). However, it does not mention when NOT to use this tool or suggest alternatives, which keeps it from a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention that the tool is read-only or non-destructive, nor does it explain any side effects or constraints.

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

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

The description is a single sentence with no unnecessary words. However, it is very brief and could be expanded slightly without losing conciseness.

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 has no parameters and no output schema, the description provides the basic purpose. However, it lacks usage guidance and behavioral details, leaving some context 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 input schema has no parameters, achieving 100% schema coverage. The description adds meaning by stating the output will include service description, pricing, and rules, which goes beyond the empty schema.

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

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

The description clearly states the tool provides 'Service description, pricing, and rules', which distinguishes it from sibling tools that perform actions like get, unlock, or claim. However, it is somewhat generic and could be more specific about which service.

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

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

No guidance is provided on when to use this tool versus alternatives. The description only states what it does, without any context for preferred use cases or exclusions.

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

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

With no annotations, the description fully carries behavioral transparency. It discloses the asynchronous nature (returns 'processing' with verify_id), the callback/polling mechanism, the x402 payment requirement, the need to retain verify_id for recovery, and the single-active-verification constraint. These are key behavioral traits beyond a mere 'create' action.

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

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

The description is front-loaded with a clear one-line purpose, followed by compact parameter definitions and workflow steps. It is dense but every sentence earns its place, covering all necessary aspects without redundancy. The line breaks improve readability.

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

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

For a complex async, payment-backed tool with no output schema, the description covers the full lifecycle: initiation, return value (verify_id, status), callback/polling options, recovery, and a post-verification action (unlock_verify). It also specifies a concurrency limit, making it complete for an agent to select and use correctly.

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

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

Schema coverage is 0%, so the description fully compensates. It explains each parameter's meaning and constraints: intent (max 2000 chars), claim (max 4000 chars), agent_id (wallet address format), callback_url (HTTPS endpoint for verify.ready/failed), and payment_signature (optional manual input, standard auto-sent). This adds substantial value beyond the bare schema.

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

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

The description opens with 'Ask a real human to verify a claim,' which clearly states the tool's purpose as initiating human verification. It distinguishes this creation action from sibling tools like get_verify (polling) and unlock_verify (post-verification) by describing the return of a verify_id and the subsequent 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?

The description provides explicit workflow guidance: 'Prefer callback_url, or poll get_verify at the returned interval until status is "ready" or "failed". If ready, call unlock_verify.' It also explains the constraint 'Only one active verify per agent_id at a time' and mentions the alternative to callback_url, making usage context clear.

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