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

With no annotations provided, the description carries the full burden of behavioral disclosure. It details the outputs and includes a link to a paid audit, which is a behavioral trait. However, it does not explicitly state whether the operation is read-only, non-destructive, or whether it makes network calls or has side effects. Since it's labeled a 'preview', it implies safety, but this is not explicit, leaving a moderate gap in transparency.

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 two sentences with no filler. It front-loads the action and then efficiently lists inputs and outputs. The inclusion of the paid audit link is compact and relevant. Every sentence contributes directly to understanding the tool's purpose and deliverables, making it appropriately sized and well-organized.

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 that there is no output schema, the description must explain what the tool returns, and it does list the key outputs. It also mentions the audit link, which is a relevant action. However, it does not describe the return format, data types, or any error scenarios, and it lacks usage guidance for alternatives. Still, for a simple 3-parameter preview tool, it covers the essential information an agent needs to call it 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?

Schema description coverage is 100%, so the input schema already documents all three parameters (tools, industry, teamSize) with their descriptions and enums. The description merely restates these inputs without adding deeper meaning or nuances. It does clarify the meaning of 'headless gaps' in the output, but that is output-related, not parameter-related. Thus, the description adds minimal value beyond the schema, earning the baseline score.

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 clearly states a specific action ('Run a preview StackScan') and precisely lists the inputs (list of tools, team size, industry) and outputs (current spend, optimized spend, monthly/annual recoverable, headless gaps, top 5 replace/remove opportunities, and paid audit link). It distinguishes itself from siblings by emphasizing 'preview' and the paid audit path, making the tool's purpose and scope 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 implies a preview use case but does not explicitly guide when to use this tool versus alternatives like complete_stack_audit or start_stack_audit. No when-to-use or when-not-to-use conditions are stated, and no alternative tools are named as contrasts. The agent must infer from the word 'preview' without clear routing guidance.

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