Fetch

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

With readOnlyHint=true already covering non-mutation, the description adds meaningful behavior: it discloses the billing implication ('charged as a section lookup plus a body read') and the acceptance of citation URLs, bare paths, or Bluebook citations. This goes beyond the annotations without contradicting them.

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 sentences, each earning its place: primary function with return shape, alternative accepted inputs, and usage/billing context. The most essential action is front-loaded, and there is no redundant filler.

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?

The tool has a single parameter, an output schema, and a readOnly annotation. The description covers the input sources, return type, preferred alternative, and billing impact, leaving no significant operational gap for an agent selecting or invoking the 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 schema provides no description for the single 'id' parameter (0% coverage), so the description compensates by explaining that the id comes from a search result and may also be a citation URL, bare path, or Bluebook citation. This gives an agent usable meaning for the parameter.

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 a precise verb and resource: 'Fetch the full text of one US law section by the id from a search result.' It also specifies the return shape and lists alternative accepted inputs, making the tool's purpose unmistakable and distinct from siblings like get_us_statute_section_text.

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 gives clear usage context: it is intended for clients requiring the standard search/fetch pair, and it explicitly prefers get_us_statute_section_text when available. It does not enumerate exclusion conditions for other sibling tools, but it names the main alternative and the rationale for using this tool.

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