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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('Get') and input formats, but gives no information about return value shapes, error conditions (e.g., not found), permissions, rate limits, or side effects. This is insufficient for a tool with no other structured metadata.

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 direct and front-loaded with the verb. Every word contributes meaning, and there is no padding or repetition. It is appropriately concise for a simple retrieval 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?

For a one-parameter read tool, the description is minimally viable: it explains what the tool does and what input it expects. However, with no output schema available, it does not describe the return format or what a 'catalog card' contains, and it offers no contextual guidance about when to use this tool over siblings.

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 describes only a single string parameter 'spec' with zero description coverage, so the description's mention of three accepted formats (owner/repo, github:owner/repo, GitHub URL) adds essential meaning. However, it lacks examples or detailed syntax expectations, leaving some ambiguity about exact URL forms.

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 purpose with a specific verb ('Get') and resource ('catalog card'), and enumerates accepted identifier formats (owner/repo, github:owner/repo, GitHub URL). This distinguishes it from sibling tools like list or search, which handle multiple cards or querying.

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 (e.g., dsh_plugin_search or dsh_plugin_list). It does not mention when not to use it, prerequisites, or alternative tools for related tasks, leaving the agent without decision-making support.

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. 'Inspect' suggests read-only behavior, but it does not disclose potential side effects, error conditions, required permissions, or whether it accesses local vs. remote data. It does list the specific files inspected, which adds minimal 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?

The description is a single, information-dense sentence with no redundant text. It efficiently lists the inspected artifacts while remaining compact.

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 minimal annotations, the description should explain what the tool returns, what spec accepts, and how it differs from similar sibling tools. It only describes the input scope, leaving significant gaps for the agent to select and invoke 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?

The input schema has one parameter 'spec' with 0% description coverage, and the description does not explain what 'spec' refers to (e.g., plugin ID, path, or name). It only says 'one plugin,' which weakly implies that spec identifies the plugin, but this is insufficient.

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 'inspect' and identifies the resource as 'one plugin' with a list of specific files and metadata (package.json, cordis.patch.yml, README, skills, DSH bundle metadata). It is clear and distinct from listing/searching, but does not explicitly differentiate from sibling tools like dsh_plugin_get or dsh_plugin_readme.

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 phrase 'for one plugin' implies it targets a single plugin, giving some contextual usage cue. However, there is no explicit guidance on when to choose this over alternative tools such as dsh_plugin_get or dsh_plugin_readme, nor any 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?

With no annotations, the description must disclose behavioral traits. It indicates a mutation (install) and adds a safety requirement (--allow-install). However, it omits potential side effects, such as whether installation is immediate, reversible, or affects existing plugins, leaving some behavioral 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, focused sentence. It starts with the action, mentions the mechanism, and includes a requirement. There is no wasted wording, and it is perfectly sized for the tool's simplicity.

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 install tool with one parameter and no output schema, the description covers the core action and a prerequisite. However, it lacks context about post-install behavior (e.g., if the plugin is immediately available or if a runtime restart is needed), which would be useful given sibling runtime tools. It is adequate but has a clear gap.

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 fully covers the single 'spec' parameter with examples ('github:owner/repo, npm name, or path'), so the description need not add more. The description offers no additional parameter detail, but the baseline of 3 is appropriate given 100% 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 clearly states the action: 'Install a plugin into the DSH profile', and identifies the underlying command 'dsh plugin add'. This distinguishes it from siblings like uninstall, list, and search, making the tool's purpose unambiguous.

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 the critical prerequisite 'Requires --allow-install', telling the agent when the tool can be invoked. It doesn't explicitly compare with alternatives, but for an install operation the intended usage is clear given the sibling set.

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 must carry the transparency burden. It discloses that the tool reads from a cache and may be stale, which is useful behavioral context. Yet it does not specify return format, network behavior, or what happens when the cache is empty, leaving many behavioral traits undisclosed.

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 with no waste: the first states the core function, the second gives a conditional alternative. It is front-loaded and efficiently 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?

Given the tool has 7 parameters, no output schema, and no annotations, the description is insufficiently complete. It only addresses the cache refresh edge case and does not explain the meaning or interaction of the many filtering parameters, nor the return shape of the list.

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 29% (kind and query have descriptions), and the tool description adds no parameter information. The remaining five parameters (limit, offset, language, minStars, includeArchived) are left to bare schema constraints, leaving a significant documentation gap that the description fails to fill.

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 'List cached dsh-plugin repositories' clearly identifies the action (List) and resource (cached repositories), and the word 'cached' helps distinguish it from tools like dsh_plugin_search. However, it does not explicitly differentiate from dsh_plugin_list_installed, so it falls short of a perfect 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?

The instruction to call dsh_plugin_refresh_catalog when the cache is empty or stale provides an explicit alternative for a common usage scenario. However, it lacks broader guidance on when to choose this tool over dsh_plugin_search or dsh_plugin_list_installed, so it earns a 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 provided, the description must disclose behavioral traits. Listing is generally read-only, but the description does not explicitly state that it performs no modifications, doesn't require special permissions, or depends on a configured profile. The mention of 'configured DSH profile' adds some context, but lacks detail about failure modes 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?

The description is a single concise sentence that directly states what the tool does. Every word earns its place, with no redundancy or noise.

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 simple zero-parameter schema and no output schema, the description provides sufficient information for an agent to understand the tool's core purpose. However, it could be more complete by explaining what 'installed' means (e.g., in the local profile vs. remote) and whether the list includes versions or other details. The presence of multiple sibling tools also calls for a brief note on how this differs from dsh_plugin_list.

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 accepts zero parameters, so the baseline is 4. The description correctly does not mention parameters, and the empty schema confirms no input is needed. No additional parameter semantics are required.

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 ('List') and identifies the resource ('bundles and dependencies') plus the scope ('installed in the configured DSH profile'). It clearly distinguishes from sibling tools like dsh_plugin_list (which likely lists all available plugins) by adding the 'installed' qualifier.

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 explicit guidance on when to use this tool versus alternatives. It does not mention use cases, exclusions, or when to prefer dsh_plugin_list or dsh_plugin_status instead. The usage context is only implied by the name and description.

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, and the description only states the action without disclosing potential side effects, authentication requirements, or return format. It does not contradict any annotations but also adds no meaningful behavioral context beyond the literal action.

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 highly concise, stating the core functionality in a single sentence with no redundant words. However, its brevity comes at the cost of missing crucial usage information, so it is not a perfect score.

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 only one parameter, no output schema, and no annotations, the description should explain parameter meaning and usage context. It only states the return value, leaving the tool's invocation incomplete. Sibling tools suggest a broader ecosystem where README selection is 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?

The single parameter 'spec' has no description in the schema, and the tool description does not explain what it represents. With 0% schema description coverage, the description fails to provide any semantic meaning for the parameter, leaving the user guessing.

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 the README of a dsh-plugin repository, using a specific verb and resource. However, it does not differentiate from sibling tools like dsh_plugin_get or dsh_plugin_inspect, so it falls 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?

No context is provided about when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or why one would choose this over dsh_plugin_get or dsh_plugin_inspect.

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 provided, the description carries the full burden. It transparently states the core behavior: the tool makes a network call to the GitHub topic and overwrites the on-disk cache. This is a destructive (but expected) side effect and is disclosed. It doesn't discuss failure modes, timeouts, or rate limits, but for a simple refresh operation, the disclosure is adequate.

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 front-loads the action ('Force-refresh'), names the resource, and clearly states the side effect. Every word adds value; there is no wasted or redundant phrasing.

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's simplicity (no parameters, no output schema), the description is fully complete. It explains the tool's purpose, the source of data, and the mutation performed. No additional context is necessary for an agent to invoke this 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?

The tool has zero parameters, and the schema is empty (coverage 100%). The description correctly adds no parameter information because there is nothing to add. Per the scoring rule, 0 parameters establishes a baseline of 4.

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 ('force-refresh') and clearly identifies the resource ('GitHub topic:dsh-plugin catalog') plus the action on it ('replace the on-disk cache'). It distinguishes this tool from siblings like dsh_plugin_status or dsh_plugin_list, which are read-only operations, whereas this one mutates the local cache.

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 phrase 'force-refresh' and 'replace the on-disk cache' clearly implies when to use this tool: when the user wants to update the local catalog immediately, bypassing any normal caching. However, it does not explicitly mention alternatives (e.g., waiting for automatic refresh) or when not to use it, so it misses the explicit differentiation that would earn 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 are provided, so the description carries the transparency burden. It discloses that the search operates on the 'cached' catalog, implying a read-only operation that may not reflect the latest live data. However, it does not explicitly confirm no side effects, nor describe return format or pagination behavior, leaving some behavioral aspects implicit.

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 concise sentences, front-loaded with the core action and resource. Every word earns its place, with no filler or repetition of schema details.

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 a simple search, so the description is minimally adequate. It relies on dsh_plugin_list for filter details and does not mention output shape or pagination, which are left implicit. With no output schema and no annotations, a bit more context would be warranted, but it does cover the essentials.

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 low (only 'query' has a description), and the description compensates somewhat by explaining 'free-text query' and referring to dsh_plugin_list for filter semantics. However, limit, language, and minStars are not directly explained, relying on the sibling reference for full understanding.

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 'Search the cached dsh-plugin catalog by free-text query,' providing a specific verb, resource, and query mode. It distinguishes from siblings like dsh_plugin_list and dsh_plugin_get by emphasizing free-text search, and the reference to dsh_plugin_list further clarifies its niche.

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 provides clear context: use this for free-text querying, and the filters are identical to dsh_plugin_list. However, it does not explicitly state when to prefer this over dsh_plugin_list (e.g., broad search vs. browsing), so it lacks explicit exclusions or alternative 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?

The description is minimal and does not disclose whether the tool performs network calls (e.g., checking GitHub auth), is read-only, or may have side effects. With no annotations provided, the description carries the full burden of behavioral disclosure, and it fails to clarify safety or side effects beyond the word 'Report'.

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 and enumerates the key scope. Every word contributes meaning, 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?

For a simple status tool with no output schema or annotations, the description names the covered components but does not explain what 'status' entails, whether results are returned in a structured format, or if any checks could fail or hang. It is adequate for a straightforward status check but leaves some ambiguity regarding output and side effects.

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 is trivially complete (100% coverage). The description adds value by enumerating the five components covered by the status report, which helps the agent understand what the tool reports on even though no parameters exist. Baseline for 0 params is 4.

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 the verb 'Report' and names five specific status categories (GitHub auth, catalog cache, dsh binary, profile, runtime bridge). This differentiates it from sibling tools focused on plugin actions (install, uninstall, search) or runtime control (start, stop).

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 a diagnostic use case (checking the health/status of key components) but provides no explicit guidance on when to use this tool versus alternatives. It does not mention any exclusions or contrast with sibling status-like tools, leaving the decision to the agent.

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 provided, the description carries the full burden of disclosing behavioral traits. It states the action and a required flag, but does not reveal whether the operation is reversible, whether it affects running processes, what output to expect, or any 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?

The description is two short sentences that lead with the primary action and include a critical prerequisite. No unnecessary words.

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 tool with one parameter and no output schema, the description is minimal. It omits any detail about the parameter format, potential errors, or post-removal behavior, leaving the agent underinformed for 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?

The schema has zero description coverage for the single parameter 'packageName,' and the description does not compensate by explaining what the value should be (e.g., plugin ID, package name format, or how it relates to the underlying command).

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 ('Remove') and resource ('plugin from the DSH profile'), clearly distinguishing it from sibling tools like dsh_plugin_install or dsh_plugin_list. The reference to the underlying command adds precision.

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 only usage guidance is the prerequisite 'Requires --allow-install.' There is no mention of when to use this tool versus alternatives (e.g., dsh_plugin_uninstall vs. dsh_plugin_list_installed to check first), nor any exclusion scenarios.

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 clarifies scope (currently bridged) and naming convention, but doesn't explicitly state the return format or that it's a read-only operation. 'List' implies non-mutating, but output structure is not disclosed.

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, front-loaded with the verb and object, with no filler. Every word contributes to clarity.

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 zero-parameter listing tool, this description covers the essential purpose and distinguishing naming convention. It doesn't detail return values, but the tool's simplicity makes this omission acceptable.

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 is empty with zero parameters, so parameter semantics are not applicable. The baseline of 4 is appropriate since no parameter explanation is needed.

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?

Description uses the specific verb 'List', identifies the resource as 'DSH tools currently bridged onto this MCP server', and notes the naming pattern 'dsh__* names'. This clearly distinguishes it from sibling plugin catalog and runtime management tools.

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 for viewing the current runtime bridge state, which is distinct from plugin list/search tools. It doesn't explicitly mention alternatives or exclusions, but 'currently bridged' provides clear situational 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?

With no annotations, the description carries the full burden of disclosure. It does mention the runtime restart, a notable side effect, and the permission requirement. However, it omits details about downtime, persistence, error conditions, 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?

The description is a single concise sentence, front-loaded with the core action. However, it is under-specified in a way that hurts usability, so the brevity is not optimally balanced with necessary information.

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's action (install + restart) and an opaque 'spec' parameter, the description is incomplete. It does not explain the parameter, return behavior, or when to use this over sibling tools, leaving significant gaps for the 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?

The only parameter 'spec' has no schema description and the tool description does not mention it at all, leaving the agent completely uninformed about expected format, values, or purpose.

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 installs an additional plugin into the live profile and restarts the DSH runtime, which gives a specific verb and resource. It somewhat distinguishes from dsh_plugin_install by mentioning the runtime restart, but does not explicitly name sibling tools.

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 over alternatives like dsh_plugin_install or dsh_runtime_unload. The only usage-related note is the prerequisite 'Requires --allow-runtime', which is a constraint but not a contextual recommendation.

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 provided, the description carries the full burden and does well by stating concrete side effects: it installs plugins, spawns a profile process, and bridges tools. It also discloses the required `--allow-runtime` flag, which is a permission-related behavior. The main gap is not mentioning reversibility or what happens to the existing profile state.

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 with no fluff. It front-loads the main action and packs in the prerequisites and bridge behavior efficiently. The phrase 'this MCP bundle' is slightly vague but not wasteful.

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 one optional parameter and no output schema, the description covers the essential operational sequence: install, spawn, bridge, and permission. It does not discuss return values or when to use, but given the moderate complexity and absence of structured schemas, 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?

Schema description coverage is 100%—the plugins parameter is fully described as 'github:owner/repo specs to install before boot'. The description merely refers to 'optional plugins' without adding new meaning, so the baseline 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 lists three distinct actions: installing the MCP bundle and optional plugins, spawning `dsh --profile`, and bridging ctx.tools as dsh__* MCP tools. This is a specific verb+resource combination that differentiates it from sibling tools focused on plugin management or runtime loading.

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 given on when to use this tool versus alternatives like dsh_runtime_load or dsh_plugin_install. The only stated condition is the prerequisite `Requires --allow-runtime`, but there is no mention of when this tool is the appropriate choice or when it should be avoided.

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 discloses the key behavioral consequence of dropping bridged dsh__* tools, which goes beyond the tool name. However, it does not mention reversibility, prerequisites, or the effect of calling when no runtime is active.

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 and includes the most important side effect. Every word adds value, with no redundancy 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?

Given the simplicity of the tool (zero parameters, no output schema), the description sufficiently explains the main behavior. It could mention the return value or behavior when no runtime exists, but for a straightforward stop operation this is likely adequate.

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 defines zero parameters, so there are no parameter semantics to explain. Per the rubric, 0 params results in a baseline of 4. The description correctly omits any parameter details since none exist.

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 action ('Stop the spawned DSH runtime') and the direct effect ('drop bridged dsh__* tools'). It is specific and distinguishes this tool from siblings like dsh_runtime_start and dsh_runtime_unload by indicating it stops and cleans up.

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 use case: stopping a previously spawned runtime. The sibling tool names provide clear context, but there is no explicit when-not-to-use or mention of alternative tools. It gives enough contextual guidance without 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?

With no annotations, the description must carry the disclosure burden. It does disclose the destructive nature (remove and restart) and the --allow-runtime requirement, but it omits other behavioral context such as impact on active sessions, dependencies, or reversibility. The core behavior is transparent, but depth is limited.

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 short sentences, front-loaded with the action, and contains no filler. Every phrase earns its place, 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 tool with one parameter and no output schema, the description is fairly complete. It states the action, the target resource, and a key prerequisite. It could mention failure modes or effects on other packages, but these are not essential given the tool's simplicity.

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 provides only a property name 'packageName' with no description (0% coverage). The description's phrase 'Remove a package' implies that packageName identifies the package to remove, but it does not explicitly map the parameter or clarify format or semantics. The parameter is self-explanatory from context, but the description could add more 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 the tool's purpose: 'Remove a package from the live profile and restart the DSH runtime.' It uses a specific verb ('Remove') and resource ('package from the live profile'), and the restart action distinguishes it from sibling tools like load, start, and stop.

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 a prerequisite ('Requires --allow-runtime') but gives no guidance on when to use this tool versus alternatives such as dsh_runtime_load or dsh_runtime_stop. It does not mention exclusions or scenarios where another tool would be more appropriate.

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