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

With no annotations to carry the safety/behavior profile, the description compensates well: it discloses that signals are weighted by track record, that absent components are renormalized rather than treated as neutral, that as_of bounds results point-in-time, and that the output includes component breakdown, coverage, and confidence. It also notes this reads stored/free data and is not advice.

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 and front-loaded with the core composite concept, and nearly every sentence carries operational value. It is slightly cluttered with branding/preamble ('★ COMPOSITE (Pro)', 'FREE', 'Not advice'), and the EXPLAIN_MODE reference assumes external context, which keeps it from a perfect conciseness score.

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 an output schema exists and there are only three parameters, the description covers what an agent needs to invoke the tool correctly: parameter semantics, behavior, data sources, prerequisite steps, and output scope. There is no material missing context for a tool of this complexity.

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%, but the description effectively explains the non-obvious parameters: as_of is a YYYY-MM-DD point-in-time bound, and audience accepts 'retail' or 'pro' with a default from EXPLAIN_MODE. The ticker parameter is self-evident from the tool name and description, so the compensation is adequate.

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, non-tautological purpose: compute a single composite sentiment score for a ticker by blending weighted analyst calls, SEC insider activity, and StockTwits retail sentiment. It clearly distinguishes itself from sibling single-source tools by emphasizing that it is a composite with a transparent breakdown.

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 a concrete prerequisite ('run analyst_views on your analysts first') and a clear sense of when this tool is appropriate: when a blended, free composite score is needed rather than a single data source. It does not explicitly name alternatives or say when not to use it, so it stops short of full explicit routing.

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