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 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=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 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 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.