MCP Verify

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

Annotations already declare readOnlyHint=true, so the description does not need to state safety. It adds the comparison dimensions but does not disclose any other behavioral traits such as output format, error handling, or identifier validation. This is acceptable given the annotation but adds limited extra transparency.

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 a single, front-loaded sentence with no redundant words. It efficiently communicates the action and scope.

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 simple comparison tool with one array parameter and a read-only annotation, the description covers what is compared and the input constraint. It does not explain the return format, but the lack of an output schema means the description carries some responsibility; however, the listed comparison facets imply a side-by-side result, which is adequate. The description is complete for the tool's moderate complexity.

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% with a clear description of 'identifiers' as canonical server identifiers in namespace/name format. The tool description only adds that these are MCP servers and the 'up to four' constraint, which is already encoded in schema maxItems. No significant additional meaning is provided.

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 uses a specific verb 'Compare' with the resource 'MCP servers' and explicitly lists the comparison dimensions (score, verdict, auth, tool count, prompts/resources, freshness), clearly distinguishing it from siblings like search_servers or get_server_report.

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 use for comparing multiple servers side by side but provides no explicit when-to-use or when-not-to-use guidance, nor does it name alternatives. The usage context is inferred from the verb 'Compare' rather than stated.

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 indicate the tool is not read-only. The description adds that it generates artifacts, which aligns with the annotation. However, it does not disclose potential side effects like overwriting existing artifacts or any permissions or prerequisites, though the annotation lowers the baseline.

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 a single, front-loaded sentence that begins with the verb and resource, then enumerates the artifact types. Every word earns its place with no unnecessary detail.

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 10 parameters, 0% schema coverage, and no output schema, this description is completely inadequate. The agent cannot determine what each parameter does, which inputs are needed for a given source type, or how the artifacts are generated from the inputs.

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?

The schema has 0% description coverage, and the tool description does not explain any of the 10 parameters. It only vaguely references 'product docs' without mapping to fields like source_url, openapi_spec, or markdown_docs, leaving the agent without guidance on how to invoke the tool.

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 clearly states the tool generates agent-readable MCP artifacts from product docs and lists specific artifact types (server card, llms.txt, tool schemas, etc.), distinguishing it from the analysis, comparison, and policy tools in the sibling list.

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?

While no explicit alternatives or exclusions are mentioned, the description provides clear context that this tool is for compiling product documentation into a specific set of artifacts. The usage is implied but unambiguous given the tool's unique purpose.

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?

With readOnlyHint: false, the annotation indicates a write operation, and the description does not contradict this. However, the description only adds that the mandate is 'signed' and does not disclose side effects, permissions, persistence, or return behavior. It fails to explain the consequences of creating a mandate or any required configuration.

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 a single, well-structured sentence. It front-loads the core action and uses a colon to succinctly list the mandate's components. Every word adds meaning, with no redundancy or excess detail.

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?

The tool has 10 parameters, nested objects, and no output schema, while annotations only provide readOnlyHint. The description gives a high-level overview but omits critical contextual details like return values, error scenarios, lifecycle implications, or dependencies. It is insufficient for an agent to reliably invoke the tool without additional information.

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?

The schema has 10 parameters with 0% description coverage. The description mentions 'agent/user/server scope, budget, validity window, and tool constraints' which maps to some fields (scope, user_id, agent_id, server_id, budget_limit, valid_until, constraints) but omits several (metadata, signature, requires_human_approval). It does not provide format, semantics, or relationships, leaving significant ambiguity.

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 clearly states the tool's function: 'Create a Verify Mandate: signed delegated authority...' It specifies the verb (Create), the resource (Verify Mandate), and the key components (scope, budget, validity, constraints). This distinguishes it from sibling tools, none of which focus on mandate creation.

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 usage by defining what a mandate is, but does not explicitly state when to use this tool versus alternatives. There is no mention of exclusions or when not to use it. Given the context, an agent could infer it's for authorizing delegation, but the guidance is not explicit.

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 indicate readOnlyHint=false, so the description's statement that it 'Writes an audit-ledger decision event' adds meaningful side-effect transparency. But it does not disclose return format, failure behavior, or authorization requirements, leaving important behavioral aspects unaddressed.

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 terse sentences with no filler. The first sentence names the domain ('Gateway decision point'), and the second specifies the exact decision being made. Every phrase 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?

This is a complex 17-parameter authorization tool with no output schema and minimal annotations. The description fails to explain what the tool returns (e.g., a decision boolean, reasons, or error details), how to handle failures, or which parameters are essential beyond the required list. The description is insufficient for reliable invocation.

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?

With 17 parameters and only 12% schema description coverage, the description should compensate by explaining parameter meanings. It loosely maps to agent_id, user_id, and tool ('this agent', 'this user', 'this tool'), but offers no detail on the many other parameters like max_cost, max_risk, or action.

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 clearly states the tool's function: to decide whether an agent may call a given tool for a specific user at the current time. The verb 'Decide' plus the specific resource ('whether this agent may call this tool') distinguishes it from sibling tools like route_task or get_gateway_options.

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 provides clear context for use: before invoking a tool, to verify permission for a specific agent/user/payload. However, it does not explicitly mention alternatives or when-not-to-use cases, stopping short of the highest tier.

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 readOnlyHint annotation already communicates safe read behavior; the description adds that it explains risk findings and recommended action, but does not disclose details like error handling, output format, or prerequisites. It is consistent with the annotation.

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 a single concise sentence that front-loads the purpose. The 'Agent Sprawl Radar:' prefix is slightly extraneous but not detrimental.

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 simple read-only tool with one parameter and no output schema, the description gives a basic understanding but lacks context about how the output is presented or how it relates to sibling tools like score_agent.

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?

With schema coverage at 0%, the description must compensate. It identifies the parameter as referring to 'one registry agent,' but does not elaborate on the agent_id format, constraints, or relationship to other entities. Minimal added value.

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 uses the verb 'explain' with the resource 'risk findings and the recommended action' for a single registry agent, making the purpose clear. However, it does not explicitly differentiate from sibling tools like score_agent or list_high_risk_agents, though 'for one registry agent' implies a singular target.

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?

No guidance is provided on when to use this tool versus alternatives such as list_high_risk_agents or generate_remediation_plan. The description states only what it does, not the context or exclusions.

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=true, and the description is consistent with a read-only export. It adds useful context about the return format (JSON) and the specific contents of the policy, which goes beyond the annotation.

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 a single, well-structured sentence that starts with the verb and quickly conveys the core purpose and contents. No filler or redundancy.

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 tool with 6 parameters and no output schema, the description provides a solid overview but lacks detailed parameter semantics and return structure. It is adequate but leaves gaps about how to configure the policy and what the JSON response looks like.

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 only 17% (identifier only). The description vaguely references policy features like 'allow, blocked tools, required scopes, freshness, and approval gates' but does not map them to specific parameters (client, max_risk, requires_oauth, max_freshness_hours, no_write_without_approval). It fails to compensate for the low schema coverage.

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 uses a specific verb 'Export' with a clear resource ('JSON TrustOps policy for one MCP server') and enumerates the policy components. It distinguishes itself from sibling tools like create_mandate (creation vs export) and get_server_report (report vs policy).

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?

No guidance is provided on when to use this tool versus alternatives. It does not mention when to choose export_policy over create_mandate or other policy-related tools, offering no exclusions or preferred contexts.

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=true, and the description reinforces this with 'read-only.' It adds the return shape (id, title, text, url, metadata) and the 'ChatGPT-compatible' tag, but does not cover error behavior, side effects, or prerequisites. This adds some context beyond annotations but is not especially rich.

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 a single sentence and front-loaded with the core purpose. It is concise and doesn't waste words, though the 'ChatGPT-compatible' label could be clearer.

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 simple one-parameter read-only fetch, the description covers the purpose and return format sufficiently. The output schema is absent, so listing the return fields is helpful. It doesn't address error cases, but annotations handle the safety profile and the tool is simple.

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?

The id parameter is fully documented in the schema with format guidance ('namespace/name format'), so the description adds little extra semantic value. With 100% schema coverage, the baseline of 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 clearly states the tool fetches a full MCP server item and lists the returned fields (id, title, text, url, metadata). It distinguishes itself from siblings by specifying the resource type, though it doesn't explicitly compare to other getter tools like get_server_report or get_agent.

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?

No guidance is provided on when to use this tool versus alternatives. The phrase 'ChatGPT-compatible' hints at a context but is not explained, and there are no exclusions or 'use this instead of' statements.

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 adds the trait 'deterministic' and specifies the target agents, but it does not clarify that the tool only generates a plan and does not apply changes. The readOnlyHint annotation already covers safety, so the description's contribution is minimal beyond that.

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 a single, front-loaded sentence that effectively communicates the core function. The 'Agent Sprawl Radar' prefix adds context without significant bloat, and every word serves a purpose.

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?

Given the lack of an output schema, the description should clarify what a 'remediation plan' looks like (e.g., list of steps, severity levels). It also does not mention related tools or prerequisites, such as needing a drift report or risk assessment first. The description is too sparse for a tool that generates actionable outputs.

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?

The schema has one parameter (agent_id) with 0% description coverage, and the tool description does not mention this parameter at all. The description offers no meaning, format, or context for agent_id, leaving the agent to guess from the schema's type and required status alone.

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 clearly states the tool generates deterministic remediation steps for risky or drifting agents, using a specific verb (generate) and target resource. This distinguishes it from siblings like explain_agent_risk or get_drift_report, which analyze rather than produce actionable steps.

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 tool is used when remediation steps are needed for risky or drifting agents, but it does not explicitly state when to use it over alternatives like explain_agent_risk or get_drift_report. No exclusions or direct comparisons are provided, leaving the usage context to be inferred.

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=true, so the description does not need to state read-only behavior. It adds context by listing the returned attributes but does not disclose additional behavioral traits like performance implications or required permissions. This is comparable to the calibration example where annotations cover safety.

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 a single sentence, under 15 words, and gets directly to the point. The label 'Agent Sprawl Radar' is slightly stylistic but not wasteful. Every part contributes to conveying the tool's purpose.

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?

The tool is simple (one parameter, no output schema), and the description lists the return fields. However, it omits any explanation of the agent_id parameter and does not clarify terms like 'findings' or 'drift,' which might be ambiguous. It is adequate for a basic get-by-ID tool but leaves gaps.

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 carries the full burden for parameter meaning. It does not mention agent_id at all, only 'return one agent,' which implicitly suggests identifying an agent but provides no guidance on the parameter format or how to obtain it. The param name is self-explanatory, but the description adds no semantic value.

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 clearly states it returns a single agent with specific fields (tools, data access, findings, drift, recommended action). The verb 'return' and resource 'one agent' distinguish it from sibling tools like list_agents and get_drift_report.

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 context is clear: use this tool to retrieve one agent's detailed profile, implied by 'return one agent.' However, it does not explicitly mention when not to use it or suggest alternatives such as list_agents for multiple agents, so it lacks explicit exclusions.

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=true, and the description's 'return' is consistent with that. It adds the temporal scope 'across latest snapshots,' which is useful, but it does not disclose output ordering, default limits, or behavior when no agent_id is supplied.

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 sentence, front-loaded with the tool's essence, with zero filler words. It is as concise as possible while conveying the core action.

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 and no parameter descriptions, the description leaves important invocation details (what an event looks like, how limit/agent_id behave) unresolved. The temporal scope is helpful, but the overall picture is incomplete for an agent needing to call the tool correctly.

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%, and the description does not mention either parameter. 'agent_id' and 'limit' are only documented by their names/types, leaving their roles, defaults, and constraints unexplained; the description fails to compensate for the lack of schema descriptions.

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 uses a specific verb ('return') and resource ('agent drift events') and scopes it to 'latest snapshots,' which clearly distinguishes it from sibling tools like get_server_report or list_agents. The playful label 'Agent Sprawl Radar' doesn't obscure the core purpose.

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?

No guidance is given about when to prefer this tool over alternatives or when not to use it. The phrase 'latest snapshots' implies a current-state use case, but there is no explicit context or exclusion of historical reporting.

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 annotation readOnlyHint=true already establishes that this is a safe read operation, so the description need not restate that. The description adds useful context about the content structure (e.g., 'hash-chained audit events'), but does not disclose behavioral details such as filtering semantics, pagination, or result limits beyond what the schema suggests.

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 a single, tightly written sentence that front-loads the verb and resource, followed by a compact list of contained elements. Every word contributes value; there is no redundancy or 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?

While the description lists the content of evidence packs, it omits essential operational context: how the parameters filter results, whether limit applies to packs or items, any pagination or ordering behavior, and the structure of the response. With no output schema, the description carries the burden of explaining return semantics and partially fails to do so.

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%; the description provides no explanation for the parameters limit, user_id, agent_id, or server_id. It does not state how these filters affect the returned evidence packs, nor does it add any semantic meaning beyond the schema's bare property names. This is a significant gap for a tool with four optional parameters.

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 uses the specific verb 'Return' and clearly identifies the resource as 'Verify Ledger evidence packs', listing the exact content types included (invocations, hash-chained audit events, decisions, outcomes, mandates, cost summaries). It is unambiguous and differentiates from sibling tools that target other report types.

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?

No explicit guidance is provided on when to use this tool versus alternatives. There is no mention of scenarios, exclusions, or related tools for different query types. The description only states what the tool returns, leaving the agent to infer usage context.

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 annotation readOnlyHint=true already covers the safety profile, lowering the bar. The description adds context about the content of the return (semantics, guidance, inputs, hooks, fields) but discloses no behavioral traits such as side effects, error conditions, or required permissions. This is adequate but not rich.

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 a single sentence of about 20 words, efficiently front-loaded with the action 'Return' and listing five distinct items. No filler words or redundant information; it 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?

Since there is no output schema, the description must carry the burden of explaining return values. It lists five categories but does not describe their structure, format, or how they are presented. For a simple zero-parameter, read-only tool, this is moderate completeness, but it leaves room for ambiguity about the response shape.

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?

This tool has zero parameters, so the schema coverage is trivially 100%. According to guidelines, a baseline of 4 applies. The description mentions 'mandate inputs' as a returned item, not a parameter, so it adds no parameter semantics 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?

The description clearly states the tool's function with 'Return' followed by a specific resource: Verify Gateway semantics, /v1/route vs /v1/decide guidance, mandate inputs, ledger evidence hooks, and decision fields. This distinguishes it from siblings like route_task and decide_agent_call, which perform actions rather than return options. The broad list of returned items makes it slightly less precise than a single decisive action.

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 provides no guidance on when to use this tool versus alternatives. It simply states what it returns, leaving the agent to infer usage. There are no explicit exclusions or comparisons to sibling tools like get_hosting_options or get_subscription_options.

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?

With readOnlyHint=true in the annotations, the safety profile is already disclosed. The description adds value by specifying the types of information returned (capabilities, controls, endpoints), but does not go into deeper behavioral context such as return format or any side effects. This is a moderate addition on top of the annotation.

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 a single sentence that is front-loaded with the verb 'Return' and directly states the resource and its scope. Every word earns its place, with no filler or redundancy.

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?

Given the tool has no parameters, is read-only, and has a simple informational purpose, the description adequately covers what the tool does. It lists the key output categories (capabilities, controls, endpoints), which is sufficient for an agent to know when to call it. It could be slightly more detailed about what 'Verify Hosted' means, but overall it is complete for the tool's complexity.

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?

The tool has zero parameters, so there is no parameter information needed beyond the empty schema. The baseline of 4 applies, and the description does not need to compensate for any schema weaknesses. It correctly focuses on the output rather than parameters.

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 uses the specific verb 'Return' with a clear resource 'Verify Hosted MCP runtime/sandbox hosting capabilities, controls, and endpoints.' This distinguishes it from sibling tools like get_gateway_options or get_subscription_options by explicitly focusing on hosting.

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 tool is used when hosting capabilities or endpoints are needed, but provides no explicit when-to-use/when-not-to-use guidance or comparison with alternatives. It relies on the tool name to signal its purpose, which is acceptable but not explicit.

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 readOnlyHint annotation already declares the operation as read-only. The description adds that the report is 'full' and 'machine-readable', which is useful but minimal. It doesn't disclose details about caching, freshness, or any side effects, but the annotation lowers the burden.

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 a single, front-loaded sentence with no wasted words. It conveys the action, resource, and scope efficiently.

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 simple read tool with one parameter and no output schema, the description sufficiently states what is returned. It could elaborate on the report's contents, but the current level is adequate given the tool's simplicity and annotation support.

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% with the parameter described as 'Canonical server identifier in namespace/name format.' The description adds no further parameter-specific semantics beyond calling it a 'specific MCP server identifier', 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 clearly states the verb 'Return' and the resource 'full machine-readable verify report' for a specific MCP server identifier. This distinguishes it from siblings like get_drift_report and compare_servers, which target different reports or actions.

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 usage: when you need the verify report for a known server identifier. It doesn't name alternatives or exclusions, but the sibling tool names provide enough differentiation that the intended context is clear.

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 adds minimal behavioral context beyond the readOnlyHint annotation. It only states what is returned, not anything about permissions, response structure, or side effects. Since annotations already indicate a safe read operation, this is acceptable but not enriched.

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 a single, front-loaded sentence with the verb 'Return' at the start. It lists the key outputs with no filler or redundancy, making it highly concise and well-structured.

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 simple, parameterless read-only tool, the description sufficiently covers what the tool does. It lacks details about response format or use cases, but given the low complexity and no output schema, it is reasonably complete.

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?

The tool has zero parameters, so the schema fully documents what is needed. The description does not add parameter details, but the baseline of 4 for zero parameters applies, as there is nothing to clarify.

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 clearly states the tool returns specific items (alert types, subscription channels, watch scopes, and existing subscription endpoints), which precisely identifies its function. It distinguishes itself from sibling tools like get_gateway_options and get_hosting_options by the word 'subscription' and the listed content.

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 provides no guidance on when to use this tool versus alternatives. It lacks context about prerequisites, intended scenarios, or exclusions that would help an agent decide between this and similar option-fetching 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 already declare readOnlyHint=true. The description adds the 'discovered' scoping trait, implying only previously discovered items are returned, but offers no details on pagination, ordering, or output structure.

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 a single sentence with the key action upfront. The 'Agent Sprawl Radar' label is catchy but slightly extraneous, costing a point.

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 tool with no output schema and sparse annotations, the description fails to fully specify what the list contains, how to filter, or pagination behavior. The current text mixes entities and attributes, leaving the return structure unclear.

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%, and the description does not explain the 'limit' or 'risk_level' parameters. 'risk_level' appears as 'risk levels' in the description, hinting at filtering, but it's not explicit.

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 uses the verb 'list' and specifies the resource: 'discovered AI agents, MCP servers, bots, workflows, risk levels, and owners.' It distinguishes from siblings like get_agent (singular) and list_high_risk_agents (risk-specific) by implying a broad inventory, though the mix of entity types is slightly ambiguous.

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?

No guidance on when to use this tool vs alternatives. Sibling tools like get_agent and list_high_risk_agents exist, but the description doesn't mention them or any prerequisites/exclusions.

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=true, so the read-only nature is covered. The description adds the risk-filtering scope (high and critical risk agents), which is useful. However, it does not disclose behaviors like whether results are sorted, paginated, or how 'high risk' is determined, but given annotations the bar is lower.

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 a single sentence, front-loaded with the action and scope. The 'Agent Sprawl Radar' prefix is slightly decorative but not harmful. Overall, it is efficient with no redundant filler, though the metaphor could be omitted without losing meaning.

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 tool with a simple optional parameter and no output schema, the description is incomplete. It doesn't explain what 'high risk' means, how the limit affects results, or what the return structure looks like. Given the low complexity, more detail was expected.

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?

The input schema has a single optional 'limit' parameter with no description (0% schema coverage). The description does not mention this parameter at all, leaving the agent to guess its purpose and behavior. The description fails to compensate for the lack of schema documentation.

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 clearly states the verb 'list' and the resource 'high and critical risk agents', which distinguishes it from sibling tools like list_agents (which likely lists all agents) and get_agent (single agent). The phrase 'Agent Sprawl Radar' adds context but doesn't obscure the core purpose.

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 provides only a vague context ('for review') but no explicit guidance on when to use this tool versus siblings like list_agents, score_agent, or explain_agent_risk. There are no noted exclusions, prerequisites, or alternatives, leaving the agent to infer usage.

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?

With readOnlyHint already declared, the description adds value by specifying the output behavior: returning ranked matches with install config. This goes beyond the annotation, though it does not disclose ranking methodology or limitations. Still, the added context is useful for a read-only recommendation tool.

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 a single concise sentence that front-loads the action verb 'Recommend' and clearly conveys the purpose and output. There is no wasted wording or unnecessary detail.

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?

Despite having no output schema, the description provides a clear picture of the tool's main behavior and output (ranked matches with install config). With 100% schema coverage for inputs, the description is sufficiently complete for a recommendation tool, though it could elaborate on what 'ranked matches' and 'install config' entail.

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 parameter descriptions in the schema already provide full meaning. The tool description itself adds minimal parameter context beyond noting the 'plain-language task' input, which aligns with the 'task' parameter. Since the schema handles all parameters, a baseline score of 3 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?

The description clearly states the tool's function: to recommend MCP servers for a plain-language task and return ranked matches with install config. This distinguishes it from siblings like search_servers (which searches) and compare_servers (which compares), by emphasizing a natural-language input and recommendation output.

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 usage for plain-language task descriptions but does not explicitly state when to use this tool over alternatives such as search_servers or compare_servers. It lacks explicit exclusions or alternative guidance, though the focus on 'plain-language' hints at the intended input style.

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 declare readOnlyHint=true, and the description does not contradict this. The description adds no additional behavioral context such as what the routing decision entails, how risky parameters are handled, or what output to expect. It mainly restates purpose and a sibling distinction, so with annotations present a neutral score of 3 is appropriate.

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 two sentences and front-loads the core purpose, followed by a useful pointer to the main alternative. Every sentence earns its place with no filler or redundancies.

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?

Despite having 8 parameters and no output schema, the description offers only a purpose statement and one usage pointer. It does not explain the routing criteria, how optional constraints (max_risk, capabilities, requires_oauth, etc.) affect the result, or what the tool returns, leaving the agent without critical context for correct invocation.

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 50%, with several parameters lacking descriptions (e.g., client_target, requires_oauth, max_freshness_hours, no_write_without_approval). The tool description does not compensate by explaining any of these parameters, their relationships, or effects on routing behavior, so it adds little 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?

The description uses a specific verb and resource: 'Choose the best MCP server/tools for a task.' This clearly states the tool's purpose and distinguishes it from the sibling decide_agent_call by explicitly saying to use that tool when evaluating one specific attempted tool call.

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 gives an explicit alternative: 'Use decide_agent_call when evaluating one specific attempted tool call.' However, it does not address other potentially similar siblings like recommend_servers or search_servers, so guidance is clear for one key distinction but not comprehensive across all alternatives.

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 readOnlyHint annotation already discloses that the operation is read-only, and the description adds context about the two input modes. However, it does not explain what 'scoring' entails, whether it returns a score, or any other behavioral details beyond the annotation, leaving some ambiguity.

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 a single sentence, front-loaded with a descriptive label, and does not waste words. The 'Agent Sprawl Radar:' prefix is slightly decorative but not harmful. Overall, it is concise and scannable.

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?

The tool has two parameters, no output schema, and a terse description. It does not explain what the returned score means, what the output format is, or when to use each parameter. Given the absence of an output schema, the description carries the burden of explaining return behavior and fails to do so, leaving the tool under-specified.

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?

With 0% schema description coverage, the description must compensate for the bare schema. It does add some meaning by associating 'agent' with 'normalized agent payload' and 'agent_id' with 'existing registry agent,' but it fails to explain the relationship between the two parameters, their requirements, or the structure of the payload. This is insufficient for such sparse schema descriptions.

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 clearly identifies the action ('score') and the resource ('a normalized agent payload or an existing registry agent'). It conveys the tool's unique function compared to siblings like get_agent or list_agents, though it does not explicitly differentiate itself from potential alternatives such as explain_agent_risk.

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 provides clear context for use by specifying two valid inputs: a normalized agent payload or an existing registry agent. It does not, however, state explicit when-not-to-use guidance or mention alternative tools, so it stops short of full usage guidance.

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 provide readOnlyHint=true, and the description reinforces this with 'read-only'. It also discloses the return fields (id, title, url) beyond what annotations specify, adding valuable context about the output. No safety-critical behavior is hidden, and there is no contradiction with annotations.

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 extremely concise—two short sentences—and front-loaded with the core purpose. Every word contributes value: 'ChatGPT-compatible' sets context, 'read-only' signals safety, and the return format is stated explicitly. There is no wasted text.

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 simple search tool with 100% schema coverage and a read-only annotation, the description covers the essential aspects: purpose, return format, and query examples. It lacks guidance on how this alias relates to sibling 'search_servers' and does not mention pagination or ordering, but these are not critical for a basic search function.

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?

The input schema has 100% coverage for both parameters. The description adds meaningful examples for the 'query' parameter (e.g., healthcare MCP, OAuth MCP servers), which helps users formulate search queries. It does not duplicate the schema's limit description but enhances understanding of query intent.

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 clearly states it is a search tool that returns MCP server results with id, title, and url. The verb 'search' and resource 'MCP servers' are specific. However, it does not differentiate from the sibling tool 'search_servers', aside from calling itself an 'alias' without explaining what it is an alias for.

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?

There is no explicit guidance on when to use this tool versus alternatives. The description does not mention 'search_servers' or any other sibling, nor does it provide context about preferred use cases or exclusions. The only hint is 'ChatGPT-compatible', which is vague and not elaborated.

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 readOnlyHint annotation already covers side-effect safety. The description adds 'rank', implying ordering, but does not disclose return format, pagination via the limit parameter, ranking algorithm, or any auth/rate-limit behavior. It contributes minimal behavioral context beyond what the annotation provides.

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 a single, concise sentence that front-loads the verb and resource and efficiently names the key filtering dimensions. No wasted words; it 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 does not state what is returned (e.g., list of server IDs with scores) or how limit interacts with ranking. It covers all parameters via the schema, but overall tool behavior is under-specified for a 6-parameter tool. Adequate but with clear gaps.

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 all six parameters have descriptions. The description's mention of four dimensions aligns with parameters but adds no new semantic detail beyond the schema. This meets the baseline of 3.

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 clearly states the tool searches and ranks MCP servers, listing four specific criteria (capability, auth preference, client target, risk tolerance). This gives a specific verb+resource+scope. However, it does not explicitly differentiate itself from sibling tools like recommend_servers or search, 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?

There is no guidance on when to use this tool versus alternatives. It does not mention recommend_servers, compare_servers, or any preconditions/exclusions. The description merely states the function without situational context, offering little help for tool selection among siblings.

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