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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavior: the 24h aggregation window, that ranking is by average signal strength across constituent companies, and that each row carries a tier word and a count of companies with chatter. It omits pagination and ordering ties, but for a fixed-window ranking read that is minor.

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?

A single front-loaded sentence carries the ranking metric and the return fields, followed by a brief scope disclaimer. Nothing is redundant, though the sentence is dense enough that the output shape takes a second read.

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 only two optional parameters, full schema coverage, and rich annotations, the description covers what an agent still needs: the aggregation window, the ranking basis, and the per-row fields. No output schema exists, yet the description sketches the return shape adequately.

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 coverage is 100%, so the enum values 'sectors'/'industries' and the 1-50 limit are already fully documented in the schema. The description reinforces the sector-versus-finer-industry distinction but adds no syntax, defaults, or edge-case guidance beyond what the schema states, so the baseline 3 applies.

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 concrete verb and resource ('Returns sectors or industries ranked by the average 24h signal strength of their companies') and describes the payload fields (tier word, chatter company count). That is far more specific than the title alone. It does not explicitly contrast itself with company-level siblings such as get_company_score, so it stops short of a 5.

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 implied by the ranking semantics and the 'not a price prediction or investment advice' caveat, which tells the agent how to frame the output. There is no explicit statement of when to prefer this over per-company or per-strategy tools, and no exclusion conditions beyond the disclaimer.

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