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

The description significantly expands on the annotations: it discloses that the operation is a pure calculation with nothing stored, no external calls, no authentication, and no rate limit. It also clarifies the output is an estimate from a fixed model, not a forecast or quote, and specifies the output format (plain text with assumptions and a calculator link). This is rich behavioral context well beyond the readOnlyHint and idempotentHint annotations.

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 dense but every sentence serves a purpose: first what it does and the output, then when to use it, then operational guidance, then exclusions, then behavioral guarantees. It is front-loaded with the most decision-relevant information and has no filler or repetition of the title.

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?

Despite lacking an output schema, the description fully specifies the return structure: plain text, annual impact in USD, split into pipeline lift, CAC savings, hours returned, assumptions, and a calculator link. It covers input requirements, use cases, and behavioral side effects, making the tool fully usable for an agent with no additional context.

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 covers 100% of the six parameters with clear examples and units, so the description doesn't need to add much per-parameter detail. The description adds useful high-level context about the six inputs being required and that missing ones should be requested, but it doesn't redefine or extend the meaning of individual parameters. This stays at the baseline expected for full schema coverage.

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 specific action: runs zRev's ROI model on one company's numbers and returns a projected annual impact in USD split into concrete categories. It clearly identifies the resource (ROI model) and scope ('on one company's numbers'), which distinguishes it from sibling tools like get_benchmarks or gtm_diligence_checklist. It leaves no ambiguity about what the tool does.

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 explicitly says 'Use when a user wants a number for their own company,' giving a clear use condition. It also instructs the agent to ask for missing required inputs rather than guessing, which is practical guidance. It doesn't explicitly name alternatives or when-not-to-use conditions, but it excludes forecasts and quotes implicitly.

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