mcp

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

Annotations already indicate a non-read, non-destructive, non-idempotent operation. The description adds valuable context: the backup is off-site, triggers immediately, and replicates a known UI action. This supplements the annotations without contradicting them, though it does not disclose potential caveats like concurrent backup 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?

The description is a single, focused sentence that immediately conveys the action and purpose. It uses the panel button analogy to add clarity without unnecessary length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool with an output schema and clear annotations, the description gives sufficient information for an agent to select and invoke it correctly. The 'same as panel button' analogy provides practical context, making it complete for this tool's complexity.

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

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

The schema fully documents the single 'server' parameter with a clear description ('The server id (server_...) from list_servers'), providing 100% coverage. The description adds no parameter details, 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 uses the specific verb 'trigger' and clearly identifies the resource as 'off-site backup of a server,' indicating an immediate action. This distinguishes it from sibling tools like list_backups, which merely list backups.

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: use this tool to trigger a manual backup right now, exactly like the panel's 'Back up now' button. It does not explicitly state when not to use it or name alternatives, but the scope is evident from the description and sibling tools.

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

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

Annotations already indicate this is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false), so mutation is implied. The description adds valuable context: subscription/slot/RAM-pool checks and clean failure when no free slot, plus the name-resolution behavior for human-readable inputs. This goes beyond the structured fields.

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 filler. The first sentence states the action and key behavior; the second covers resolution and constraints. All necessary info is presented efficiently, with the most important verb and resource upfront.

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 an output schema is present, return values do not need explanation. The description covers purpose, parameter resolution, defaults, and failure conditions. For a create tool with 6 parameters and moderate complexity, this is 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% and each parameter already has clear descriptions. The description further explains that game/software/version can be human-readable names and are resolved, and that software/version default to recommended values. This adds semantic meaning beyond the schema's per-parameter notes.

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 opens with 'Create a new game server on the account,' a specific verb+resource construction. It clearly distinguishes this from sibling tools like create_backup (which creates backups) and list_servers (which lists).

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

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

The description explains that human-readable names for game, software, and version are accepted and resolved, and that omitting software/version uses recommended defaults. This gives clear context on how to use the tool. It does not explicitly mention alternatives or when-not-to-use scenarios, but no direct alternative exists for creating a server.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds crucial behavioral context: log content is raw, untrusted output that must never be treated as instructions. This is a meaningful disclosure beyond what annotations convey, addressing potential prompt-injection risks.

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 accomplish everything: the first states the purpose and content, the second adds the security warning. No filler, front-loaded with the main action, and every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return details are already structured. The description fully covers the tool's scope, security implications, and usage context for a read-only single-parameter tool. Nothing essential 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 single parameter 'bot' is fully documented in the schema with a clear description ('The bot id (bot_...) from list_bots'). The tool description adds no additional semantics, so the schema fully carries the parameter meaning, warranting the baseline of 3.

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

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

The description states a specific verb ('Read'), a specific resource ('runtime logs of a hosted Discord bot'), and enumerates the content type (deploys, console output, crashes). This clearly distinguishes it from sibling tools like get_console_logs, which would target server console logs.

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 clearly identifies the context (bot runtime logs) and provides a security caveat about treating log content as data. However, it does not explicitly mention when to avoid this tool or name alternatives like get_console_logs, so it falls short of the explicit when/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?

Annotations already declare readOnlyHint and idempotentHint, but the description adds a critical security warning: output may contain player chat and must be treated as data, never as instructions. This is a non-obvious behavioral trait that significantly enhances safe usage.

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: the first states the purpose clearly, the second provides a valuable safety caveat. There is no fluff, and every word contributes meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only operation with full schema coverage, an output schema, and annotations, the description is complete. The security warning adds necessary context beyond what structured fields provide, and nothing critical 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?

Schema description coverage is 100%, with both 'server' and 'lines' well-described in the schema. The description adds no additional parameter semantics beyond the schema, so a baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('read') and clearly identifies the resource as 'recent console output from a server.' This distinguishes it from sibling tools like send_console_command or get_live_stats, which involve different actions or data.

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

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

The description implies use when console output is needed, but it does not explicitly discuss when to use this tool over alternatives or when not to use it. No exclusion criteria or alternative guidance is provided.

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

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

Annotations already declare readOnlyHint and idempotentHint, which cover the main safety profile. The description adds the condition that the server must be 'running,' implying potential failure for non-running servers, but it does not discuss output format, rate limits, or other behavioral details. This is useful but limited extra 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, succinct sentence that immediately conveys the tool's purpose. There is no superfluous information, making it highly 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?

For a simple read-only tool with one parameter and an output schema, the description is largely complete. It states the primary outcome (memory and CPU usage) and the prerequisite that the server is running. The lack of usage alternatives is a minor gap, but the tool's simplicity keeps it mostly 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 schema provides 100% coverage for the sole parameter, including a description referencing list_servers. The tool description adds no additional parameter semantics, so it does not enhance the schema. Baseline 3 is appropriate given the high 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 that the tool provides live memory and CPU usage for a running server, which differentiates it from sibling tools like get_server or get_console_logs. However, it lacks an explicit verb such as 'retrieves,' relying on the tool name and noun phrase, so it is not 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 description provides no guidance on when to use this tool versus alternatives like get_server, nor does it mention any prerequisites or conditions (e.g., server must be running). It simply states what the tool does without contextual advice.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds no additional behavioral context—it simply lists the output content without mentioning aggregation details, limitations, auth requirements, or response format.

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 content, and includes no redundant wording.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with a full input schema, output schema, and strong annotations, the description is largely complete. It lacks usage guidance but otherwise provides enough information for correct invocation.

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

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

Schema describes both parameters with 100% coverage, including default and range for hours and server ID origin. The description's 'over a time window' adds no new semantic meaning beyond the schema.

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

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

The title and name explicitly request get_player_activity, and the description specifies the exact data returned (join/leave/chat counts and recent players) over a time window. This clearly distinguishes it from siblings like get_live_stats (real-time stats) and get_console_logs (logs).

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 such as get_live_stats or get_console_logs. It only describes what it returns, leaving the agent to infer the appropriate use case.

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

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

Annotations already declare read-only, idempotent behavior. The description adds value by detailing the exact types of information returned (status, software, RAM/disk, etc.), which goes beyond the annotations. It avoids overstating side effects and is consistent with the annotated safety profile.

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 front-loads the tool's purpose ('Full overview') and then enumerates the included data points. Every word contributes to understanding the tool's scope, with no wasted or redundant content.

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 relatively simple input (one server id) and the presence of an output schema, the description sufficiently communicates the tool's coverage. It mentions all key aspects a user would expect from a server overview, and the output schema handles return-value details.

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 parameter description is clear: server id from list_servers. The description adds no additional parameter-level detail beyond the schema, which is appropriate given the schema already fully documents the parameter.

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

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

The description clearly identifies the tool as returning a comprehensive overview of one specific server, listing concrete content like status, software/version, RAM/disk usage, settings, ports, node type, and crash diagnosis. It distinguishes itself from siblings such as get_live_stats and get_console_logs by emphasizing the 'full' scope of information.

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

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

The description implies usage for retrieving a complete server overview, but it does not explicitly state when to use this tool over alternatives like get_live_stats or list_servers. No direct exclusions or alternative references are provided, leaving usage guidance implicit.

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

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

Annotations already declare readOnlyHint and idempotentHint. The description adds the significant operational note that it is safe to run while the server is live, which goes beyond the structured annotations and helps an agent avoid unnecessary downtime.

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, no filler. The first sentence front-loads the four concrete output categories, and the second delivers a compact safety assurance. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, a single fully-described parameter, and annotations covering safety and idempotency, the description covers the tool's purpose, key outputs, usage context, and safety in a compact form. Nothing essential for selecting the tool 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?

Schema coverage is 100%: the only parameter, server, is fully documented as the server id from list_servers. The description adds no extra parameter-level detail, so the baseline 3 applies.

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

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

The description names a specific action—'Analyze a Minecraft Java world'—and enumerates concrete outputs: chunk count, disk usage, unvisited area, and prune savings per threshold. This clearly distinguishes it from siblings like get_player_activity and prune_world.

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 conveys when it is appropriate to call by stating it is 'Safe while the server runs' and by framing the tool as a pruning planning aid. It does not explicitly name alternatives or exclusions, but the context is clear.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds that the listing includes id, time, and size, but does not disclose other behavioral details like pagination or ordering, which is acceptable given the annotations.

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

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

The description is a single, front-loaded sentence that conveys the essential information without waste. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool with a full output schema and clear annotations, the description is sufficiently complete. It covers what the tool does, the scope (off-site, per server), and the returned fields, with no need for additional context.

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% for the single parameter 'server', so the schema fully documents it. The description does not add extra semantic meaning beyond the schema, warranting the baseline score.

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

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

The description clearly identifies the action ('List') and the resource ('off-site backup snapshots of a server'), with explicit fields returned. It distinguishes itself from siblings like create_backup and list_servers by focusing on backup snapshots.

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

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

No guidance is provided on when to use this tool versus alternatives, nor are any exclusions or prerequisites mentioned. The description simply states what it does without 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?

Annotations declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the read-only nature is already covered. The description adds transparency by specifying what data is returned (fields) and how the output should be used (ids for other tools), which is consistent with the annotations. No behavior contradicts the annotated safety profile; the description enriches the agent's understanding of expected outputs without needing to restate the read-only hint.

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 and resource, lists the key output fields, and ends with a practical usage note. Every word earns its place; there is no redundancy or filler. The structure is highly scannable for an agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters, has an output schema (as indicated), and the description covers the returned fields and how to use them, nothing essential is missing. It also distinguishes itself from other list tools by specifying 'Discord bots', avoiding confusion with siblings. The description is complete for an agent to call the tool correctly and interpret its output.

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 (schema is empty), so there is nothing to explain. The description correctly omits parameter details, and the baseline for 0 parameters is 4. The description adds value by explaining the output fields, but since there are no inputs, this dimension is inherently satisfied.

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

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

The description clearly states the verb 'List' and the resource 'hosted Discord bots on this account', and enumerates the exact fields returned (id, name, status, runtime, GitHub repo). It differentiates from sibling list tools (e.g., list_servers, list_vps) by being bot-specific, and even specifies the id prefix format (bot_...). This leaves no ambiguity about what the tool does.

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 instructs to use the id with get_bot_logs and power_bot, providing clear context for when this tool is needed (to obtain ids for downstream operations). While it doesn't explicitly state when not to use it, the mention of the dependent siblings and the specificity of the resource imply a clear usage scenario. Omission of explicit exclusions is a minor gap.

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

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

Annotations already declare readOnlyHint and idempotentHint, establishing a safe read-only operation. The description adds meaningful context by specifying the 'jailed' file system boundary and the root path convention, going beyond the structured annotations without contradicting them.

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 that conveys purpose, scope, and usage flow. No word is wasted, and critical information is front-loaded.

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 list operation, strong annotations, and existing output schema, the description covers all necessary context: what it does, the jailed scope, root usage, and how it connects to other tools. Nothing essential 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?

Schema description coverage is 100%, with both path and server already documented. The description adds only a minor detail (using '/' for root) that is also present in the schema. Baseline of 3 applies since the schema handles parameter explanations adequately.

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 (list a directory), the resource (server file system), and the scope (jailed to that server). It distinguishes itself from related tools by mentioning read_file/write_file for subsequent operations, making the purpose unambiguous even among 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 provides clear context by explaining the root path convention and how to proceed with read_file/write_file. While it doesn't explicitly list alternatives or exclusions, the workflow is explicit and the tool's role among file management siblings is evident.

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

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

Annotations already declare read-only and idempotent hints. The description adds useful context about scope (own plus team-shared) and the authentication requirement, going beyond what annotations alone provide.

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 concise sentences that are front-loaded with the essential action and include only high-value details about output and usage. No wasted 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?

With no parameters, an output schema, and a clear description covering purpose, scope, and usage, the tool is fully contextualized for an agent. The description is complete for this simple tool.

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?

No parameters exist, so the baseline is 4. The description does not need to explain parameters and correctly mentions the authenticated account context in prose.

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 lists game servers the authenticated account can manage, with a specific verb and resource. It also differentiates itself from siblings by positioning it as the discovery tool for server IDs.

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 instructs 'Call this first to discover server ids for the other tools,' which tells the agent exactly when to use this tool and hints at alternatives. This is strong usage guidance.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the description's job is lighter. It adds the returned fields and the typical use case (discovering VPS IDs), which is useful context beyond the structured data.

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 concise sentences with no redundant information. The verb and resource are front-loaded, and every word adds value.

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, read-only list operation with an output schema and good annotations, this description is fully sufficient. It says what it lists, why to call it, and what to do with the output.

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

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

With zero parameters, the baseline is 4. The description adds context about what the output is used for (discovering VPS IDs for power_vps), which helps agents interpret the result even though there are no input params.

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

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

The description clearly states it lists the account's managed VPS instances with specific fields (id, plan, specs, status, region, SSH host). It distinguishes from sibling list_servers by focusing on VPS instances and mentions the specific use case for power_vps.

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 says 'Call this first to discover vps ids for power_vps', providing a clear when-to-use. It does not enumerate alternatives or when-not-to-use, but the context around VPS instances is sufficient for an agent to select this tool.

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

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

The description adds valuable nuance beyond annotations: it clarifies that restart does not redeploy but relaunches the current build, and explicitly lists exclusions (env vars, deletion). These align with the idempotentHint and destructiveHint annotations, providing context without contradicting 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?

Two sentences, with the core purpose stated first and a single clarifier about restart and exclusions. No unnecessary words or redundancy, making it efficient and scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has a simple lifecycle with two well-documented parameters and an output schema (not shown but present). The description covers operation scope, restart semantics, and exclusions, which is sufficient for an agent to call it correctly. Minor gaps like permission requirements exist but are not critical for this tool.

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?

Both parameters are fully documented in the schema: 'bot' includes the source ('from list_bots') and 'action' is an enum with a description. The description reiterates the actions but does not add new semantic detail beyond what the schema already provides, so it meets the baseline for 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 explicitly states 'Start, stop or restart a hosted Discord bot,' which is a clear verb+resource combination. It distinguishes this from server or VPS tools in the sibling list by specifying 'Discord bot,' making it unambiguous which resource it operates on.

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 guidance on what the tool does not cover ('environment variables and deletion are intentionally not exposed here, direct the user to the panel for those'), which helps the agent know when NOT to use it. However, it does not explicitly name alternative tools for those operations (e.g., panel or other APIs), relying on the agent to infer from 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?

Annotations already mark this as non-read-only, idempotent, and non-destructive. The description adds valuable behavioral context beyond annotations: shutdown stops everything running on the machine including game servers but keeps all data. It also explicitly states the deletion operation is not exposed, which is a useful safety 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 sentences, front-loaded with the core purpose, and every clause earns its place. It efficiently conveys the action, a key behavioral consequence, and an important exclusion without any fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple and the description covers the essential aspects: the power actions, what happens on shutdown, data preservation, and the deliberate omission of deletion. An output schema exists, so returning details are not needed. The description is complete for an 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?

Schema coverage is 100%: both 'vps' and 'action' have descriptions, with 'action' listing the enum values. The description adds some nuance about the effects of shutdown, but this is more behavioral than parameter-specific. It does not add meaning beyond the schema descriptions, so the baseline of 3 applies.

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

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

The description starts with specific verbs 'Start, shut down or reboot' and a specific resource 'managed VPS', immediately conveying the tool's scope. It further distinguishes from sibling tools by noting that shutdown affects game servers on the game node, clarifying it operates at the VPS level rather than the game-server level.

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 (managing VPS power state) and an explicit exclusion ('deleting a VPS is intentionally not exposed here — direct the user to the panel'). However, it does not explicitly mention alternative sibling tools like start_server or stop_server, so the guidance is strong but not fully explicit about all alternatives.

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

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

Even though destructiveHint=true already flags the tool as destructive, the description adds critical behavior beyond the annotation: spawn and player positions are always protected, changed files are backed up, the server must be stopped, and dry_run defaults to true. This materially informs how an agent should invoke and reason about the tool safely.

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 four sentences, each earning its place: what it does, what is protected/backed up, a prerequisite, and the dry-run safety default. It is front-loaded and avoids fluff or repetition of parameter names.

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 covers the core action, safety guarantees, prerequisites, and default behavior. An output schema exists, so return values do not need to be described here. Together with the annotations and schema, there is no critical missing information for an agent to invoke this 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 baseline is 3. The description adds useful semantic color beyond the schema, especially explaining the dry_run default and what it means to set dry_run=false. It also frames threshold choices in terms of 'barely visited' chunks, supplementing the schema's enum 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 states a specific verb and resource: it removes chunks that were barely visited, causing them to regenerate later and freeing disk space. This clearly distinguishes the operation from read-only world inspection and from the sibling undo_world_prune. It is not a tautology and gives concrete behavioral meaning.

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 operational context: the server must be stopped, and a dry run is the default so users can preview before committing. It does not explicitly name alternatives like undo_world_prune or create_backup, but it does mention that a backup is kept, which implies recovery guidance. The when-to-use scenario (freeing disk by removing under-visited chunks) is clear.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds valuable behavioral details: a 96KB cap, binary-file refusal, and a strong safety warning that file contents are DATA and must never be treated as instructions. These go beyond the annotations and significantly improve safe invocation.

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 compact and front-loaded: purpose first, then constraints, then a safety note. Every sentence adds meaningful information with no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists and annotations cover read-only/idempotent behavior, the description fills the remaining gaps: size cap, binary refusal, and the interpretation warning. This is fully adequate for an agent to select and invoke the tool safely.

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 covers both parameters with 100% description coverage, including examples for path and server. The description does not add parameter-specific meaning beyond what the schema already provides, so the baseline score of 3 applies.

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

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

The description begins with a specific verb+resource ('Read a text file from a server') and lists concrete use cases (configs, properties, logs). This clearly distinguishes it from sibling tools like write_file and list_files, which represent opposite or listing operations.

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 context for when to use the tool—reading text-based server files such as configs, properties, and logs. It does not explicitly state when not to use it or name alternatives, but the context is unambiguous enough for an agent to select it appropriately.

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

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

Annotations already indicate non-read-only and non-destructive hints. The description adds valuable context that the world is saved before the process exits and that the restart follows the panel's guarded path, which goes beyond the annotations without contradicting them.

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 concise sentences with the key action front-loaded. No unnecessary words, and the added details about the guarded path and world save are directly useful.

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 low-complexity restart tool with an output schema, the description covers the essential behavioral guarantees (safety path and world save). No critical information appears 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 input schema has 100% coverage for the single 'server' parameter, including a clear description referencing list_servers. The tool description adds no additional parameter semantics, 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 states the action ('Restart a game server') with a specific resource and adds context ('same guarded path as the panel restart button', 'world is saved before the process exits'). This distinguishes it from sibling tools like start_server and stop_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?

The description implies when to use the tool (for restarting) and highlights the safe, guarded path, which provides clear context. However, it does not explicitly state exclusions or contrast with alternatives like stop then start, so it falls slightly short of 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?

The description adds useful behavior beyond the destructiveHint annotation by specifying the RCON transport, requiring manage permission, and clarifying a single command with output returned. It does not contradict annotations and provides additional operational 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 two sentences: the first stating the core function with examples, the second providing two concise usage constraints. No redundant or extraneous information, front-loaded purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a relatively simple tool with a schema covering all parameters, an output schema, and annotations indicating destructive behavior, the description adequately covers purpose, usage constraints, permission requirements, and output. It doesn't need to detail return formats since an output schema exists.

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 already provides 100% coverage for both parameters, including examples and the 'without a leading slash' instruction. The description repeats this guidance and adds a few extra command examples, but does not introduce significant new meaning beyond the schema.

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

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

The description uses an active verb 'Run' with a specific resource 'single console command on a running Minecraft server over RCON', includes concrete examples, and clearly distinguishes it from sibling tools like start/stop/restart which manage server lifecycle.

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 that the tool executes arbitrary console commands on a running server, and gives explicit usage constraints: 'Do not prefix with a slash' and 'Requires manage permission.' However, it does not explicitly state when not to use it (e.g., for restarting/stopping the server), so it lacks explicit exclusions.

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

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

Beyond the annotations (idempotent, non-destructive), the description adds meaningful behavioral context by stating that the operation is subject to subscription, RAM-pool, and disk-quota checks. This helps the agent anticipate potential failures and understand constraints, going above the structured data.

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 core action, and every word earns its place. It avoids redundancy and keeps the tool purpose immediately visible.

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, existing output schema, and helpful annotations, the description provides sufficient context: what it does, when to use it, and key constraints. No critical information appears missing for agent selection and 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 provides 100% coverage of the single parameter, including its type and source (list_servers). The description adds no extra parameter-level meaning, so the baseline of 3 is appropriate since the schema fully documents the parameter.

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 ('Start') and resource ('game server') and explicitly scopes to 'stopped' servers, clearly distinguishing it from restart_server and stop_server. It also adds context about the checks performed, 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 clearly indicates the tool is for starting a stopped server, giving strong context for when it is appropriate. However, it does not explicitly exclude already-running servers or mention alternatives like restart_server, so it lacks explicit when-not/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?

Annotations already indicate idempotentHint=true and destructiveHint=false, and the description adds a key behavioral detail: 'The world is saved before the process exits.' This provides extra transparency beyond the structured hints and aligns with the annotations, showing why the operation is non-destructive.

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 concise sentences with zero waste. The first states the action and context, the second adds a critical safety detail. Front-loaded and perfectly sized.

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 one-parameter schema, clear annotations, and presence of an output schema, the description is complete. It covers the essential behavioral aspects (guarded path, world save) and requires no further explanation for effective use.

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

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

The input schema has 100% coverage for its single parameter, including a clear description ('server id (server_...) from list_servers'). The tool description does not elaborate on the parameter, but the schema fully compensates, so the 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?

The description uses a specific verb ('Stop') and resource ('game server'), clearly distinguishing it from sibling tools like start_server, restart_server, and send_console_command. The phrase 'through the same guarded path as the panel stop button' adds meaningful context about the operation's nature.

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 this is the safe, intended way to stop a server (via the guarded path), as opposed to using a console command. It gives clear context for when to use this tool, though it doesn't explicitly name an alternative to avoid or list exclusions.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation risk is known. The description adds useful context beyond annotations: the node keeps backups and the server must be stopped. This provides operational context without contradicting the annotations. Not full score because it doesn't detail side effects like overwriting current files, though the destructive hint covers that.

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

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

Two sentences with no filler. The core action comes first, then the essential precondition. Every word contributes meaning, and it is 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?

For a single-parameter tool with an output schema, rich annotations, and a clear precondition, the description is complete. It covers what, why, and when, and there is no missing information an agent would need 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?

Schema description coverage is 100%, with the single 'server' parameter fully explained as a server id from list_servers. The description adds no additional parameter-level semantics, so a 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?

The description clearly states a specific verb ('put back') and resource ('world files from before the most recent prune'), distinguishing it from the sibling prune_world. It also explains the backup mechanism, leaving no ambiguity about what operation is performed.

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 states a critical precondition: 'The server must be stopped.' This tells the agent when the tool is usable. It does not name alternatives explicitly, but the context of pruning/restoring makes the intended use clear enough, and the exclusion of running servers is direct.

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?

Beyond annotations (destructiveHint, idempotentHint), the description discloses additional traits: 'Overwrites without backup', 'Most config changes need a server restart', and 'Capped at 192KB'. These add valuable context for safe usage and are not present in the annotations.

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

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

The description is three concise sentences. The first states purpose, the second provides a critical safety warning, and the third adds side-effect and limitation. Each sentence earns its place with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the existence of an output schema and detailed annotations, the description covers all essential aspects: purpose, destructive behavior with no backup, precondition (read first), postcondition (restart), and a size limit. It is complete for safe invocation.

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

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

Schema coverage is 100%, so baseline is 3. The description adds useful context beyond the schema: examples of file types (configs, properties, scripts) align with the path examples, and the 192KB cap is important for the content parameter but not listed in the schema.

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

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

The description clearly states the action ('Write (create or overwrite) a text file') and the resource ('on a server'), with relevant examples (configs, properties, scripts). It implicitly distinguishes itself from sibling tools like read_file and list_files by focusing on writing.

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 clear directive: 'so read_file first when editing' and warns that config changes need a restart. This gives explicit when-to-use guidance and references an alternative tool, though it doesn't enumerate all possible alternatives.

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