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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so safety is covered. The description adds genuine provenance context the annotations cannot: candidate matches are not verified law-to-award mappings or fraud determinations, and no private reviews or AI-generated content are included. It does not mention pagination or volume limits.

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 short sentences with no redundancy, purpose front-loaded and the disclaimers trailing it. Efficient, though the disclaimers occupy space that could have held parameter guidance.

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?

With no output schema, the description should say more about what comes back; it lists entity categories but not shape or structure. The unglossed program enum is a real gap for a three-parameter detail-read tool, though the read-only profile is adequately covered by annotations.

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 description coverage is 0%, so the description must carry parameter meaning, yet it only vaguely gestures at 'law and jurisdiction'. The program parameter (overview/bridges/schoolbus/middlemile) is never explained, nor is the required lawId format, even though both are the main sources of caller error.

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?

States a specific verb (read) and a specific set of resources (public source candidates, stages, requirements, coverage) scoped to a law and jurisdiction. It is clearly a detail-read rather than a search, which implicitly separates it from search_public_laws, but no sibling is named explicitly.

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?

Usage is only implied: the required lawId plus 'existing' signals a lookup for a known law, versus discovery via search_public_laws or scope inspection via read_research_scope. The exclusions given ('No private reviews or AI generation') describe data boundaries rather than when to pick this tool over an alternative.

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