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

With no annotations, the description carries the full burden and mostly succeeds: it discloses the exact checks performed and the return shape (findings with severities, a 0-100 score, a fix list) plus latency measurement. It omits whether the tool requires credentials, whether it has side effects on the target, rate limits, or cost — and the trailing truncation ('what breaks a ') cuts off information.

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?

Purpose is front-loaded and the enumeration of checks is useful content, but the definition is a single dense run-on sentence that ends truncated mid-clause. The unclosed 'Use when you sell an x402 endpoint and want to know what breaks a ' is dead weight the agent cannot parse.

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?

No output schema exists, and the description does compensate by naming the return shape (severities, 0-100 score, fix list), which is the most valuable addition here. Against that, it never states the invocation contract correctly given the empty schema, provides no sibling disambiguation among 19 akari_* tools, and is cut off before finishing its usage guidance, leaving real gaps for a network-calling audit tool.

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 description instructs the caller to 'pass ?url=https://your.host', implying a required url parameter, but the input schema declares zero properties with additionalProperties: false — so a url argument would be rejected. This direct mismatch between the described input and the actual schema is worse than saying nothing. The 0-param baseline of 4 does not apply because the description actively misdirects.

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: audit an x402 paid endpoint and return a per-route report. The enumerated checks (402 status, payment header decode, positive amount, CAIP-2 network, payTo, human-readable price, MCP surface, latency) make the scope concrete. It does not differentiate itself from the many akari_* siblings (e.g. akari_audit_plus, akari_deep), so an agent has no textual basis for choosing between audits.

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?

Offers a trigger condition ('Use when you sell an x402 endpoint and want to know what breaks a ...'), which implies usage but stops mid-sentence, so the condition is incomplete. No exclusions, no named alternatives, and nothing to distinguish it from akari_audit_plus or akari_deep.

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