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

Annotations declare readOnlyHint=false, so the agent knows persistence is possible; the description goes well beyond that by defining the exact consent gate that triggers storage and confirming that without consent nothing is stored. It also constrains framing ('never tell the person their data was stolen or breached'), which is behavioral guidance annotations cannot carry. The idempotentHint matches the described scoring-and-save flow.

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?

Three dense sentences: outcome first, then the consent/storage workflow, then the framing constraint. Every clause carries information and the most important content (what it returns, what it saves) is front-loaded. It is on the long side for a tool description, but nothing is redundant.

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 needn't detail return values, yet it still previews the result shape. It fully covers the consent/privacy contract, the persistence condition, and the framing rules for a tool that both computes and conditionally writes — nothing an agent needs to invoke it correctly is missing.

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 75%, and the description reinforces the meaning that matters most: email/company exist to save the result for a follow-up from Alex Morris, and userConfirmed is the agreement flag authorizing that send. This clarifies the interdependent, all-or-nothing nature of the three optional parameters better than the schema's per-field descriptions do. Minor details of the nested answers object remain schema-only.

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?

It names a specific verb and resource ('Scores the person's answers to the AI data exposure check') and enumerates the outputs: exposure level, 2-4 reasons with policy sources, a recommendation, and a book_private_call URL. This is far more than a restated title. It stops short of a 5 because it never explicitly positions itself against the obvious sibling get_ai_exposure_questions, leaving the ordering of that pair to inference.

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 gives concrete operational context: ask for work email and company first, obtain agreement, then pass email, company and userConfirmed:true; otherwise nothing is stored. It also states presentation rules (editorial assessment of exposure/retention; never claim data was stolen). It lacks explicit when-to-use-vs-alternatives routing among siblings such as get_ai_exposure_questions or book_private_call.

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