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

Annotations indicate readOnlyHint=false and idempotentHint=false, and the description adds key behavior: it handles HTTP POST, requires an x402-enabled MCP client for the payment challenge, and returns an asynchronous acceptance. It also explains the payment challenge (dynamic price, max_spend_cents limits budget) and the retry behavior with idempotent payload preservation, which is beyond the annotations.

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

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

The description is dense but well-structured, front-loading the core purpose and usage. It covers multiple important behaviors in a single paragraph without redundancy. A minor deduction for length, but every sentence adds value.

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 (payment challenge, async flow), the description covers the essential workflow: purchasing, handling the challenge, saving the status_url, and calling the result tool. It also warns about idempotency and not re-purchasing, which is crucial. However, it does not describe the output schema (since none exists) or all parameter details, but it covers the critical operational steps.

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

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

Schema description coverage is only 33%, but the description highlights the three required parameters (objective, candidate, criterion) and mentions that candidates are treated as data. It also explains max_spend_cents (budget limit) and target_reliability (empirical target, not guarantee) implicitly. However, it does not fully compensate for the missing coverage of all 9 parameters, so a 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 the verb (purchase), resource (independent human review), and the target (candidate against criteria). It distinguishes it from siblings like me_human_verify_result by explicitly noting it returns an asynchronous acceptance and directs saving the status_url for the result tool.

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 lists when to use (REVIEW/HOLD, conflicting evidence, uncertain outputs), when not to use (non-sensitive only, not professional advice), and implies the alternative me_human_verify_result for checking results. It also warns against purchasing again for progress checks, preventing misuse.

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