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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description correctly focuses on what the annotations cannot convey. It discloses that results automatically include Federal-to-SLED cross-walks in `crosswalk_intelligence` and SBA size standards, and instructs the agent to cite `canonical_url` when presenting results — valuable behavioral detail. It does not describe result volume or ranking for keyword searches, a minor gap given the safety profile is 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?

Three tightly written sentences, front-loaded with the scope and code counts before the usage modes and output notes. The embedded code examples partially duplicate the schema's examples, which is the only wasted space.

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?

There is no output schema, so naming the key return fields (crosswalk_intelligence, SBA size standards, canonical_url) is exactly the missing context the description must supply, and it does. All parameters are optional, yet the description never states what happens when neither code nor keyword is given, which is the main remaining gap.

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 coverage is 100%, with each parameter already carrying its own description and examples, including the code_system enum. The description largely restates those formats rather than adding new constraint semantics; baseline 3 is appropriate.

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 names a specific verb and resource set: lookup and cross-walk NAICS, PSC, and NIGP codes, with code counts for each system. It clearly distinguishes this reference-lookup tool from siblings like define_govcon_term and search_govcon_resources.

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?

It states the two usage modes — exact code lookup with concrete format examples ("541512", "D310", "920-45") and plain-English keyword search with examples ("software", "janitorial", "paving") — giving the agent clear input routing. It does not say what happens if both code and keyword are supplied, nor when to prefer this tool over define_govcon_term.

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