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

Annotations only provide readOnlyHint and openWorldHint, leaving behavioral details to the description. The description discloses that the list endpoint omits body text and attachment info, that comment_id retrieves full detail, and that attachment-only comments include a stub with attachmentOnly=true plus download URLs. It also mentions the API key requirement. These are material behaviors beyond the annotations, adding real transparency.

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 two sentences with a moderate length, front-loading the core purpose before diving into targeting options and behavioral caveats. It is efficient and free of fluff, though it could tighten the listing of parameters, but the structure is clear and each 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 complexity (six parameters, four targeting modes, list vs detail behavior), the description covers the main decision points: how to choose a target, the difference between list and comment detail, attachment handling, API key requirement, and pagination hints (though pagination is in schema). The output schema exists (indicated by has_output_schema: true) so return formatting is covered elsewhere; the description fills all gaps not in structured fields.

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 provides 100% coverage with detailed descriptions for each parameter (including mutual exclusivity and examples). The description adds extra context like 'broadest scope' for docket_id, 'convenience' for fr_document_number, and the general rule of exactly one targeting parameter. This enriches the semantics beyond the schema without repeating it verbatim, justifying a score above the baseline of 3.

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 opens with 'Fetch public comments on a Federal Register document or a Regulations.gov docket', clearly stating the verb (Fetch), resource type (comments), and the two scopes (FR document or docket). It also notes the unique corpus, and the differentiation from siblings like regulations_get_docket/regulations_get_document is implicit in the focus on comments. This leaves no ambiguity about what the tool 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 explicitly instructs to 'Provide exactly one targeting parameter' and enumerates each option with its context (broadest for docket, per-document for object ID, convenience for FR number, detail for comment_id). It adds exclusion guidance: 'supplying two is rejected, not resolved by precedence' and warns that the list endpoint returns no body, steering users to comment_id for full content. This fully covers when to use which variant and the prerequisite of the API key.

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