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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), but the description adds real value: data comes from public unauthenticated directories, and Bugcrowd scope is login-walled and reported as such rather than silently empty. It also discloses that has_wildcard triggers per-program detail calls on YesWeHack/HackerOne — useful cost/behavior context.

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 dense sentences, purpose front-loaded before the cross-platform caveat. The second sentence is long but earns its place by disclosing the Bugcrowd scope limitation and the per-program cost of has_wildcard; only minor tightening is possible.

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 6-parameter, cross-platform search tool with no output schema, the description names the returned fields, the data provenance, and platform-specific behavioral caveats (Bugcrowd scope, HackerOne-only launch dates). The unexplained 'see bounty_new_programs note' reference is the only real 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 description coverage is 100%, so the schema already documents all six parameters and the enum; baseline is 3. The description adds some semantic depth for has_wildcard (real scope asset identifiers, Bugcrowd unavailable) and platform-specific limitations, but largely reinforces what the schema states.

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 (Search) and resource (public bug-bounty program directories) across three named platforms, plus the returned fields (program name, cash bounty range, status). An agent can distinguish this from siblings like bounty_new_programs and bounty_program without opening any 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?

Usage is implied — search bounty directories when you want to find/list programs — but there is no explicit when-to-use/when-not guidance or routing to the sibling bounty_program (single) or bounty_new_programs tools. The only speculative handoff ('see bounty_new_programs note') is referenced but never explained.

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