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

With no annotations, the description carries the full burden of behavioral disclosure. It reveals a non-obvious trait: check names and categories are localized to the account locale and change with language, so matching must be by slug or checkId. It also details the entire return payload, providing transparency about the operation's outcome. Minor omissions like rate limits or side effects are acceptable given the read-like nature.

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 moderately long but every sentence adds value. The purpose is front-loaded, followed by requirements, return content, and a critical caveat about localization. It is logically structured with no fluff, balancing detail with brevity.

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 single-parameter tool with an output schema, the description is comprehensive. It lists all return components (status, score, overview, history, checks with details) and highlights an important edge case (localization). It lacks explicit error handling or pagination details, but the output schema likely covers structural expectations, and the description sufficiently guides invocation.

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 0%, so the description must compensate. It explains that audit_id is the id returned by start_audit or list_audits, which is critical context for obtaining the correct value. This goes beyond the raw integer type in the schema, effectively clarifying the parameter's provenance and usage.

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 states a clear verb and resource: 'Get the full results of one audit.' It distinguishes from siblings like get_audit_status by emphasizing 'full results' and enumerates the comprehensive return content, making its purpose unambiguous.

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 explains the required parameter (audit_id) and where to obtain it (from start_audit or list_audits), but does not explicitly contrast with alternatives like get_audit_status. It implies usage context but lacks explicit when-to-use vs. when-not-to-use guidance.

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