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

Annotations only declare readOnlyHint=true, so the description adds real behavioral context: it returns the full answer() bundle for every name, passes response_mode through without a second call, and explains how names without a built case are handled. This goes beyond what annotations alone convey, though it stops short of describing response shape in detail.

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 front-loaded with the core purpose and use case. The only minor redundancy is 'side by side' and 'weigh against each other', and the response_mode explanation could be slightly tighter, but every sentence contributes useful information.

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 comparison tool with no output schema, the description adequately explains what the response contains (full answer() bundles), how to invoke it, what to do for single companies, and how missing cases are handled. The main omission is a semantic explanation of reading_level, but the parameter schema still provides its enum and default.

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 carries the burden for parameters. It clarifies 'entities' as the companies to weigh, and explains response_mode by listing its values and pass-through behavior. However, reading_level is never mentioned, leaving one of three parameters semantically unexplained despite the low 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 names a specific verb ('Compare'), a resource ('two or more companies'), and the output (valuation data, investment thesis, helps/hurts). It also distinguishes itself from answer() and screen by stating what kind of question it serves ('X vs Y, which is the better business / better buy / more defensive?').

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?

Explicitly states this is the front door for side-by-side comparisons and directs single-company questions to answer(). It also clarifies that the comparison is based on investment cases rather than raw screener ratios, giving an agent clear selection criteria among siblings.

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