Search Entities

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

Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds valuable behavioral details beyond annotations: q requires min 2 chars, unrecognized business_type returns 400 with the valid list, limit max is 100, and each result returns a uei usable by other listed tools.

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 most important scoping and sibling-differentiation guidance appears in the first sentence. The bullet list packs a lot of parameter detail with no fluff, and every line earns its place. The cross-tool uei note at the end is useful and compact.

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 an output schema present, the description doesn't need to enumerate return fields, but it still adds the critical cross-tool uei linkage. It covers scope, plan limits, error behavior, and parameter constraints. The only minor omission is offset, but that's not essential given the schema and pagination context.

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 carries full responsibility for parameter meaning. It covers 7 of 8 parameters with concrete semantics: q substring min length, NAICS suffix rules, business_type examples plus error behavior, active_only meaning, naics_small exact format, and limit maximum. Only offset is left to the schema, which is self-explanatory.

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?

Description states it searches ALL SAM-registered entities by name, explicitly including those without award history. It also differentiates from sibling search_companies by noting that search_companies is for companies that won awards and has richer award-history fields.

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?

Explicitly tells the agent when to use this tool vs search_companies, and when to prefer search_companies instead. It also documents plan limitations (q works on every plan, other filters are Pro), giving operational context for when filters may fail.

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