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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely useful behavior: the latest reading is always returned, while full history, per-stock closes, and CSV are gated behind the AI Metric pass (a paywall/entitlement constraint not visible in annotations). The closing disclaimer frames the output as data, 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 core purpose is front-loaded, and the gating note plus disclaimer are useful. However, the opening is a single comma-spliced run-on cramming the 47-stock sector list, six possible states, and seven sub-metrics into one sentence, which costs readability without adding decision-relevant 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?

With no input parameters and no output schema, the description carries the burden of explaining what comes back, and it largely does by enumerating the score, its states, and the component metrics. It also discloses the entitlement boundary for history/CSV. Some gaps remain about freshness cadence and update frequency, but an agent has enough to invoke it correctly.

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 tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool is 4. The description also names the concrete fields surfaced (state, momentum, breadth, distance from high, relative strength, correlation, bubble heat), which is return-content detail rather than parameter meaning.

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 exactly what the tool returns: one 0-100 score for the whole AI market plus its qualitative state and sub-metrics. It is clearly a read of a composite AI-market indicator rather than a generic market call. It does not, however, differentiate itself from near-siblings such as get_owl_score or get_market_radar, which an agent could easily 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?

Usage is only implied: an agent can infer it should call this when it wants the AI-sector composite reading. There is no explicit when-to-use, when-not-to-use, or guidance on choosing this over get_owl_score, get_market_radar, get_carv, or get_data_pack. The one gateway note ('the full history... need the AI Metric pass') hints at an upgrade path but is not framed as usage guidance.

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