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

Annotations declare a non-idempotent, open-world write; the description goes further by disclosing a side effect the annotations cannot express — a copy is sent to the WizeB team for human follow-up, which tells the agent about third-party data exposure and consent obligations. It also implies the run is persisted/updated via the artifact build, but does not state whether calling twice duplicates emails or what confirmation is returned.

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, both earning their place: the first establishes the artifacts and recipients, the second establishes the consent prerequisite. The consent gate is placed last so the agent reads it immediately before invoking. No filler.

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 mutating tool with no output schema, the description covers the essential facts: what is generated, who receives it, and the consent gate. The only meaningful gap is the return value / success signal and any idempotency note tying run_id to avoiding duplicate runs, which an agent calling this tool would plausibly wonder about.

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 name, email, run_id, answers, company and company_website are all already documented in the schema; baseline 3 applies. The description only echoes the name/email requirement and adds no syntax, format, or interaction detail (e.g., how run_id relates to score_index) beyond what the schema says.

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 compound action: it builds a defined artifact (full PDF scorecard with score, tier, six-dimension breakdown, answer-by-answer comparison, three fastest improvements) and emails it. The enumerated contents make it distinguishable from a generic report tool, though it never names the near-duplicate sibling email_startup_scorecard explicitly.

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?

Gives a concrete prerequisite gate: 'Ask the user for their name and work email first; only call this once they have agreed.' That is clear when-to-call guidance with a consent condition, but it offers no guidance on when a caller should prefer it over email_startup_scorecard or get_enhanced_index_report.

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