Every MCP

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

readOnlyHint=true already tells the agent this is a safe, non-mutating lookup, so the bar is lowered. The description usefully discloses the provenance (Official MCP Registry), which hints at freshness/authority, but says nothing about behavior when a client has no config available or whether results can be stale.

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 sentences, zero waste, with the output shape (install command or config fragment) and the scope (one server, one client) front-loaded.

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 identify the two possible return forms. For a 3-parameter read-only lookup with full schema coverage, that is nearly complete; only fallback/error behavior is unstated.

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%, so id, client, and search_id are all already documented in the schema (including the enum values and telemetry purpose of search_id). The description adds no parameter format or constraint detail beyond that, 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?

States a specific verb (return) plus the concrete resource (a ready-to-run install command or exact config fragment) scoped to one MCP server and one client, and names the data source. This distinguishes it from get_server (server details) and search_tools (discovery) by implication, 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?

The description implies the place in the workflow — you already know which server and client you want — and the search_id parameter hints at following a prior search_tools call, but the description body gives no explicit when-to-use or when-not-to-use guidance relative to get_server or search_tools.

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 only supply readOnlyHint=true, and the description goes well beyond that: it discloses freshness rules (fields present only when the server answered within 7 days, null otherwise), the tokenizer used for the estimate (o200k_base), the provenance of tool entries (tools/list), and an explicit prompt-injection warning that names/descriptions are untrusted data. That is exactly the behavioral context an agent needs and cannot get from structured fields.

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?

Purpose is front-loaded in the first sentence, then field-level semantics follow. The text is dense but each sentence carries information, and since no output schema exists the return-value detail is load-bearing rather than filler; only the multi-clause sentences around the 7-day rule could be tightened.

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 does the heavy lifting on return values and does it well for the volatile fields, plus provenance and trust warnings. It is still incomplete in that 'verification facts' is asserted but never explained, the remaining record fields are not enumerated, and no behavior is given for an unknown/unresolvable id.

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% — both id and search_id are documented in the schema, including format examples and the purpose of search_id. The description adds no syntax, format, or constraint detail about either parameter, 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 opening sentence gives a specific verb and resource ('Return the full registry record for one MCP server') plus the scope of what is included (verification facts, installable clients). However, it never names or contrasts the closest sibling get_install_config, even though 'which clients it can be installed into' overlaps with what an install-config tool would plausibly return, leaving minor ambiguity at the boundary.

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: the 'search_id from the search_tools result that led you here' hints at a search-then-fetch workflow, and the optional search_id note nudges the agent to pass provenance. There is no explicit when-to-use statement, no when-not, and no disambiguation from get_install_config, so an agent must infer the routing.

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?

The description goes far beyond the readOnlyHint annotation, explaining ordering rules, official_match and has_public_source semantics, freshness checks, nullability, and the registry data source. It discloses important behavioral caveats, such as the discovery-query official_match meaning and lack of GitLab verification.

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 description is front-loaded with the core purpose and alternative, but it then becomes extremely long and dense with ranking edge cases. Much of the official_match and ordering detail is unlikely to be needed by an agent selecting or invoking the tool.

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 explaining returned flags and fields, and it does so comprehensively. It covers official_match, has_public_source, sorting, tool_count, tools_tokens_estimate, protocol_version, and null cases.

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 moderate at 67%, and the description adds substantial meaning about how query wording affects query_class, official_match, and ordering. It does not explain filters, transport, publisher, or has_remote beyond the schema, but the query parameter semantics are unusually well documented.

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 first sentence states a specific verb and resource: searching the public MCP server universe by intended server behavior. It also distinguishes the result type from get_server by saying compact summaries are returned and get_server is needed for a full record.

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 clear usage context: use free-form words for what the server should do, and call get_server when a full record is needed. It does not explicitly cover when to use get_install_config or when not to use this search, but the sibling routing for the main alternative is clear.

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