Get an MCP setup guide, client profile, or comparison

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds one behavioral fact (omitting `topic` returns the full list), which is valuable, but it says nothing about what happens when `max_chars` truncates a long guide — a real concern given the 1000-60000 range.

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 compact sentence with an appended operational tip; no filler or restatement of the title. The list-all caveat is placed last rather than front-loaded, but the total length is well within budget.

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 output schema, the description correctly conveys the kinds of content returned, and annotations cover the read-only/open-world profile. It is, however, silent on the return format (guide text vs. metadata) and on how `max_chars` truncation manifests, which an agent calling a text-returning tool should know.

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 baseline is 3, and the description earns an extra point by explaining the meaning of an absent `topic` (list-all fallback) and enumerating the domain of `kind` and `topic` beyond the schema's bracketed examples. It does not clarify truncation semantics for `max_chars`.

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 the resource clearly (setup guides, client profiles, comparisons) and grounds it with concrete examples like 'Claude Code', 'Cursor', and 'MCP vs API'. It does not explicitly distinguish itself from the sibling tools (search_servers, get_server_review), but those operate on an entirely different resource, so an agent will not confuse them.

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?

It gives one concrete operational rule: 'Omit `topic` to list all guides.' That is genuinely useful, but there is no statement of when to prefer this tool over search_servers or get_server_review, and no guidance on choosing a `kind`. Usage is implied rather than prescribed.

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