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

Annotations declare readOnlyHint=false and destructiveHint=false, which is ambiguous (not read-only, not destructive). The description adds some behavioral hints: 'Never hold' suggests the tool doesn't persist state, and 'allow or stop vs cap_usd' suggests it returns a decision. However, it doesn't explain what happens on a 402, what 'X-Agent-Pass' is, or what the actual side effects are. The cryptic pricing and 'No free looks' statements are not clearly tied to the tool's behavior. No contradiction with annotations, but the description fails to provide meaningful behavioral transparency beyond vague hints.

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 extremely short but not concise in a useful way. It reads like a stream of disconnected fragments: 'Can I pay this address? Buy looks_20 pack ($0.20) or look $0.10. Stamp ticket $0.05. No inbox. One look = one address. No free looks.' These sentences don't form a coherent explanation. The most important information ('allow or stop vs cap_usd') is buried at the end. There is no front-loading of the tool's core purpose. This is under-specification disguised as brevity.

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

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

This is a tool with 6 parameters, no output schema, and no useful annotations. The description fails to explain the tool's core function, the meaning of the pricing references, the role of pass_token, or what the output looks like. An agent would not be able to reliably invoke this tool correctly. The cryptic references to 'looks_20 pack', 'Stamp ticket', and 'X-Agent-Pass' are unexplained domain jargon. Compared to the sibling tools, this lacks the clarity needed for correct selection and invocation.

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

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

Schema description coverage is 0%, so the description must compensate for the bare parameter names. It does mention 'Body: chain, wallet, to, value_usd, cap_usd' and 'allow or stop vs cap_usd', which gives some meaning to cap_usd and value_usd. However, it doesn't explain what 'chain' values are valid, what format 'wallet' should be, what 'to' represents, or what 'pass_token' is for. The cryptic pricing statements don't clarify parameter semantics. With 6 parameters and 0% schema coverage, this is insufficient.

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 is a jumble of pricing fragments ('Buy looks_20 pack ($0.20) or look $0.10. Stamp ticket $0.05.') and cryptic rules ('One look = one address. No free looks.') without a clear statement that this tool performs a preflight check against a cap. The title says 'Preflight against a self cap', but the description never explicitly says 'checks whether a payment is allowed' or 'returns allow/stop'. It mentions 'allow or stop vs cap_usd' at the end, which hints at the purpose, but the overall message is confused and fails to clearly distinguish this from sibling tools like meter_scan or check_transfer.

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 guidance on when to use this tool versus alternatives. The description mentions 'No inbox' and 'Without a paid X-Agent-Pass, 402 looks_20 pack $0.20' which seems to describe error conditions, but it doesn't say 'Use this before sending a payment' or 'Use meter_buy_pass if you need a pass'. The sibling list includes meter_buy_pass, meter_pricing, and check_transfer, but the description never references them or provides selection criteria.

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