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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, but the description adds substantive context: the HTTP 202 'pending' retry semantics for bars, the api:read auth requirement, 'same for every reader', and that the response carries app_url. These add genuine value beyond the structured flags.

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 content is dense and earns much of its space, but it's delivered as one long run-on paragraph with no structural breaks between views, and phrases like 'The same for every reader' are opaque. Front-loading the overview is good, but per-view formatting would improve scanability.

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?

No output schema exists, and the description compensates by describing the return payload per view and mentioning the app_url field. For a complex multi-view dispatch tool it's mostly complete, though the 'same for every reader' phrasing and lack of any response-shape detail leave minor gaps.

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?

With 75% schema coverage, the description still goes well beyond it: it enumerates the interval options, explains that start/end are ISO timestamps with start < end <= now, clarifies venue reference (US equities) vs hyperliquid (perps, bare or dex-prefixed), and notes observed_at as timezone-aware. This meaningfully disambiguates the enum-driven dispatch.

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 it returns the Research page's reads for one symbol, then enumerates each view (snapshot, bars, return, trade_baseline, context, relationship_profile) with a concrete description of what each returns. This is specific verb+resource, though it doesn't name siblings like get_bars or get_live_snapshot that an agent might otherwise confuse it with.

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 per-view descriptions give clear context for which view to select (e.g., bars for chart OHLCV, snapshot as the default, trade_baseline for the last trade at or before observed_at), and the required param conditions are noted. It lacks explicit 'use X instead' routing to sibling tools, keeping it below a 5.

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