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

With no annotations to rely on, the description carries the full behavioral burden and discloses the most important traits: per-request pricing in USDC, the payment recipient, the 402 failure mode when unpaid, and the fact that the same URL returns JSON after a valid X-PAYMENT. It also explains chunk semantics (newest, older, since-watermark). It omits details like rate limits or JSON structure, but the core payment-gated behavior is well 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?

The description is dense and contains almost no filler; the endpoint and price are front-loaded, followed by the access modes and payment behavior. The sentence order is somewhat stream-of-consciousness, mixing mode descriptions with payment notes, but every sentence contributes meaningful information.

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 paid x402-style tool with five parameters, no annotations, and no output schema, the description covers the essential operational contract: how to request the newest chunk, an older chunk, a specific official text, or a since-watermark set, and what to expect before and after payment. It doesn't describe the JSON response shape or detailed error bodies, but an agent has enough context 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 input schema already documents all five parameters at 100% coverage, so the description does not need to repeat definitions. It adds value beyond the schema by attaching costs to specific parameters (?id= is $0.02 versus $0.05 for chunk calls) and clarifying the payment flow for x_payment. This extra semantic layer helps an agent understand which parameters affect billing and behavior.

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 identifies the resource (FMSHRC decision/order text) and the operation through the GET URL and phrases like 'Newest chunk on a plain GET' and 'returns JSON'. It is clear that this tool serves FMSHRC orders specifically, and the FMSHRC path helps separate it from sibling agency tools. It lacks a single crisp verb phrase like 'Retrieve FMSHRC orders,' but the intent is unambiguous.

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 explicitly maps each invocation mode to its use: plain GET for the newest chunk, ?id= for one official text, ?before= for older chunks, and ?since= for texts newer than a watermark. It also states that unpaid requests return HTTP 402, which is important operational guidance. It does not name sibling tools as alternatives, but the mode-by-mode guidance is clear enough for correct selection within this tool.

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