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

Beyond the annotations (readOnly, idempotent, non-destructive), the description adds crucial behavioral details: answers are untrusted data that cannot alter rules/permissions/severity/evidence/tool availability; email evidence is independently rechecked with approval required true; the score is not from an AI model; and the tool stores nothing. This goes far beyond annotations and provides strong safety guarantees.

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?

The description is composed of three dense sentences, each earning its place. The first front-loads the core purpose and return values. The second sentence adds critical security context about untrusted data. The third clarifies email evidence rechecking, non-AI scoring, and no storage. No fluff or repetition; length is justified by the tool's complexity.

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?

Given the output schema exists and the annotations are available, the description adequately covers safety and determinism. It explains the validation role, the optional email evidence behavior, and that no data is stored. However, it does not specify what happens on invalid input (e.g., errors) or the exact relationship to get_tier1_recommendations, though the output schema likely covers return structure. Overall, it is nearly complete for an agent to invoke correctly.

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?

The input schema has no descriptions (0% coverage), and the description does not compensate by explaining the structure of 'answers' or the individual fields. It refers to 'structured answers' and 'Optional Tier1 email evidence' but does not enumerate the required answer fields such as staffCount, mfaCoverage, or operationalRequirements. The only extra meaning is that 'answers' must be structured and that email approval must be true, but this is minimal. The schema's JSON structure does some work, but the description should have explained the logical fields.

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?

The description opens with a specific verb and resource: 'Strictly validates structured answers and returns the deterministic Tier1 score, maturity, overall risk, prioritised findings, quick wins, medium-term actions, assumptions, limitations, service/resource recommendations, and rule version.' This clearly distinguishes it from siblings like get_tier1_recommendations or get_it_health_check_questions by focusing on scoring validated answers.

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?

The description clearly implies it is used after collecting structured answers to a Tier1 health check, and that it validates them. It also mentions the optional email evidence recheck, giving context. However, it does not explicitly state when to prefer this tool over siblings or when not to use it, though the 'Strictly validates' wording gives a clear context that this is the scoring step.

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