Find who to contact

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the Pro-plan requirement and the fact that SAM registration agents are filtered out of decision-maker results.

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 terse opener is immediately followed by a clean two-bullet breakdown of modes, so the key routing information is front-loaded and easy to scan. The resolve(company) parenthetical is slightly cryptic but earns its place as a hint.

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?

An output schema exists so return values needn't be described, and the description maps most of the six parameters plus the Pro-plan prerequisite. It doesn't state what happens if kind and supplied params disagree, a minor 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?

With 0% schema coverage, the description must carry parameter meaning, and it does: uei maps to company_decision_maker, name/email to contracting_officer, and state/agency narrow the search. It leaves format details (e.g., state abbreviation) unstated, but otherwise compensates well for the coverage gap.

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 bullet list names the two specific things the tool returns – a company's decision-maker and a contracting officer's details – which is more than the vague 'Who to talk to' opener. It clearly separates the two modes but does not differentiate itself from siblings like resolve or search beyond the resolve(company) reference.

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 a prerequisite ('Both need the Pro plan') and gives per-kind input guidance: UEI for company_decision_maker (with resolve(company) to obtain one) and name/email for contracting_officer, with agency/state as narrowing filters. No explicit when-not or alternative sibling is named, so it stops short of a 5.

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