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 does state that commands are executed on the server console, a useful behavioral detail. However, it does not mention potential side effects of commands (e.g., destructive commands like ban/kill), whether it requires specific permissions, or what the tool returns (e.g., command output vs. confirmation). Given the command execution nature and the absence of a safety profile, the description provides only partial transparency, warranting a 3.

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 well-structured, starting with the purpose and examples, followed by an Args section. It is informative without being redundant. The list of command examples is extensive but directly aids comprehension. Each sentence contributes to understanding, and the layout is front-loaded with key information. A small trim of examples could improve conciseness, but it remains efficient.

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 only two parameters and an existing output schema, the description is nearly complete. It explains both parameters with examples and provides usage scenarios. It does not describe the return value, but since an output schema exists, that obligation is satisfied elsewhere. The only minor gap is the lack of explicit caution about potentially harmful commands, but given the simple parameter set and output schema presence, a 4 is justified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It does so thoroughly with an 'Args' section that explains each parameter: instance_name is described as server instance name or UUID with examples, and command is described as a console command without a '/' prefix, with multiple examples. This adds significant semantic meaning beyond the schema's bare titles, clarifying format and usage for both parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: sending console commands to a specified Minecraft server instance. It lists specific command examples (say, list, op, whitelist, give, tp, kick/ban, etc.) and concrete use cases ('send a notice', 'run op Steve', 'add to whitelist'). This distinguishes it from sibling tools that handle instance lifecycle (start/stop/restart) or configuration, making the purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use the tool, giving concrete request examples that map to user intents (e.g., 'send an announcement', 'check online players'). It implicitly differentiates from sibling tools by focusing on console command execution rather than instance management, but it does not explicitly state when NOT to use it or name alternative tools. Thus a score of 4 is appropriate.

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 that API keys and passwords are redacted as '***' — genuinely useful security behavior an agent should know — and the verb '查看' implies a non-mutating read. It doesn't fully cover edge behaviors (e.g., behavior before first load), but for a config getter this is meaningful disclosure.

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 with no redundancy: the content scope is front-loaded, followed by usage intent, with the redaction note appended in a parenthetical. Every clause 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 zero-parameter config getter, the description covers purpose, usage intent, and security disclosure. An output schema is present, so return values need not be explained. Nothing an agent needs to call this correctly is missing.

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 baseline of 4 applies. There is nothing the description needs to explain; schema coverage is trivially complete.

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 and resource — '查看当前 MCP Server 生效的配置' (view the currently effective MCP Server configuration) — and enumerates the contents: panel address, read/write switch, command white/blacklist, transmission method. This cleanly distinguishes it from siblings like mcs_list_instances (lists instances), mcs_instance_status, and mcs_reload_config (applies config).

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 usage context: '用于确认 Server 当前配置状态，或修改 .env 后核对是否生效' (used to confirm the current config state, or verify whether changes take effect after editing .env). This conveys when the tool is appropriate without explicitly naming alternatives or exclusions — a solid context but not full when-not/alternative routing.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clarifies the operation is a query (读取状态) and lists the fields returned, which implicitly indicates a non-destructive read. However, it does not mention required permissions, error behavior (e.g., instance not found), or whether the operation has side effects. While not contradictory, it leaves some behavioral aspects unstated, so a 3 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is crisp and front-loaded: the first sentence states the primary function and details, the second gives typical use cases, and the argument block clarifies the parameter. Every sentence earns its place, and there is no fluff. For a single-parameter tool, this is optimally concise.

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 (one parameter), the presence of an output schema (which reduces the need to describe return values), and the contextual signals, the description covers the essential aspects: what it does, what data it returns, and how to specify the target instance. The only notable gap is the absence of usage exclusions, but that low impact given the tool's nature. Overall it is sufficiently complete 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?

The input schema only provides the parameter name 'instance_name' with no description (0% coverage). The tool description compensates by explaining that the parameter accepts either a display name (昵称) or an instance UUID, with concrete examples ('生存服', 'SMP', '我的世界主服'). This adds substantial semantic value beyond the schema, though it could go further (e.g., mentioning case sensitivity or format validation) — hence a 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 ('查询') with a clear resource ('Minecraft 服务器实例的运行状态与详情') and enumerates the exact details returned (运行状态、在线玩家数、端口、启动命令). It also provides example user questions, making the scope instantly recognizable and clearly distinct from sibling tools like mcs_start_instance or mcs_list_instances.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by giving example questions ('XX服务器状态怎么样', etc.), which signals when an agent should call this tool. However, it does not explicitly mention when not to use it or point to alternative tools for related tasks (e.g., listing instances for discovery, or waiting for status changes). The guidance is implied rather than explicit.

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

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

With no annotations provided, the description carries the burden. It explicitly warns about potential data loss ('可能丢失未保存数据') and indicates the operation is a direct process kill, which is destructive. It also frames the tool as a last resort. While it does not mention permissions, reversibility, or post-kill state, the key risk is disclosed, making this a solid score.

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 concise and well-structured: two sentences front-load the purpose and risk, followed by a separate args note. Every sentence adds value, and the key behavioral warning appears early, making it easy for an agent to parse quickly.

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 only one parameter, the description covers the core usage and risk. An output schema exists (though not shown), so return-value details are not required. The tool's edge-case nature and the mention of when to use it make it sufficiently complete, though it does not address post-kill behavior or whether the instance can be restarted, which would be nice to have.

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 only provides a string type and required flag, with zero description coverage. The description adds meaning by explaining that the parameter accepts either a server instance name or UUID and provides examples like '生存服' and 'SMP'. This compensates well for the schema gap, though it could further clarify how UUIDs are formatted or how names are resolved.

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 force-stops a Minecraft server instance via direct process kill, explicitly differentiating from the normal stop (mcs_stop_instance). It provides concrete example user requests, making its purpose unmistakable.

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 states when to use it: '仅建议在正常停止无效时使用' (only recommended when normal stop is ineffective). This gives a clear condition for use and implies it should not be the first choice. However, it does not explicitly name the alternative tool or state when not to use it beyond that condition, so it is slightly short of perfect 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 burden. It does disclose the return format (structured JSON) but does not explicitly state that the operation is read-only, non-destructive, or detail any side effects. The '列出' verb implies a safe read, but additional behavioral context would improve transparency; a score of 3 reflects adequate but not comprehensive disclosure.

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. The first states functionality and key fields, the second gives use cases and return format. No redundancy, front-loaded action, perfectly sized for the simple 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?

Given the tool's simple nature (no parameters), the presence of an output schema, and the clear description of purpose and return format, nothing critical is missing. The use cases are specified, and the tool's role among siblings is clear enough. The description is fully adequate for an agent to invoke 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?

The tool has zero parameters, and schema coverage is 100% (vacuously true), so the description need not explain parameters. It does mention the output fields, which indirectly aids understanding of the result, but this is output semantics rather than parameter semantics. With a baseline of 4 for zero-parameter tools, this score is justified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb '列出' (list), the resource 'MCSManager面板上的所有Minecraft服务器实例', and the specific fields included (名称、状态、玩家数、端口). It also gives concrete use cases ('有哪些服务器' etc.), effectively distinguishing it from sibling tools that operate on individual instances or perform actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool (answering list/status questions), but does not explicitly exclude alternatives or mention 'use mcs_instance_status for a single instance'. The differentiation is implicit rather than explicit, so a score of 4 is appropriate.

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 bears the full burden of behavioral disclosure. It mentions hot update without restart, the default path behavior when env_file is empty, and re-reading environment variables in pure env mode. However, it does not disclose potential side effects (e.g., whether some settings require a restart, error behavior, or permission requirements). This is a moderate gap for a config-reload tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured. The main purpose is front-loaded in the first sentence, and the parameter documentation follows in a clear 'Args:' section. Every sentence adds value, with no redundant or vague content. The structure makes it easy for an agent to quickly grasp the tool's function and parameter semantics.

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 low complexity (one optional parameter) and an output schema exists, so the description doesn't need to explain return values. It covers the core functionality, parameter behavior, and the no-restart advantage. It could be more complete by mentioning prerequisites (e.g., server running) or edge cases, but given the simple scope, it is largely sufficient 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?

The schema has 0% description coverage, but the description thoroughly explains the only parameter env_file: it is optional, specifies the .env file path, and details what happens when left empty (uses startup path) and in pure environment variable mode (re-reads current env vars). This fully compensates for the schema's lack of description, giving complete semantic clarity.

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: reload configuration (.env file or environment variables) without requiring a server restart. It specifies the verb (reload) and resource (config), and distinguishes from sibling tools like mcs_restart_instance by explicitly noting that no restart is needed. This makes it unambiguous which operation the tool performs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear when-to-use guidance: after modifying .env, call this tool for immediate hot update, and it explains the env_file parameter for switching config files. It implies it's an alternative to restarting, but does not explicitly name sibling tools or state when NOT to use it. This is adequate but could be more explicit about routing from alternatives.

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

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

There are no annotations, so the description carries the full burden. It discloses that the restart is asynchronous and recommends a follow-up call to verify status. However, it does not specify what happens if the instance is already stopped or not running, nor does it mention potential error conditions or side effects. This is a moderate gap given the lack of annotation support.

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 succinct and well-structured: a one-sentence purpose, a note on async behavior with a follow-up, and a brief Args section. Every sentence adds value, and the most important information (purpose, async nature) is front-loaded. No redundant or filler text appears.

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 that the tool has only one parameter and an output schema exists (not shown but implied), the description covers the essential aspects: what it does, how to use it, and how to verify completion. However, it lacks details on edge cases (e.g., if the instance is not running), which could cause an agent to misapply it. It is functional but not exhaustive.

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 type and title, with zero description coverage. The description compensates by explaining that the parameter accepts either an instance name or UUID, and gives examples (生存服, SMP). This meaningfully expands on the bare schema definition, though it could also note that it is required (already in the schema) or provide format constraints.

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 (重启/restart) and the resource (Minecraft server instance). It uses a specific verb and distills the purpose into a single sentence. It also distinguishes itself from siblings by focusing on restart as opposed to start/stop/kill, making its role among them 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 provides explicit example usage scenarios (e.g., '重启一下XX服', 'XX服务器卡了') and a clear post-action instruction to call mcs_wait_for_status to confirm completion. While it doesn't explicitly say when NOT to use it (e.g., for starting a stopped instance), the examples and the sibling context make the intended usage clear enough.

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 fully carries the behavioral disclosure. It clearly states that the start operation runs asynchronously in the MCS backend, the command returns immediately, and to confirm completion one must call mcs_wait_for_status. This is critical behavioral information that the agent needs to know to avoid assuming the server is ready. No contradictions.

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 well-structured with a clear main sentence, an async behavior note, usage examples, and an Args section. It is slightly longer than absolutely necessary, but every sentence adds value. The front-loading is good: the core action and async behavior come first. A minor deduction for minor redundancy (the usage examples could be considered extra but they help parsing).

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 that the tool has one parameter, an output schema exists (though not detailed in the prompt), and the description covers purpose, usage, async behavior, and parameter semantics, it is complete. An agent can correctly invoke this tool and know how to verify success. No critical gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description must compensate. It does so excellently: it defines instance_name as the server instance name (as configured in MCSManager) or instance UUID, and provides concrete examples like '生存服', 'SMP', '我的世界主服'. This gives the agent clear understanding of what to pass.

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: to start a specified Minecraft server instance. It uses a specific verb ('启动' = start) and a specific resource (server instance), and it distinguishes itself from sibling tools like stop/restart/kill by specifying the action of starting. It even gives example usages ('启动XX服务器'), making the intent unmistakable.

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 explicitly says when to use this tool: for requests like '启动XX服务器' (start XX server) or '把XX服开起来' (bring up XX server). It also provides guidance on how to confirm completion by calling mcs_wait_for_status with 'running' status, which is a clear follow-up instruction. It does not mention exclusions, but the context is clear and sufficient.

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?

无注解，描述承担了行为披露责任。它说明了后台异步执行、安全存档、以及通过mcs_wait_for_status确认完成的行为，这些都是关键透明信息。但未提及权限要求或错误处理，考虑到工具简单，披露已较充分。

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?

描述结构清晰：第一段说明功能与行为，第二段解释参数。信息密度高，没有冗余词句，每个句子都有价值。

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?

对于只有一个参数的简单工具，描述涵盖了用途、使用场景、参数解释和异步确认行为。存在输出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覆盖率0%，但描述在Args部分明确说明了instance_name的含义（实例名称或UUID）并给出示例（如'生存服'），完全补偿了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?

描述明确说明了动词（停止）、资源（Minecraft服务器实例）以及具体动作（发送停止指令、安全存档）。与兄弟工具如mcs_kill_instance（强制停止）区分开来，突出'正常停止'，目的清晰且独特。

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?

描述说明了典型使用场景（'关掉XX服'等请求），并指出异步执行及如何确认完成（配合mcs_wait_for_status）。虽未明确说明何时不使用（如强制停止场景），但通过'正常停止'隐含了与kill的区别，整体指引清晰。

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 behavioral disclosure. It discloses the polling interval (every 5 seconds), timeout behavior, and return values (reached=true on success, reached=false with current status on timeout). This transparently conveys the blocking nature and outputs. It does not mention potential errors or side effects, but as a wait tool, these are less critical.

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 well-structured: a concise summary sentence followed by a clear argument list. The polling interval and purpose are front-loaded. It is slightly verbose in the summary (mentions replacing push notifications, which is useful context but not strictly necessary), but overall efficient and easy to scan.

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 an output schema (per context signals) and the description explains the return behavior (reached true/false and current status on timeout). It covers the essential context: purpose, all parameters, polling behavior, and outcomes. Nothing critical for correct invocation is missing; it does not describe error handling, but for a wait tool this is 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?

Schema coverage is 0%, so the description must fully explain each parameter. It does so comprehensively: instance_name (server instance name or UUID), target_status (accepts 'running'/'stopped' or Chinese '运行中'/'已停止'), and timeout_seconds (default 300, range 5-1800). This provides meaning far beyond the bare schema, compensating completely for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool waits for a server instance to reach a target status via polling, and explicitly ties it to confirming completion after start/stop/restart. This distinguishes it from sibling tools like mcs_instance_status (which likely just reads current status) and the mutation tools (start/stop/restart). The purpose is specific and 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?

It explicitly says to use this after start/stop/restart to confirm operation completion, and mentions it replaces the old 'background push notification' capability, giving clear usage context. However, it does not explicitly state when NOT to use it (e.g., for a one-off status check, use mcs_instance_status instead). The absence of an exclusion leaves some ambiguity but the primary use case is clear.

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