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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, open-world), and the description still adds substantive context beyond them: single vantage point, not a judgement of service quality; empty-sample handling with samples 0; the 404/not-charged behavior; typical sub-1s latency; USD 0.05 price with no free tier; and an untrusted-data warning for returned page and on-chain strings.

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 usage condition and returned metrics are front-loaded and the pricing/docs/safety notes are compact. A few clauses are terse to the point of being cryptic ('A target with no samples is returned with samples 0; none has any: 404 (not charged)'), costing a little clarity.

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?

An output schema exists, and the description nonetheless summarizes the returned fields, plus cost, latency, and the empty-sample edge case. The only residual ambiguity is the compressed no-samples/404 sentence, which an agent could misread when interpreting an empty result.

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 100%, so the single 'targets' parameter with its 1-25 bounds and URL-or-host format is already documented. The description restates the 'up to 25 endpoints or hosts' limit but adds no format, normalization, or validation semantics beyond the schema, so the baseline of 3 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?

States a specific verb and resource ('compare the 30-day uptime and valid-402 share of up to 25 x402 endpoints or MCP servers at once') and the payload returned. It distinguishes itself from the singular sibling only implicitly via 'up to 25 ... at once' rather than naming get_endpoint_uptime/get_endpoint_history, so an agent must infer the bulk-vs-single split.

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?

Gives a clear triggering condition ('Use when an agent must compare ... up to 25 ... at once') that separates it from per-endpoint scanning. It does not name the singular alternative (get_endpoint_uptime) or state an explicit exclusion, so the routing is clear but not fully specified.

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