minecraft-paper-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools map to distinct resource/action pairs (process, player, whitelist, gamerule, logs). rcon_command is a catch-all that could overlap with dedicated commands, but the description explicitly directs agents to dedicated tools, so confusion is limited.
Naming Consistency3/5
Naming mixes noun_verb (server_start, player_kick, whitelist_add, logs_tail) with verb_noun (give_item, set_time, teleport_player) and noun_noun (rcon_command, server_status, players_list). All names are snake_case and readable, but there is no consistent pattern.
Tool Count2/5
28 tools is above the 25+ threshold and feels heavy for a single server admin surface. Many tools are narrowly scoped (e.g., separate set_gamerule, set_weather, set_time), though each has a clear purpose.
Completeness4/5
The surface covers process lifecycle, player moderation, ops/whitelist, world settings, and logs. Obvious gaps include IP ban/unban actions (only banned_ips_list exists) and no save/backup operation, but core workflows are covered.
Average 3.4/5 across 27 of 28 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely states 'set' without elaborating on effects (e.g., immediate vs persistent change), any prerequisites, side effects, or whether the server must be running. This is a severe gap for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but it is under-specified. It is front-loaded with the action, but lacking necessary detail for an agent to use it effectively, so the size is not appropriate for the complexity of the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with zero annotations und an empty output schema, the description burdens the agent with all context. It fails to state what rules are available, what value formats are accepted (e.g., booleans, numbers), prerequisites like a running server, or side effects. This is severely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description provides zero explanation of what 'rule' or 'value' should contain. The agent gets no information about valid rule names or value formats, so it would have to guess or rely on external knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: setting a gamerule on the server. However, it doesn't differentiate from siblings like server_properties_set, which also modifies server settings, though gamerule is a distinct concept. The verb and resource are specific enough to convey the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It doesn't mention what gamerules are applicable, whether the server needs to be running, or any exclusions. The user must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral disclosure. It simply states the action 'ban' without explaining permanence, effect on player connection, whether the reason appears in the ban list, or reversibility. For a mutating tool this is a significant omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, very concise. But it's so short that it doesn't carry useful context – brevity without substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No annotations, no output schema, and the description doesn't explain effects (permanent, revocable via player_pardon), reason optionality, or relation to siblings like player_kick. For a mutation tool with a cleanup sibling, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not explain what 'player' means (username, UUID, name pattern?) nor what 'reason' does (displayed to player? logged?). The description adds no meaning beyond the property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb (Ban) and resource (a player), and states the scope ('from the server'). It distinguishes from player_kick by implying permanence, though it doesn't explicitly contrast with the sibling kick tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance or exclusions. It doesn't mention when to use ban vs kick, nor that it can be reversed with player_pardon. An agent must infer the difference from the sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it only says 'Kick a player from the server.' It fails to disclose that the kick is reversible (the player can reconnect), whether server operator privileges are required, whether the server must be running, or what effect it has on the player's active session. For a mutating server-management action with zero annotation coverage, this is a meaningful transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is a single short sentence with no wasted words and the core verb is front-loaded. The structure itself is efficient; the weakness lies in under-specification rather than excessive or disorganized prose, so conciseness is decent even though content is thin.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with no output schema and no annotations, the description should supply substantially more. It omits whether the server must be active, the temporary nature of the action, and the role of the reason parameter. An agent has just enough to guess the operation but not enough to call it confidently in varied server states.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the parameters, but it adds nothing about 'player' or 'reason.' The names are mildly self-evident, yet the description provides no clarification of what 'player' accepts (username or UUID) or how 'reason' is surfaced to the kicked player. Since it adds no meaning beyond the bare schema properties, this dimension is poorly served.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (kick) applied to a resource (player on the server), giving a clear sense of what the tool does. However, it doesn't differentiate from the closely related sibling player_ban — both remove a player, and there's no mention that kick is temporary while ban is persistent. The name and description together make the core action clear, but sibling disambiguation is left entirely to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. Siblings like player_ban and player_pardon exist, but the description never explains that kick is transient (player may rejoin) or that ban is the persistent removal option. There's also no mention of prerequisites, such as the server being online or operator permissions being required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'Add a player to the whitelist.' It doesn't disclose whether the whitelist must be enabled, whether the operation is idempotent, if it overrides existing entries, or any error conditions (e.g., player already whitelisted). The description carries the full burden of behavioral transparency and fails to provide it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one sentence with no fluff. It's front-loaded with the action. However, the conciseness comes at the cost of necessary details, but structurally it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and a simple action, the description is minimal. But given the lack of annotations and output schema, and the presence of many sibling tools, a better description would have specified prerequisites (e.g., whitelist must be enabled), the format of the player parameter, and the expected result. It is inadequate for an agent to call this confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage (0%) for the 'player' parameter. The description adds no meaning beyond the parameter name itself. It doesn't clarify format (username? UUID?), whether it's case-sensitive, or any constraints (e.g., must be a valid player). This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Add' and the specific resource 'a player to the whitelist'. It distinguishes itself from sibling tools like whitelist_remove and whitelist_list (which show context). However, it doesn't specify which server or game the whitelist pertains to, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. For instance, it doesn't mention whether the player must be online, if they should be added before they join, or that it operates on a specific server. It doesn't reference sibling tools like whitelist_remove or whitelist_list for context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It says 'search' but does not disclose whether this is a read-only operation, performance implications, output format, or any limits beyond maxMatches. It doesn't state what happens if no matches are found or whether it scans the entire file.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that conveys the core purpose without waste. It could be more specific but is appropriately brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, and the description doesn't mention what the tool returns (matching lines? count?), whether it's a read-only operation, or any performance considerations. For a log search tool, the agent needs to know the expected output format. The lack of behavior disclosure beyond 'search' leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the 'pattern' parameter with a description, but 'maxMatches' is undocumented in schema. The description doesn't explain that pattern is a regex (it repeats the schema) or clarify maxMatches semantics (e.g., maximum number of lines to return). Schema coverage is only 50%, so description should compensate but doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('search') and resource ('logs/latest.log') and specifies that it matches lines by regex pattern. It distinguishes from sibling tools like logs_tail by focusing on regex search, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like logs_tail or server_status. It doesn't state any exclusions or prerequisites, leaving the agent to infer from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects了好久. However, the description only states the action with no mention of mutability, permission requirements, reversibility, or effect on player state. It does not clarify whether the item appears in inventory, whether it replaces existing items, or if any feedback is returned. This is a meaningful gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that communicates the core action without any fluff. It is optimally front-loaded and wastes no words. For a simple tool, this is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, no parameter descriptions for player and amount, and no hints about default values or restrictions, the description is insufficient for an agent to fully understand invocation semantics. It does not note that 'amount' is optional, what happens with invalid items, or how player is identified (username vs UUID). The tool is simple, but the description fails to provide the necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'item' has a description). The description does not clarify the 'amount' or 'player' parameters beyond the schema. It does implicitly link
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Give an item to a player' clearly states the action (give) and the target (an item to a player), and it is distinct from all sibling tools which handle server control, player management, or teleportation. It is clear but does not explicitly distinguish itself by naming any alternative; however, the verb+resource is unambiguous among the siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 others wire. It does not mention any prerequisites (e.g., player online, permission level) or situations where an alternative like rcon_command might be more appropriate. An agent is left to infer usage entirely from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Change the weather' signals a mutation but does not disclose persistence, reversibility, permissions, or side effects such as thunder implying rain or weather reverting. This is minimal disclosure for a state-changing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three words, no filler; the core intent is front-loaded and immediately readable. It is well-structured for a simple tool, though terse enough that the lack of supporting detail keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity—one required enum parameter and no output schema—the description covers the basic operation. However, it omits usage context and any behavioral nuances, so it is only minimally complete for an agent deciding when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate, but it adds no information beyond the property name; the enum values (clear, rain, thunder) are left to the schema. The phrase 'the weather' at least ties the single parameter to the intended effect, but does not explain the semantics of each value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: 'Change the weather.' This clearly identifies what the tool does, and there is no weather-specific sibling among the provided tools. It does not explicitly contrast with related setters like set_time or set_gamerule, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use set_weather versus alternatives; it only says 'Change the weather.' The sibling list includes other state-changing commands such as set_gamerule, set_time, and server_properties_set, but the description gives no selection criteria or exclusions, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only names the core action and does not mention side effects, whether the player must be online, permission requirements, idempotency, or what happens if the player is not currently an operator.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler, front-loading the verb and resource. It is appropriately sized for a one-parameter tool, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the action and target are clear, but the description leaves gaps in usage selection, player identifier format, and behavioral expectations. It is minimally viable but not fully complete given the absence of annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only echoes that the action is performed 'from a player,' adding minimal meaning to the player parameter, but it does not specify the expected identifier format (username vs. UUID) or any constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Revoke'), a resource ('operator status'), and the target ('a player'), so it clearly identifies the operation. It does not explicitly distinguish itself from siblings like player_op or player_pardon, though the inverse relation to player_op is implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. With siblings such as player_op, player_pardon, and player_kick present, an agent is left to infer selection from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention whether the time change persists, affects all players, requires permissions, or if there are restrictions on accepted values beyond examples. For a mutating tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that clearly states the purpose without any fluff. It is front-loaded and immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool performs a mutation (setting in-game time) with no annotations and no output schema, the description is minimal. It lacks details about persistent effects, scope, or restrictions on accepted values beyond the schema's example. More context would help an agent assess side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter schema already provides a clear description and examples. The tool description adds no further meaning beyond what the schema states. Since schema coverage is high, this is an acceptable baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set the in-game time' clearly states the action (set) and the resource (in-game time). It is specific enough to distinguish from other tools in the sibling list, like set_weather or set_gamerule, though it doesn't explicitly mention alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool versus similar setter tools (e.g., set_weather, set_gamerule). The description offers no context about prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the action but does not disclose potential side effects (e.g., whether it blocks until the server is up, whether it fails gracefully if already running, or whether it requires elevated permissions). No details on output or state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no waste. It's appropriately short for a zero-parameter operation, though it lacks a hint about what follows (e.g., checking status).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter state-changing tool with no annotations and no output schema, the description should clarify expected outcomes (e.g., server starts asynchronously, check server_status to confirm). It doesn't do that, so an agent may not know how to verify success or handle errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, so schema coverage is 100% (vacuously). The description doesn't need to explain any parameters. The baseline for 0 params is 4, and the description aligns with that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Start') and resource ('the Paper Minecraft server process'). It clearly distinguishes from siblings like server_stop and server_restart by focusing on the initial start action, though it doesn't explicitly differentiate from server_restart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no context on when to use this tool versus alternatives. It does not mention prerequisites (e.g., server not already running), or conditions where server_restart might be preferred. No guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states the action, but does not disclose potential side effects (e.g., teleport confirmation, whether the action is instant or requires server restart), error cases (e.g., invalid player or invalid coordinates), or any impact on gameplay. Minimal behavioral disclosure for a tool that mutates server state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that quickly conveys the core action. No filler or redundant content. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter teleport command used in server management, the description is adequate in that it specifies the action and the two destination modes. However, it omits any mention of error handling, permission requirements, or behavioral side effects, which could leave an agent uncertain about edge cases. Given the absence of an output schemaThis is a relatively common pattern for such commands, so a 3 reflects the overall sufficiency but lack of depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes 'destination' with 'Target player name, or x y z coordinates', and the description reinforces this by saying 'to another player or to coordinates'. However, the 'player' parameter has no description in the schemaˌ and the description does not clarify it further. The description adds slight value for 'destination' but leaves 'player' ambiguous. With 50% schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Teleport') and the resource ('a player'), and specifies two destination types ('another player' or 'coordinates'). It's specific enough to distinguish from sibling tools like server_start or give_item, even without naming alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. While the tool's purpose is obvious from the name, the description doesn't mention any preconditions (e.g., player online, permission requirements) or suggest alternatives for related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but does not mention any side effects (there likely are none), performance implications, or whether it requires any special permissions. It also doesn't clarify what constitutes 'online' (e.g., active connections) or how the list is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a single, clear sentence that front-loads the action and resource. It avoids unnecessary words or details, making it easy for an agent to quickly grasp the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is mostly sufficient. However, it lacks information about the response format (e.g., list of usernames, UUIDs) and any potential limits or empty states. Since it's a read-only status tool, this is acceptable but could be enhanced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% with no properties defined. Since there are no parameters to document, the description doesn't need to explain them. The score reflects that the tool is self-contained with no ambiguity in parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 'currently online players', making the tool's purpose immediately understandable. It effectively distinguishes itself from sibling tools like player_ban or player_kick, though it could be more specific about the format of the list (e.g., player names, UUIDs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool compared to alternatives like server_status or whitelist_list. It doesn't mention that this tool specifically shows real-time online status, nor does it differentiate between online players and whitelisted players.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It notes the restart requirement, but it does not mention whether the operation updates or creates the key, what happens if the key is invalid, whether it is destructive, or any error conditions. The restart note is helpful but insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, consisting of two short sentences with no redundant wording. It front-loads the core action and then adds the essential caveat. This structure is easy to parse and presents information in a logical order.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema or annotations, the description covers the basic purpose and a critical operational detail. However, it lacks information about expected output (e.g., success/failure indication), parameter validation, or potential side effects. It is adequate for a minimal tool but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only parameter names (key and value) with no descriptions, and the tool description does not elaborate on them. It does not explain what constitutes a valid key (e.g., allowed properties) or the expected format for the value. The description adds no additional meaning beyond the parameter names, so agents cannot infer how to correctly populate them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: setting a single key in server.properties. It uses a specific verb (set) and a specific resource (server.properties), and distinguishes itself from the sibling tool that retrieves properties. This makes its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that a server restart is required for changes to take effect, which is a useful caveat. However, it does not explicitly state when to use this tool over alternatives like server_properties_get or other configuration tools. The usage context is implied but not fully described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of behavioral disclosure. It only states the high-level effect and does not mention reversibility, authorization requirements, or behavior when the player is not already whitelisted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, front-loaded sentence with no wasted words. This is excellent conciseness for a simple single-parameter command.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The single parameter and lack of output schema make this a very simple tool, so the description is minimally adequate. However, the lack of behavior format details and no mention of how to verify removal leaves noticeable gaps for an agent in a broad tool context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema exposes a single 'player' string with zero description coverage. The tool description merely rephrases the action and does not clarify whether the value should be a Minecraft username, UUID, or case-sensitive identifier, nor gives examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Remove' and the resource 'player from the whitelist', making the tool's purpose unambiguous. It naturally distinguishes itself from sibling tools like whitelist_add and whitelist_list, which correspond to opposite or listing actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 relative to alternatives such as player_kick, player_ban, or player_pardon. There are no mentioned prereats, preconditions, or contextual examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description carries the full burden for behavioral transparency. The description clearly indicates a mutating action (broadcasting) but does not disclose any potential side effects, such as whether the message is logged, or if there are restrictions (e.g., formatting). It does not contradict anything because there are no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that perfectly communicates the purpose. It is front-loaded with the core action and resource, and there is no extraneous content. It earns a high score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is mostly complete. An agent can infer how to call it. However, it lacks context about the underlying server protocol, such as whether the message supports color codes or commands, and does not explain return behavior. Given the tool's simplicity, this is acceptable but not exceptional.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only one parameter, 'message', as a string. The schema coverage is 0%, meaning the description provides no additional detail about the parameter. However, the parameter is self-explanatory given the description, and the baseline for parameter semantics when schema has no descriptions and 1 param is adaptive. The description implies the parameter is the message text, but does not add syntax or format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Broadcast a chat message to all players' clearly states the action (broadcast), the resource (chat message), and the target (all players). It is specific enough to distinguish from the sibling tools, none of which are about broadcasting messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool—when you want to send a chat message to all players. However, it does not explicitly state when not to use it or mention alternatives (e.g., rcon_command for sending a command). Since there are no annotations or context, this 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits itself. It only states the action, omitting whether the player must be online, whether permissions are required, whether the grant is persistent, or what response the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler or repetition. It states the action and object clearly and packs all relevant information into a scannable format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description is mostly sufficient for selection and invocation. Yet with no annotations and no output schema, it omits behavioral details like response format and prerequisites; sibling tools help disambiguate but do not fill that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'player' parameter is self-descriptive and the description reinforces that it receives operator status. However, the schema has zero parameter documentation, and the description adds no format details such as username vs UUID, validation rules, or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'grant' with the resource 'operator status', clearly identifying the action. It stands in distinct contrast to siblings player_deop and ops_list, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The verb 'grant' implies this is the tool to use when conferring operator privileges, but there is no explicit when-to-use guidance or mention of exclusions versus alternatives. No context or prerequisites are provided beyond the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Read', which implies non-mutating behavior, but offers no context on file location, error handling (e.g., if whitelist.json doesn't exist), or the structure of the returned data. This is minimal coverage for a tool with no 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It front-loads the action ('Read') and states the object clearly. It is appropriately sized for a tool of this simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no params, no output schema), the description is almost sufficient. It tells the agent what is read but does not describe the return format or potential failure modes. An agent might expect a list of player names or raw JSON; specifying 'returns the JSON contents' or noting if an error occurs when the file is missing would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (empty schema). Per the baseline rule for zero-parameter tools, this earns a 4. The description adds no parameter details, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the resource 'whitelist.json contents', making it distinct from sibling tools like whitelist_add and whitelist_remove which modify. It also differentiates from other list tools (ops_list, banned_players_list) by naming the specific resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention exclusions or reference sibling tools for different use cases. While the name implies a read operation, a more explicit statement like 'Use this to view the current whitelist, as opposed to adding or removing entries' would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. 'Unban' clearly discloses a state-changing operation that removes a ban, but it does not mention permissions, output, or the fact that it only affects player bans rather than IP bans.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one clear sentence with no filler or redundancy. The key verb 'Unban' is front-loaded, and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's trivial single-parameter shape, the description is minimally adequate for selecting and making a first attempt at a call. However, with no annotations or output schema, it leaves gaps around return behavior, exact player identification, and prerequisites such as the player currently being banned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema offers a single required `player` string with no description, and the description does not clarify the expected format (username vs UUID) or any constraints. Because schema coverage is 0%, the description needed to compensate but only repeats the concept of 'a player' without adding parameter-specific semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific action verb 'Unban' and names the target resource ('a player'), making the tool's purpose immediately clear. It also distinguishes itself from the sibling ban and kick tools by describing the opposite operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case—when a previously banned player should be allowed back—but it does not explicitly state when to use this tool instead of alternatives like player_ban or player_kick. There is no exclusionary guidance, so an agent must infer the conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Read' implies read-only, but it does not explicitly state there are no side effects, rate limits, or error behaviors (e.g., file missing). For a simple getter this is acceptable but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that states the action and target. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter read tool with no output schema, the description gives the essential behavior. Could mention return format explicitly, but 'key-value pairs' implies it. Adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the schema is empty. The description adds value by stating that it reads all key-value pairs, which clarifies the output semantics (a map of key-value pairs). Baseline 4 for 0-param tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Read all key-value pairs from server.properties' uses a specific verb (read) and resource (server.properties) with a clear scope (all key-value pairs). It is clearly distinguishable from siblings like server_properties_set (write) and server_status (server state), so an agent can select it correctly without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but provides no guidance on when to use it versus alternatives mirror. No mention of conditions, prerequisites, or when not to use it. It is implied by its name, but the rubric expects explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It does identify this as a read-only operation—getting stats—which is positive. However, it doesn't disclose any potential limitations, such as whether TPS is averaged over a period, whether MSPT is instantaneous, or if the command might fail on a stopped server.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, direct sentence that conveys the exact purpose. No wasted words, and key information (what metric, for what target) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a zero-parameter read-only utility with siblings like server_status, the description is mostly sufficient. It could be more complete with a note that this is a performance-specific counterpart to server_status or a mention of the return format, but nothing critical is missing for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so schema coverage is trivially complete. The description reinforces that no arguments are needed by focusing solely on the output values. A 4 is appropriate because there is nothing more parameter documentation could add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the server's current TPS and MSPT stats. It uses a specific verb ('Get') and resource ('server's current TPS and MSPT stats'), distinguishing it well from sibling tools like server_status or server_start.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is a diagnostic/read-only monitoring tool, useful for checking server performance. However, it doesn't explicitly state when to use it over server_status or provide contextual guidance such as 'use this for performance diagnostics'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. 'Read' and 'current' convey a non-mutating snapshot operation, but the description does not reveal return format, error behavior, or whether the data is raw file content versus a parsed list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no wasted words. It immediately communicates the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 tool, this description is adequately complete. The only notable gaps are the lack of explicit sibling differentiation and no stated output format, but the tool name and simplicity keep these gaps minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema description coverage is 100%, so there is nothing for the description to add. Per calibration, a zero-parameter tool gets a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Read') and a specific resource ('current banned-ips.json contents'). It clearly distinguishes this from sibling tools like banned_players_list by identifying the banned-IP file specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: call when you need the current banned-IP list. However, there is no explicit guidance about when not to use it or how it compares to similar siblings such as banned_players_list or players_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. 'Get' implies a read-only operation and the source path is named, but the description does not explicitly state that no side effects occur, nor describe output formatting or behavior when the optional lines parameter is omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that conveys the resource and operation with no filler. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tail operation, the description covers the essential resource and count. The main gaps are the optional-parameter default behavior and explicit differentiation from logs_search, but these are minor for this level of complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description gives semantic meaning to the 'lines' parameter by referring to 'N lines', which the bare schema lacks. It does not specify the default when the parameter is omitted, but the parameter is simple and the schema already documents its constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get'), a specific resource ('logs/latest.log'), and the operation's scope ('last N lines'). This is unambiguous and differentiates it from the sibling logs_search tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: an agent would choose this when it wants the most recent log lines. However, the description does not explicitly contrast it with logs_search or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. 'Read' conveys a non-mutating, side-effect-free operation on live state, which is adequate for a zero-parameter read tool. It does not discuss permissions or error cases, but those are minor for this simple action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no filler. It front-loads the verb and resource and earns every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read operation with no output schema, the description provides all necessary call-level information: what action to take and what resource it targets. The returned content is implied by 'contents', so nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is already complete and there is nothing to explain. The description correctly avoids inventing parameter details, and the baseline for zero-parameter tools is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Read') and a specific resource ('current ops.json contents'), which is unambiguous. It is clearly distinct from sibling tools like whitelist_list or server_status because it names the exact file being read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives or when not to use it. The intended context is implied by the operation, but no exclusions or sibling comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It conveys that the command is raw and executed via RCON, and the 'use dedicated tools' note implies this is a lower-level option, but it does not disclose potential side effects, irreversibility, permission needs, or command output behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with the core action front-loaded, followed by a concrete example and routing guidance. Every sentence earns its place and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, this is largely usable, but it leaves return-value and safety expectations unstated. Since there are no annotations to cover the safety profile, the description would benefit from noting that raw commands can be powerful or destructive and that output may be returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single 'command' parameter as a raw console command without a leading slash, so parameter coverage is complete. The description adds a useful example but does not substantially extend meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as sending a raw RCON command to the server console, with a concrete example ('gamerule keepInventory true'). It also distinguishes this escape-hatch tool from dedicated sibling tools, making its role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using dedicated tools for common actions when available, which tells the agent when to prefer alternatives and when to fall back to this raw command tool. This provides clear selection guidance relative to the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavior. It does so by explaining the graceful shutdown via RCON and the SIGTERM fallback if RCON is unreachable. This is a meaningful behavioral disclosure, though it stops short of describing potential side effects like unsaved data loss or shutdown timing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the primary action and then adds the key behavioral details. Every word serves a purpose, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description is complete. It explains the stopping mechanism, the graceful fallback, and implicitly when it would be used. Given the low complexity, nothing essential is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the only parameter ('graceful') with a clear description and default value, so the schema coverage is 100%. The tool description adds no additional meaning beyond what the schema provides, placing it at the baseline of 3 for parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Stop') and the target ('the Minecraft server'), making it unambiguous. It distinguishes itself from sibling tools like server_start, server_restart, and server_status by explicitly naming the stop operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (for stopping the server) but does not explicitly state when to use it versus alternatives such as server_restart or server_status. It offers no exclusions or alternative guidance, relying on the tool's name and clear purpose to infer when it should be called.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even without annotations, the description clearly frames this as a read-only operation by stating 'Read the current banned-players.json contents.' It signals that no server mutation or state change occurs. It does not describe output format or edge cases, but for a simple no-parameter file read this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence of about eight words. Every word adds information: it names the verb, clarifies the resource is the banned-players.json file, and emphasizes it reflects the current contents. There is no redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, no annotations, and no output schema, the description gives enough high-level context to understand it as a plain read of the banned-players file. It could theoretically state the exact return representation, but naming the file and saying 'contents' makes the expected behavior clear for a simple reader.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is little for the description to clarify beyond what the schema shows. The baseline of 4 applies because parameter semantics are trivially complete; the description cannot add meaningful parameter nuance to a tool with no inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and a specific resource ('current banned-players.json contents'). This clearly distinguishes it from sibling tools like banned_ips_list, players_list, and whitelist_list, since it targets the banned-players file specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when this tool is useful: whenever the agent needs the current list of banned players from the banned-players.json file. However, it gives no explicit guidance about alternatives, such as when to use banned_ips_list or whitelist_list instead, and no exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral burden. It accurately states the action (checking running state and retrieving PID) with no side effects disclosed; for a simple read-only tool, this is sufficient. It does not contradict any annotations (none exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with two clear actions, front-loaded with the primary intent. Every word earns its place; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description is largely complete. It tells the agent what to expect (running state and PID), though it does not specify the exact return format (e.g., boolean + integer vs. JSON). Given the simplicity, this minor gap is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4 per the rubric. The description adds no parameter details because none exist, and the schema is trivially covered. No additional value is expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and names the exact resource ('Minecraft server process') plus the output ('get its PID'). This clearly distinguishes it from siblings like server_tps or players_list, which check other aspects of the server.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a read-only status check but does not explicitly state when to use it relative to alternatives. There is no mention of using it before start/stop or as a health check, and it does not name any alternative tool. Usage context is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the behavioral disclosure burden. It clearly explains the sequence — graceful stop, 10-second wait, then start — which provides a transparent view of the operation's side effects (temporary downtime, orderly shutdown). It does not cover every possible implication (e.g., player disconnect), but the core behavior is well communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one parenthetical clause appended to a clear noun phrase. Every word earns its place, and the key behavior is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless action with no output schema, the description fully covers what the agent needs to know to invoke it correctly. It explains what happens both during and around the restart, making the behavior complete and predictable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema is trivially complete and the description has nothing to add about parameter meanings. Per calibration guidance, the baseline for a zero-parameter tool is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Restart'), a clear resource ('the Minecraft server'), and a precise scope ('graceful stop, wait 10s, then start'). It clearly distinguishes this tool from the sibling start/stop tools by describing the full restart cycle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by the name and the description (it is a restart, not a plain start or stop). However, it does not explicitly state when to choose this over server_start or server_stop, nor does it mention when not to use it. This falls short of explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![minecraft-paper-mcp MCP server](https://glama.ai/mcp/servers/inrok872-cyber/minecraft-paper-mcp/badges/card.svg)](https://glama.ai/mcp/servers/inrok872-cyber/minecraft-paper-mcp)

Score Badge

Copy to your README.md:

[![minecraft-paper-mcp MCP server](https://glama.ai/mcp/servers/inrok872-cyber/minecraft-paper-mcp/badges/score.svg)](https://glama.ai/mcp/servers/inrok872-cyber/minecraft-paper-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/inrok872-cyber/minecraft-paper-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server