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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond annotations: the call is free and consumes no research credits, and it is guidance rather than a research request. It does not describe return shape, but that is acceptable given no output schema.

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?

Four short sentences, front-loaded with the usage trigger and the key exclusion. Every sentence carries information, though the middle sentences about overview vs. topic selection could be tightened into one.

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?

For a zero-required-param, no-output-schema guide tool, the description adequately covers when to call it and that it is free. However, the topic enum's semantics are entirely unexplained in both schema and description, which is the main gap an agent faces when deciding which topic value to pass.

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 carry parameter meaning. It only implies the topic parameter's role ('Overview introduces combinable topics; choose a topic for more detail') and names the default implicitly; it never explains what the 11 enum values (live, coins, chains, coverage, data, etc.) each yield, leaving the agent to guess from terse enum strings.

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 verb+resource and clarifies the tool's nature: it is 'Free guidance, not a research request' that explains what CryptoSocials can investigate. It distinguishes itself from research-query siblings by framing itself as meta-guidance, though the scattered phrasing ('overview introduces combinable topics') is slightly less crisp than a clean purpose statement.

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?

Explicit triggers are given ('Use when asked what CryptoSocials can investigate, for research ideas, about its evidence or how research credits work') plus an explicit exclusion ('A specific question can proceed directly without this call'). This is exactly the when-to-use/when-not guidance the dimension asks for.

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