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

The description does disclose some behavioral traits beyond the annotations: it mentions that a 402 error occurs without a paid X-Agent-Pass, that 'No free looks' (a charge applies), and that risk levels are 'ok|new|warn|sink'. However, these disclosures are cryptic and not clearly tied to the tool's execution flow. Annotations already cover read-only and non-destructive, so the description adds partial context but in a confusing way.

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, run-on set of clauses mixing pricing, payment options, error codes, and risk levels. It lacks clear organization and front-loads a question rather than a declarative purpose. It is not concise or structured in a way that aids comprehension.

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 3 parameters and no output schema, the description is severely incomplete. It does not explain what the tool returns, what the risk levels mean, how the payment flow works, or what the user should expect. References to invoices and pay pages are unexplained, leaving an agent without enough information to invoke 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?

The schema describes only 'chain' (33% coverage), and the description does not clarify the purpose or format of 'address' or 'pass_token'. It references 'X-Agent-Pass' indirectly but does not explicitly connect it to the pass_token parameter. With low schema coverage, the description fails to compensate by explaining parameter semantics.

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 'Can I pay this address?' implying a payability check, but then dives into pricing, payment methods, and error codes without clearly stating that this tool scans an address to determine risk or payability. It does not name a specific verb+resource and offers no differentiation from siblings like meter_preflight or meter_scan_batch.

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 meter_scan versus its sibling tools. The description mentions payment preferences (e.g., 'Prefer Base USDC... to base_pay_to') but that is about payment rails, not tool selection. No conditions, exclusions, or alternatives are given.

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