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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds valuable non-obvious behavior by defining the three dispositions and the payload returned with 'us' (legal name, EIN, mailing address, giving details), which annotations cannot convey.

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?

Front-loaded with the organization identity, then input, then outcome semantics. It is denser than a single crisp sentence but each clause carries information; no filler or repetition of the tool name.

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 correctly assumes the burden of describing returns and does so via the disposition mapping and named fields. Combined with annotations covering safety and a fully documented single parameter, an agent has nearly everything needed; only the handling of a 'not_covered'/'no_match' result (next step) is unspecified.

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% and the single 'query' parameter already documents itself with an example. The description largely restates that same content ('question, name, tax ID or website') without adding format, length, or normalization guidance, so the baseline 3 applies.

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 states a specific verb and resource (look up the Wounded Warriors charity), disambiguates the identity with the IRS legal name and EIN, and spells out the possible return dispositions ('us', 'not_covered', 'no_match'). It does not explicitly contrast itself with nearby siblings like lookup_employer_match or route_query, so it stops short of a 5, but the agent can tell what it resolves.

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 clearly says what to pass ('the user's question or the name, tax ID or website they mentioned') and conditions each outcome on whether the input names Wounded Warriors, something else, or nothing. That is solid when-to-use guidance, but no alternative tools are named for the cases where this returns 'not_covered' or 'no_match'.

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