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

Annotations already establish readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description still adds substantive context the annotations cannot: the 0-100 scoring output shape, that red flags cover privacy/consent/history length, that no dollar valuation or outreach occurs, and that answers are not persisted.

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?

Front-loaded with the scoring action and its outputs, followed by usage, then hard exclusions and a privacy warning. Every sentence contributes; it is dense but not padded, though the privacy sentence partially repeats the 'does not store answers' point.

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 11 parameters and no output schema, the description must carry the return-value burden and does: it names the score range, the factor breakdown, buyer-type suggestions, red-flag categories and next steps. Combined with the full schema coverage and explicit scope limits, an agent has everything needed to call it and interpret the result.

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% with 9 of 11 params enumerated, so the schema carries the field-level detail and a baseline 3 is the floor. The description adds real semantic constraint on how to fill those fields: answers must be coarse multiple-choice, and names, contact details, patient information or the raw data itself must never be submitted — which directly governs the health/personal-info flags.

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 output ('Scores how ready ... 0-100') plus the input mode ('using only multiple-choice answers'), and enumerates the returned content (factor breakdown, buyer types, red flags, next steps). None of the siblings (term explanations, checklists, handoff links, disclosures) overlap with this scoring function, 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?

Gives an explicit trigger ('Use when someone asks whether their company's data could be sold or licensed, or what it would take') and explicit exclusions ('does not estimate a dollar value, make an offer, contact anyone, or store answers'). This tells the agent both when to call it and what adjacent requests it should not be used for.

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