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

With no annotations, the description carries the full behavioral burden. It discloses what the log captures and how securityOnly narrows it, but says nothing about read-only semantics, event retention/coverage window, ordering, or what happens when filters match nothing — gaps that matter for a forensics 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?

Two sentences, front-loaded with the resource and its scope, followed by the one actionable filter hint. The parenthetical enumeration is dense but each item earns its place by matching a real event type.

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 usefully describes the returned event content, which is the key missing structured information. It stops short of covering ordering/recency limits or the fact that results are capped, though the limit/ordering details do live in the schema.

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 are already documented, including the securityOnly meaning and the limit default/ordering. The description's securityOnly sentence ('blocks and errors') largely restates the schema, 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 and resource ('View the safety audit trail') and immediately scopes it as a forensics log, then enumerates exactly what it contains: tool calls, blocked tools, egress allowed/blocked, connects with granted capabilities. That enumeration maps onto the `event` enum and separates it from analytics-style siblings like mcp_usage.

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 tells the agent when to narrow scope: 'Use `securityOnly: true` to see only blocks and errors.' However, it never says when to reach for this tool rather than alternatives such as mcp_usage or mcp_gateway_health, so selection guidance is clear but not complete.

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?

With no annotations and no output schema, the description carries the full burden and does disclose the return shape (trust tiers, install info, quality scores) and that only configured registries are searched. It omits confirming the operation is read-only and says nothing about rate limits or pagination behavior, which is why it is not a 5.

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 tight sentences with no filler; purpose, return content, and the routing hint are all front-loaded before any elaboration.

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 description compensates for the missing output schema by naming what results contain, and all three parameters are schema-documented. Small gaps remain around default registry configuration and result pagination/limits beyond the schema's max.

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 query, category, and limit are already documented in the schema (baseline 3). The description adds only the registry context ('MCP Rating by default') and nothing about query syntax or category source.

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 configured MCP registries ... for MCP servers') plus what comes back (trust tiers, install info, quality scores). It is clearly distinguishable from siblings like mcp_server_info, mcp_recommend, and 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?

'Use this to find servers before connecting them with mcp_connect' gives an explicit use context and names the downstream alternative. It stops short of ruling out competing discovery tools such as mcp_recommend or describing when NOT to use it.

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 the full burden and does well: it discloses that 'set' is a partial patch ('only the fields you pass change, the rest keep what the server has now or would get by default') and that changes are deferred ('applies on next connect'). These are non-obvious mutation semantics an agent could not infer from the schema. It still omits the permission/authorization requirements and what a failed or rejected grant looks like.

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 dense sentence with the purpose front-loaded and the action routing following in priority order. It is long but every clause (partial-update behavior, deferred application) earns its place; only the nested parenthetical stacking costs it 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?

No annotations and no output schema, and for a 9-parameter policy mutation tool the description covers actions and mutation semantics adequately. It does not say what 'view' returns or how enforcement failures surface, but the schema's enum descriptions (e.g. l2-container requires Docker) pick up part of that slack.

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 all nine parameters, including enum values and the [set] action prefixes. The description's only added parameter meaning is the merge semantics for omitted fields on 'set', which is useful but marginal. 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 specific verb pair (view/customize) and the exact resource (a server's sandbox capability manifest), then enumerates the four policy domains it covers (env/network/filesystem/subprocess). No sibling tool deals with sandbox grants, so the agent can route to it unambiguously.

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?

Maps each action enum value to a purpose: 'view' to inspect, 'set' to tighten or loosen grants, 'reset' to revert to defaults. This tells the agent which action to pick but gives no guidance on when this tool is preferable to adjacent tools like mcp_connect or mcp_profiles, nor any prerequisites.

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.