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

With no annotations provided, the description fully carries the behavioral disclosure burden. It transparently explains the payment requirement (USDC on Base), the HTTP 402 on unpaid requests, the response property (JSON after valid X-PAYMENT), and the pricing model for different modes. It also notes 'Not a new SKU' to prevent duplicate purchasing. This is substantial and exceeds what a typical description provides.

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 sentence containing all necessary information, but it is not well-structured. It front-loads the URL and price, then mixes mode explanations with pricing and payment behavior. While efficient, it could benefit from clearer breaks (e.g., bullet points or separate sentences) to improve scannability. Still, every sentence earns its place.

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?

Given the tool's complexity (paid x402 protocol, multiple access modes), the description covers the critical details: pricing per mode, the payment header, the 402 fallback, and the JSON response after payment. It does not describe the exact structure of the JSON output, but there is no output schema and this may be standardized across enforcement tools. It also omits rate limits or pagination limits, but these may not be critical for a paid endpoint. Overall, it is sufficiently complete for an agent to call 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 descriptions are already quite detailed (100% coverage), but the description adds significant semantic context: it explains that 'id' retrieves a single official text at a lower price, 'before' fetches an older chunk, and 'x_payment' is forwarded as the payment header. It also clarifies pricing implications for each parameter, which is valuable beyond the schema.

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 explicitly states a specific verb (GET) and resource (ORR Railways Act s.55 enforcement-notice text), specifies the endpoint URL, and clarifies it is not a new SKU, which hints at its relationship to similar enforcement tools. This is more specific than typical sibling tools and leaves no doubt about what it does.

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 description clearly implies the tool is for retrieving ORR enforcement notices, and the 'Not a new SKU' note suggests it overlaps with an existing endpoint. However, it does not explicitly contrast with sibling tools like ofgem-enforcement or ofwat-enforcement, nor does it state when to choose this over alternatives. The usage context is implied but not fully explicit.

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