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

Goes well beyond the thin annotations by disclosing the auth flow (agent key via POST /agent/auth, then Bearer token), per-key and per-email rate limits, the asynchronous email-based scoping step, and the hard rule against including credentials or customer data. It also makes clear that submitting a request does not by itself start testing, which is exactly the kind of non-obvious behavior an agent needs before calling a mutation tool.

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?

Four tight sentences that front-load the action, then auth, then process, then limits and prohibitions. Every sentence carries operational content; there is no filler, though the parenthetical auth mechanics sit slightly awkwardly between purpose and process.

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 an 11-parameter, 6-required outbound request tool with no output schema, the description covers the important unknowns: authentication, quotas, consent requirement and what happens next. The remaining gap is what the agent gets back on success (request ID, confirmation, status), which is neither in an output schema nor described here.

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 64% schema coverage the schema already documents most fields, and the description mostly reinforces what is there (email is the reply address, targets must contain no credentials) rather than adding new meaning. The undocumented fields — notes, reason, company, website, timeline — and the enum values of test_type and reason receive no elaboration in the description, so it does not compensate 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?

States a specific verb and resource ('Send a request for a penetration test or an AI application security assessment to Excession Labs') plus who it acts on behalf of. This is unmistakably distinct from the read-only siblings get_page, how_to_contact and search_site, so an agent can route to it without opening the 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?

Frames the trigger clearly ('on behalf of a person who asked for it') and states operational limits (5/day per key, 3/day per email) plus the downstream process (email to agree scope, written authorization required before testing). It does not name an alternative tool, but no sibling could plausibly substitute, so the omission is minor.

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