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

With no annotations, the description carries the full behavioral burden. It does disclose what the log contains (tool calls, blocked tools, allowed/blocked egress, connects with granted capabilities), but it says nothing about read-only-ness being guaranteed, retention limits, or pagination behavior beyond the schema's limit field.

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, front-loaded with the core purpose and followed by the one actionable flag. The parenthetical event list is dense but every element maps to real event types, so little is wasted, though the em-dash construction makes it slightly heavy.

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 four optional params, no annotations, and no output schema, so the description should ideally say more about what a returned audit record looks like or how results are ordered/paginated. It covers the content categories and the key flag but leaves return shape and scope limits to inference.

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 the baseline is 3 and the schema already documents all four parameters. The description's event enumeration largely restates the schema's enum values, adding only a small interpretive nuance ('connects with granted capabilities'), so it does not materially exceed 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 gives a specific verb and resource ('View the safety audit trail') and scopes it as a forensics log of sandboxed server activity versus sandbox blocks, which clearly separates it from siblings like mcp_usage or mcp_sandbox. It never names an alternative sibling explicitly, so the differentiation is implied rather than stated, keeping it below 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?

Usage guidance is limited to the parameter-level hint 'Use `securityOnly: true` to see only blocks and errors' rather than any when-to-use-this-vs-another-tool statement. An agent can infer this is the forensics/compliance view, but no exclusion or alternative routing is given.

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 no annotations, the description carries the full behavioral burden, and it falls short: it does not say what happens on failure, whether arguments are validated against the target tool's schema, what the response looks like, or any permission/timeout concerns. The only behavioral hint is the dynamic-availability condition.

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 short sentences, front-loaded with the action, followed by the usage condition and then the required input format. No waste.

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 dispatcher with no output schema and no annotations, the definition covers the essential action and input format but omits error behavior and any indication of the return shape, which would matter for an agent deciding how to handle the result.

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 both parameters are already fully documented ('name' as server-slug__tool-name, 'arguments' as a JSON object). The description restates the namespaced format but adds no syntax or usage detail beyond what the schema provides, 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 and resource ('Call a tool on a connected MCP server'), so an agent immediately knows this dispatches a call to a dynamically connected server. It does not, however, explicitly distinguish itself from siblings like mcp_discover or mcp_connect, leaving the routing between meta-tools to inference.

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?

Provides a clear when-to-use condition: 'when dynamically connected tools aren't directly available.' That is genuine routing guidance, but it names no alternatives (mcp_discover/connect/list_active) and gives no when-not 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?

With no annotations, the description carries the full burden; it discloses the connection outcome (tools become available) but not trust-tier confirmation needs, persistence/reconnect behavior, or auth requirements, which live only in the schema for `confirmed` and `saveProfile`. Useful but incomplete behavioral context.

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, front-loaded with the action and immediately followed by the three invocation options. Zero filler, and the most decision-relevant routing info comes first.

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 an 8-parameter tool with no annotations and no output schema, the description covers the core routing but omits the trust-tier confirmation flow, reconnect/profiles semantics, and error behavior. The rich schema compensates for parameter semantics, but behavioral completeness is thin.

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 baseline is 3. The description reinforces the slug-vs-command-vs-url selection logic but largely restates what the per-parameter descriptions already say ('Use instead of command for remote servers'), adding only the OR framing.

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 (Connect) and resource (MCP server) plus the effect (make its tools available), and names the sibling mcp_discover as the source of slugs. An agent can distinguish this from mcp_disconnect, mcp_list_active, and mcp_discover without opening the schema.

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?

Explicitly lays out three mutually exclusive invocation modes (slug from registry, command+args to spawn, url for remote), which routes the agent to the correct parameter set. It stops short of stating when-not to use it or what to do on failure/confirmation, so not a 5.

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?

No annotations, so the description carries the full burden. It usefully discloses that disconnecting removes the server's tools, but it omits whether the server can later be reconnected (mcp_connect exists as a sibling), whether the action is reversible, and whether in-flight tool calls are affected.

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 short sentences, action and effect front-loaded, with the helper pointer second. No waste.

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 single-parameter teardown tool with no output schema, the definition covers what it does, its side effect, and how to obtain the slug. The main remaining gap is the reversibility/reconnect question, which matters given mcp_connect is a sibling.

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% and the single slug parameter is fully documented in the schema, so the description need only be consistent. It refers to "a connected MCP server" without adding format or sourcing detail beyond what the schema and the mcp_list_active pointer provide.

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?

Specific verb+resource ("Disconnect from a connected MCP server") with the key side effect stated ("remove its tools"), which cleanly distinguishes it from sibling mcp_connect and the read-oriented mcp_list_active.

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 names mcp_list_active as the way to find connected servers, which implicitly tells the agent the prerequisite state (a currently connected server) and where to get the slug. It does not state any when-not-to-use condition or contrast against alternatives like mcp_connect, so it falls short of full routing 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?

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only search and discloses return content ('quality scores, trust tiers, and install information'), which is useful. However, it omits behavioral details such as authentication requirements, rate limits, result ordering, or pagination, leaving meaningful gaps for a tool with zero annotation coverage.

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 tightly written sentences with zero waste. The purpose is front-loaded, followed by return contents and usage guidance. 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?

For a simple search tool with complete schema coverage and no output schema, the description adequately explains what returns and when to use it. It does not cover result ordering, default limits, or error behavior, but those are minor given the tool's simplicity and the schema's parameter documentation.

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 three parameters (query, limit, category) are already documented in the schema. The description adds no parameter-specific meaning, such as syntax hints or default behaviors beyond the schema. Baseline 3 is appropriate when the schema fully handles parameter 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?

States a specific verb and resource: 'Search the MCP-Rating registry for MCP servers.' It distinguishes itself from mcp_connect by naming it as the follow-up step. However, it does not differentiate from other discovery-adjacent siblings like mcp_recommend or mcp_server_info, which prevents 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?

Provides clear usage context: 'Use this to find servers before connecting them with mcp_connect.' This tells the agent when to invoke it and the intended workflow. It stops short of exclusions or naming alternatives within the search space (e.g., mcp_recommend), so it is a strong 4 rather than a 5.

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 no annotations, the description carries the full behavioral burden. It helpfully enumerates the diagnostic categories returned, but never states that the operation is a safe read-only check, whether it incurs load on downstream servers, or any auth/latency characteristics.

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 front-loaded sentence that enumerates its contents with zero filler. Every listed item corresponds to real output the caller would receive.

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?

No output schema or annotations exist, so the description must carry the return-value story, and it does by naming each diagnostic field. It stops short of describing format or how per-server health is represented, but for a zero-arg probe this is close to sufficient.

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 takes zero parameters, so there is nothing to document and the baseline of 4 applies. The description correctly adds no spurious parameter detail.

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 (Get) and resource (gateway diagnostics) and enumerates the exact contents returned: version, uptime, connection status, registry reachability, per-server health. This clearly distinguishes it from siblings like mcp_list_active or mcp_server_info, though it never names an alternative 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?

There is no explicit when-to-use guidance, no prerequisites, and no mention of alternative tools for related queries. An agent can infer a health/diagnostics use case, but nothing in the text routes it there versus mcp_server_info or mcp_list_active.

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?

No annotations are provided, so the description carries full behavioral burden. It discloses the useful 'atomic' trait, but says nothing about destructive actions (delete, remove_server), permission requirements, error behavior, or side effects of connect/disconnect.

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 front-loaded sentence with zero waste. It is appropriately sized for a tool whose schema carries the parameter 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?

For a multi-action tool with eight parameters, no annotations, and no output schema, one sentence is thin. The schema lists actions but the description does not help an agent understand action categories, destructive operations, or behavioral implications.

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 the schema already documents every parameter and action. The description adds no parameter-level meaning beyond that baseline, so a 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 states a clear verb+resource ('Manage server groups') and adds the scope 'atomic connect/disconnect of sets of servers'. It does not explicitly distinguish itself from sibling tools like mcp_connect and mcp_disconnect that operate on individual servers, so sibling differentiation is missing.

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 implied by the phrase 'atomic connect/disconnect of sets of servers', suggesting this tool is for group-level operations. However, there is no explicit when-to-use, when-not-to-use, or alternative routing versus mcp_connect/mcp_disconnect.

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?

No annotations, so the description carries the burden, but for a zero-parameter listing tool there is little to disclose. 'List ... currently connected' implies a read-only, non-destructive operation and indicates what is returned; however it does not state auth requirements, whether the listing is cached, or any rate limits.

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 front-loaded sentence with no filler. The core action and scope are stated immediately with nothing wasted.

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?

No output schema exists, and the description compensates by stating what is returned (connected servers and their tools). For a simple no-arg listing tool this is nearly complete; only the boundary against mcp_discover remains 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?

The tool takes no parameters, so there are no parameter semantics to convey. Baseline for a zero-parameter tool is 4, and the schema (empty object) is consistent with the description's implicit claim of no inputs.

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?

Clear specific verb 'List' with a precise resource: 'currently connected MCP servers and their tools'. An agent can distinguish it from most siblings, but the description does not explicitly contrast it with near-neighbors like mcp_discover (unconnected servers) or mcp_server_info (single server).

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 when-to-use guidance and no alternatives named. The 'currently connected' qualifier implicitly suggests it differs from discovery, but the agent must infer when to pick this over mcp_discover or mcp_server_info.

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?

No annotations are provided, so the description carries the full behavioral burden. It mentions that profiles can be 'switched between' but does not disclose that actions like delete, remove_server, and switch have destructive or state-changing effects, nor does it describe persistence, permissions, or side effects.

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, front-loaded with the core purpose and one clarifying definition. There is no filler, and the example parenthetical adds useful context without bloating the description.

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 multi-action tool (8 parameters, 7 enum actions, no annotations, no output schema), yet the description only gives a high-level summary. It omits action-specific behavior, destructive-action warnings, return information, and usage differentiation, which are necessary for an agent to call it 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 100%, so the schema already defines all 8 parameters and the action enum. The description adds no additional meaning about parameter interactions or usage beyond what the schema provides. Baseline 3 applies when the schema does the heavy lifting.

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 clear verb and resource: 'Manage named connection profiles.' It further clarifies with the definition 'presets of server connections' and examples ('work', 'personal'). However, it does not distinguish this tool from possibly related siblings like mcp_groups or mcp_discover, leaving the agent to infer 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?

No guidance is given for when to use this tool versus alternatives, when to prefer each action (e.g., create vs add_server), or what prerequisites exist. The description only says 'manage', which is too vague to guide selection.

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?

No annotations are provided, so the description carries the full burden. It mentions search modes (semantic/keyword/expansion) and usage-history fallback, but says nothing about permissions, rate limits, ranking behavior, or what the response contains.

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 efficient sentences front-load the core action and then explain the query/no-query branches without waste.

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 read-only recommendation tool with no annotations and no output schema, the description covers invocation modes but leaves return shape, ranking, and any auth or rate-limit context 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% and the schema already documents all three parameters thoroughly, including limits and the category dependency on query. The description's parameter guidance largely repeats the schema, so baseline 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?

States a specific verb+resource (get recommendations for MCP servers) clearly. It distinguishes the tool from siblings like mcp_discover and mcp_list_active by focusing on recommendations driven by query or usage patterns, though it doesn't explicitly name how it differs from those siblings.

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 clear conditions for passing query vs omitting it, which covers the main usage modes. However, it doesn't mention when to prefer this over mcp_discover or other siblings that also surface servers.

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 no annotations, the description carries full behavioral burden. It helpfully discloses that changes are deferred ('applies on next connect') and that reset restores defaults, but it omits whether 'set' merges with or replaces existing grants, whether changes are reversible, and any auth/confirmation requirements — a meaningful gap for a security-sensitive mutation 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?

A single, front-loaded sentence covering scope, the three actions, and the deferred-application constraint. No filler or padding.

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 9-parameter, multi-action tool with full schema coverage and no output schema, the description covers purpose, actions, and timing. The one material omission is set/replace merge semantics for the grant fields, which matters 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 coverage is 100%, so the schema already documents every parameter, including enum meanings and example values. The description's mention of env/network/filesystem/subprocess categories adds framing but no semantics beyond what the schema provides, so 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 (view/customize) and a specific resource (a server's sandbox capability manifest), and immediately names the capability domains (env/network/filesystem/subprocess). This is clearly distinguishable from siblings like mcp_connect or mcp_server_info.

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 explains all three actions and their intent, and adds the key usage condition that 'set' grants apply on next connect, which tells an agent when in the lifecycle to call it. It does not name sibling tools as alternatives or state prerequisites (e.g. server must be discovered/known).

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?

No annotations are provided, so the description carries the full disclosure burden. It implies a read operation but says nothing about whether a connection is required, what happens if the slug is not found, permissions, or rate limits. For a lookup tool with zero annotation coverage this is thin.

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 efficient sentence that front-loads the verb and resource. Every clause earns its place, though the dual-source phrasing 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?

A read-only, single-parameter tool with no output schema, so the description could reasonably explain what 'detailed information' is returned. It stops short of that, leaving the return payload unspecified, though the lookup scope is covered.

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% and the single 'slug' parameter is documented in the schema itself, so the description adds no additional meaning. Baseline 3 is appropriate when the schema does the heavy lifting.

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 clear verb ('Get detailed information') and resource ('an MCP server') and clarifies the two lookup sources (registry or connected server). It distinguishes itself reasonably from siblings like mcp_discover and mcp_list_active, though it does not name them 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 mention of 'registry or a currently connected server' implies when this tool applies, but there is no explicit when-to-use guidance or contrast with alternatives such as mcp_discover. Usage is only inferable.

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?

No annotations are provided, so the description carries the full burden — and it frames the tool purely as a read-only viewer ('View usage analytics'), while the schema exposes a 'reset' action documented as 'clear all data'. A destructive capability is left undisclosed, which could lead an agent into irreversible data loss. No mention of permissions or reversibility.

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 front-loaded sentence that names the resource first and then the metrics. Zero wasted words and appropriately sized for 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 annotations, no output schema, and a multi-action tool that includes a destructive 'reset', the description should say more than it does. It omits the existence of non-viewing actions and any warning about data destruction, leaving a significant gap for an agent deciding whether to call it.

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 four parameters (slug, limit, action, threshold) are already documented in the schema, including enum meanings. The description adds no parameter-level detail beyond what the schema provides; 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 clear verb ('View') and resource ('usage analytics for connected MCP servers') and enumerates the metrics returned (call counts, latency, error rates, recent activity). It is distinguishable from siblings like mcp_gateway_health or mcp_audit, though it does not explicitly contrast with 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?

There is no guidance on when to choose this tool over mcp_gateway_health, mcp_audit, or mcp_server_info, nor any stated prerequisites (e.g., that a server must be connected). The description offers no when/when-not context at all.

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