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.

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuinely useful context beyond that: it discloses what the response contains (verdict, evaluation date, section list, content) and hints at the 'long review' size problem that motivates the `section` filter. It does not cover error behavior or rate limits, but that gap 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?

Two tight sentences: the first establishes what the tool returns, the second handles the narrowing parameter. The most important information (what you get back) is front-loaded and no sentence is filler.

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 carries the burden of describing returns, and it does so adequately by listing the four payload components. Combined with 100% schema coverage on inputs and annotations covering the safety profile, an agent has nearly everything needed; only error/edge behavior is unaddressed.

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 would be 3, but the description contributes beyond the schema by giving concrete section examples ('setup', 'security', 'token cost', 'FAQ') that clarify the matching semantics of the otherwise abstract 'heading contains this text'. It adds nothing for `max_chars` or `server` beyond the schema.

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?

States a specific verb and resource ('Get MCP Verdict's review of one MCP server') and enumerates the payload (verdict, evaluation date, section list, content). It is clearly distinguishable from search_servers (plural discovery) and get_guide (different resource), though it never names those siblings explicitly.

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 actionable guidance on the `section` parameter — use it to pull just one part of a long review — which implies the when-to-narrow case. However, it never states when to prefer this over search_servers or get_guide, nor any prerequisites or failure conditions, so routing is left to inference.

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

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 real behavioral context beyond the annotations: that the corpus is limited to reviewed servers only and that results include verdict, a one-paragraph summary, and a review URL — valuable since no output schema exists.

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?

Three compact sentences with zero filler. The core purpose is front-loaded, the examples follow, and the enumeration behavior plus return contents close it out — every sentence earns its place.

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 carries the return-value burden by naming verdict, summary, and URL. Both parameters are documented and the enumeration case is covered. Only minor gaps remain, such as ordering or how many results a query returns by default versus the limit.

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 100%, which sets a baseline of 3, but the description adds meaning beyond the schema: concrete example queries ('postgres', 'browser automation', 'oauth') clarify that 'capability' is a valid query dimension, and the omit-query behavior for listing is spelled out. The limit parameter's semantics live in the schema and are not duplicated, which is appropriate.

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?

States a specific verb+resource ('search reviewed MCP servers') and enumerates the searchable dimensions (name, category, capability) with concrete examples. It implicitly contrasts with the sibling get_server_review by returning summaries plus a review URL, but never names that sibling or states the division of labor explicitly.

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?

Gives one useful conditional instruction — 'Omit the query to list every reviewed server' — which tells the agent how to enumerate everything. However, it never states when to prefer this over get_server_review, nor any exclusions or prerequisites, leaving the search-vs-fetch decision to inference.

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