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

With no annotations, the description carries the full burden and does meaningful work: it discloses pay-per-call pricing ($0.001 USDC on Base), the payment protocol (x402/MPP) and the concrete failure mode (a 402 challenge on unpaid calls). It also states the return format (plain text), though 'first section' is left unexplained and no rate limits or other error modes are covered.

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?

Three tight sentences with no repetition: what it does and its identifier format first, then the return shape, then cost/auth constraints. Every sentence adds information an agent needs before calling.

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 single-parameter, no-output-schema tool, this covers the essentials: input format, return type, and the non-obvious payment precondition that would otherwise cause silent failures. Only the ambiguous 'first section' phrase leaves a minor gap.

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 nominally 100%, but the schema's own text for `path` is merely 'required', so the description's illustrative format 'uksc/2024/1' is the actual source of meaning about what the value looks like. It stops short of stating where paths come from or what a malformed path does.

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?

Names a specific verb (fetch) and a precisely scoped resource (text of a UK court judgment) keyed to a Find Case Law path, with a concrete example ('uksc/2024/1'). This distinguishes it cleanly from siblings like caselaw_search (discovery), caselaw_us (different jurisdiction) and legislation_search (different source type).

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?

The example path implies the caller must first resolve an identifier, and the UK framing implies when this is the right caselaw tool, but it never explicitly says to use caselaw_search to obtain a path or states when to prefer caselaw_us. Usage is inferable rather than stated.

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