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

Annotations already declare readOnly, idempotent, closed-world, non-destructive, so the safety profile is covered. The description adds value beyond that by disclosing directory size (8,000+), matching mode (by name), and the shape of each match including the slug handoff. Only pagination/limit behavior and no-match semantics are left out.

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?

Two sentences, zero filler: scope first, return shape second, with the get_institution handoff as the final clause. Nothing is repeated from the title or annotations.

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?

For a two-parameter read tool with no output schema, the description covers what it returns, how it matches, and where the slug leads. The only real gap is result-count behavior, which matters given the 25-item maximum.

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 0%, so the description must compensate. It constrains 'query' to name matching, but says nothing about 'limit' (default 10, max 25) or the two-character minimum, leaving an agent to discover the truncation behavior on its own.

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 and resource ('Search ... directory of 8,000+ U.S. banks and credit unions by name') with explicit scope, and names the sibling get_institution as the follow-up. An agent can distinguish this from get_institution or get_mortgage_lenders without opening a schema.

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?

The name-based search scope and the 'slug to pass to get_institution' sentence make the intended workflow clear: use this to resolve a name, then fetch details elsewhere. It gives no explicit exclusions (e.g., when to prefer get_mortgage_lenders for lender lookups), so it stops short of full routing guidance.

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