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

Annotations only declare readOnlyHint, and the description adds substantial behavioral disclosure beyond that: it reports the full thesis first, derives a comparable-period trend, identifies the exact claim tested, explains support or challenge, states what the metric cannot prove, and guarantees no wait-and-call-again on cache miss. This is rich, honest behavior description with no contradiction.

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 long but information-dense, and the core promise is front-loaded: a metric interpreted against the complete investment case in one synchronous response. The later sentences earn their place by explaining cache behavior, response structure, and response_mode options. It could be tightened, but for the complexity involved it is well structured.

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?

The description covers the output flow, cache behavior, response modes, and one concrete item example, which is quite complete given the output schema already exists. The main gaps are undocumented entity semantics and reading_level values, but those are minor against the overall richness. An agent can largely understand what will happen when invoking this tool.

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 does add meaning for item and response_mode, explaining the earnings bundle and the plain/raw/standard/deep modes. However, the required entity parameter is not described, and reading_level is completely absent, leaving the agent to infer their meaning from context and parameter names alone.

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 explains what the tool returns: a metric interpreted against the complete investment case, including whether evidence supports or challenges the thesis. It gives concrete detail such as item="earnings" bundling revenue, net income, and diluted EPS. However, it does not explicitly differentiate itself from sibling tools like get_thesis or get_analyst_view, so it loses the last point.

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 gives useful operational context, such as the tool being synchronous, complete on cache miss, and deterministic. It also explains when to use different response_mode values. However, it never states when to use this tool versus alternatives like get_thesis or get_analyst_view, so the selection guidance is only implied rather than explicit.

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