pterodactyl-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools are clearly distinct, targeting specific resources and actions (e.g., create_server vs. update_server_build). However, some overlap exists, such as list_server_databases and list_client_databases (implied but not included), and update_server_details vs. update_server_build vs. update_server_startup, which could cause confusion if not carefully read.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout (e.g., create_allocation, list_eggs, update_user). All names use snake_case, and verbs are appropriately chosen for actions, making the set predictable and easy to navigate.
Tool Count3/5
With 34 tools, the count is borderline high for a single server, potentially overwhelming for agents. While it covers many admin actions for a game server panel, it might benefit from consolidation or categorization to reduce cognitive load.
Completeness5/5
The tool set provides comprehensive CRUD and lifecycle coverage for the Pterodactyl panel domain, including server management (create, delete, suspend, update), user and egg handling, and infrastructure operations. No obvious gaps are present, supporting full administrative workflows.
Average 4.4/5 across 32 of 34 tools scored.
See the Tool Scores section below for per-tool breakdowns.
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.
Tools from this server were used 2 times in the last 30 days.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a destructive operation (destructiveHint: true) and has open-world characteristics (openWorldHint: true). The description adds valuable context beyond annotations by specifying it's an 'admin action' and requires specific API key authentication, which helps the agent understand permission requirements not captured in annotations.
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 efficiently structured in three sentences: purpose statement, parameter guidance, and authentication requirement. Each sentence adds distinct value with zero wasted words, making it easy to parse and understand quickly.
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 destructive admin tool with 9 required parameters and no output schema, the description provides good context about prerequisites, authentication, and parameter syntax. However, it doesn't mention potential side effects, error conditions, or what happens on success - gaps that could be important for a destructive operation.
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?
With 100% schema description coverage, the input schema already documents all 9 parameters thoroughly. The description adds minimal parameter-specific information - only clarifying the syntax for the 'rules' field ('uses Laravel validation syntax'). This meets the baseline expectation when schema coverage is complete.
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 ('Add a new environment variable'), the target resource ('to an egg'), and the required permission level ('admin action'). It distinguishes from siblings like 'update_egg_variable' and 'delete_egg_variable' by specifying creation of a new variable rather than modification or deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about prerequisites ('Use list_nests and list_eggs to find the nest_id and egg_id') and authentication requirements ('Requires Application API key'). However, it doesn't explicitly state when NOT to use this tool or mention alternatives like 'update_egg_variable' for existing variables.
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?
Annotations provide destructiveHint=true and openWorldHint=true, but the description adds valuable behavioral context beyond these: it specifies this is an 'admin action', includes a security warning about root_admin granting 'FULL panel access', and states the authentication requirement ('Requires Application API key'). These details aren't captured in the annotations and provide important 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in three sentences: purpose statement, usage context, and security/authentication requirements. Every sentence adds essential information with zero wasted words, and critical security warnings are appropriately emphasized.
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 destructive admin tool with no output schema, the description provides strong context about permissions, security implications, and authentication requirements. It covers the tool's purpose, usage relationship with other tools, and critical warnings. The main gap is lack of information about return values or error conditions, which would be helpful given the destructive nature.
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?
With 100% schema description coverage, the input schema already documents all parameters thoroughly. The description adds minimal parameter-specific information beyond the schema - only emphasizing the security implications of root_admin. This meets the baseline expectation when schema coverage is complete.
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 specific action ('Create a new user account'), identifies the resource ('on the panel'), and distinguishes it from siblings by specifying this is an 'admin action' that enables subsequent server ownership assignments, differentiating it from other user-related tools like get_user or update_user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool ('admin action'), mentions its relationship to other tools ('can then be assigned as owner of servers via create_server or update_server_details'), and includes a security warning about admin privileges. However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings.
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?
Annotations indicate read-only and open-world hints, but the description adds valuable context: it discloses that sensitive fields are redacted, specifies it's an admin action, and states it requires an Application API key. These details go beyond annotations, enhancing transparency about security and access requirements.
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 front-loaded with the core purpose, followed by key behavioral details (redaction, admin action, usage context, API key requirement). Each sentence adds value without redundancy, making it efficient and well-structured.
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?
Given the tool's complexity (admin action with security considerations), annotations cover read-only/open-world aspects, but no output schema exists. The description compensates by explaining the return content (config.yml with redactions) and prerequisites (API key), making it mostly complete, though it could note potential errors or response formats.
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?
Schema description coverage is 100%, with the parameter 'node_id' fully documented in the schema. The description does not add any additional meaning or details about the parameter beyond what the schema provides, so it meets the baseline for high schema coverage.
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 'Get' and the resource 'Wings daemon configuration for a node', specifying it returns config.yml content. It distinguishes from siblings like get_node or get_server by focusing on daemon configuration rather than general node/server details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage context ('when setting up or troubleshooting a node'), which helps guide when to use this tool. However, it does not mention when not to use it or name specific alternatives among siblings, such as get_node for general node information.
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?
The description adds valuable behavioral context beyond what annotations provide. While annotations indicate read-only and open-world operations, the description specifies this is an 'admin action' requiring specific permissions ('Requires Application API key'), which is crucial information not captured in the annotations. It also provides the Pelican panels special case guidance, though it doesn't mention rate limits or pagination 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 efficiently structured in three sentences that each serve a distinct purpose: stating the tool's function, specifying what information is returned, and providing important usage constraints. There is no wasted language, and critical information is front-loaded appropriately.
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 read-only tool with comprehensive annotations and full schema coverage, the description provides adequate contextual information. It covers the admin nature of the operation, authentication requirements, and special case handling. The main gap is the lack of output schema, so the description doesn't specify the exact structure of returned data, though it does list the types of information included.
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?
With 100% schema description coverage, the input schema already fully documents both parameters (nest_id and egg_id) including their types, constraints, and descriptions. The description adds minimal parameter-specific information beyond the schema, only mentioning the special case for nest_id=0 on Pelican panels. This meets the baseline expectation when schema coverage is complete.
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 specific action ('List all environment variables'), resource ('defined for an egg'), and scope ('admin action') with details about what information is shown (name, env_variable key, default value, validation rules, user editability). It distinguishes itself from siblings like 'get_egg' or 'list_eggs' by focusing specifically on environment variables rather than general egg information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool ('admin action') and includes important prerequisites ('Requires Application API key') and specific guidance for a special case ('On Pelican panels, use nest_id=0'). However, it doesn't explicitly mention when NOT to use this tool or name alternative tools for related but different purposes.
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?
The description adds valuable behavioral context beyond annotations: it explains the idempotent behavior ('calling on a non-suspended server has no effect'), clarifies the admin nature of the action, and specifies the API key requirement. While annotations already indicate idempotentHint=true and destructiveHint=true, the description provides concrete examples of what 'destructive' means in this context (re-enabling servers).
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 perfectly concise with three sentences that each serve distinct purposes: stating the action, explaining the effect, and specifying behavioral traits. No wasted words, and the most critical information appears first.
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 single-parameter mutation tool with good annotations but no output schema, the description provides excellent context about the action, prerequisites, and behavioral traits. The main gap is the lack of information about return values or error conditions, which would be helpful given there's no output schema.
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?
With 100% schema description coverage, the input schema already fully documents the single parameter. The description doesn't add any additional parameter semantics beyond what's in the schema, so it meets the baseline expectation but doesn't provide extra value.
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 specific action ('unsuspend') on a specific resource ('server'), distinguishes it from the sibling 'suspend_server' tool, and specifies it's an admin action. The verb+resource combination is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool ('previously suspended server') and mentions the prerequisite ('Requires Application API key'). However, it doesn't explicitly state when NOT to use it or compare it with alternatives like 'reinstall_server' for different scenarios.
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?
The description adds valuable behavioral context beyond what annotations provide. While annotations indicate destructiveHint=true and openWorldHint=true, the description specifies this is an 'admin action' and 'Requires Application API key' - important permission and authentication requirements. It doesn't contradict annotations but 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose. Each sentence adds value: the first states the action and admin nature, the second lists key requirements, the third provides tool references for prerequisites. There's minimal waste, though it could be slightly more structured.
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 complex creation tool with 15 parameters, no output schema, and destructive annotations, the description provides good context. It covers prerequisites, authentication needs, and references to sibling tools for finding required data. While it doesn't explain return values (no output schema exists), it gives enough operational guidance for an agent to use the tool effectively.
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?
With 100% schema description coverage, the baseline is 3. The description mentions key parameters like 'egg ID', 'owner user ID', 'allocation ID', and 'resource limits', but doesn't add significant semantic context beyond what's already well-documented in the schema. It provides high-level grouping of parameters but no additional format or constraint details.
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 specific action ('Create a new game server'), the resource ('on the panel'), and distinguishes it from siblings by specifying it's an 'admin action'. It goes beyond just restating the name by providing context about what's being created.
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 provides explicit guidance on when to use this tool: 'Requires egg ID (from list_eggs), owner user ID (from list_users), allocation ID, and resource limits.' It also mentions alternative tools to find required information: 'Use list_eggs to find available server templates and list_nodes to find nodes with capacity.' This gives clear prerequisites and related 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?
Annotations provide openWorldHint=true and destructiveHint=true, indicating this is a write operation that modifies state. The description adds valuable context: it specifies this is an 'admin action' and requires specific authentication ('Application API key'), which goes beyond the annotations. No contradiction with annotations.
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?
Three sentences, each serving a distinct purpose: stating the action, providing usage examples, and outlining prerequisites. No wasted words, and key information is front-loaded.
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 destructive tool with no output schema, the description covers purpose, usage, and prerequisites well. It could be more complete by hinting at potential side effects or confirmation steps, but given the annotations and clear parameters, it's largely adequate.
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?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal extra semantics by giving examples of port formats ('25565' or '25565-25570') and hinting at node_id sourcing from list_nodes, but doesn't significantly enhance understanding 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 states the action ('Create new port allocations'), specifies the resource ('on a node'), and distinguishes it from siblings like 'list_allocations' (read) and 'delete_allocation' (remove). It provides specific details about what can be allocated (individual ports or ranges).
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?
Explicitly states prerequisites: 'Use list_nodes to find the node_id first' and 'Requires Application API key.' It also distinguishes when to use this tool versus alternatives by mentioning the need to first use list_nodes, and the admin-only nature implies it's not for general users.
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?
Annotations already provide destructiveHint=true and openWorldHint=true, indicating this is a destructive operation with potentially unknown side effects. The description adds valuable context beyond annotations: it specifies the 'admin action' requirement, the constraint about allocations in use, and the API key requirement. No contradiction with annotations exists.
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 and front-loaded with essential information in just three sentences. Every sentence earns its place: the core action, a critical constraint, and a prerequisite tool reference. No wasted words or redundant information.
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 destructive tool with two parameters and no output schema, the description provides strong contextual completeness. It covers the admin requirement, usage constraints, and prerequisites. The only minor gap is lack of explicit mention of what happens upon successful deletion or error handling, but annotations cover the destructive nature adequately.
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?
Schema description coverage is 100%, with both parameters well-documented in the schema (node_id from list_nodes, allocation_id from list_allocations). The description references list_allocations for finding allocation_id but doesn't add significant semantic meaning beyond what the schema already provides. Baseline 3 is appropriate given high schema coverage.
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 specific action ('Delete'), resource ('a port allocation from a node'), and scope ('admin action'), distinguishing it from siblings like delete_server or delete_egg. It precisely identifies what the tool does without being vague or tautological.
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 provides explicit guidance on when to use this tool: 'Cannot delete allocations that are in use by a server' (when-not), 'Use list_allocations to find the allocation_id' (prerequisite), and 'Requires Application API key' (permission requirement). It clearly differentiates usage context from other deletion 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?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating safe read access with open-world semantics. The description adds valuable context beyond annotations: it specifies this is an 'admin action' (permission level), details the return content structure, and mentions API key requirement. No contradiction with annotations.
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?
Front-loaded with core purpose, followed by return details and usage prerequisites. Every sentence adds value: first defines the action, second specifies return content, third provides parameter sourcing guidance, fourth states authentication requirement. No wasted words.
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 read-only tool with good annotations and 100% schema coverage, the description provides excellent context about return content, admin requirements, and parameter sourcing. The main gap is lack of output schema, but the description compensates well by detailing the return structure. Could slightly improve by mentioning error cases or rate limits.
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?
Schema description coverage is 100%, with both parameters well-documented in the schema. The description adds minimal semantic context by referencing list_nests and list_eggs as sources for the IDs, but doesn't provide additional format or validation details beyond what the schema already specifies.
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 specific action ('Get full details'), resource ('egg/server template'), and scope ('admin action'). It distinguishes from siblings like list_eggs (which lists IDs) and get_nest (different resource type) by specifying detailed retrieval of a specific egg.
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?
Explicitly provides when-to-use guidance: 'Use list_nests to find the nest_id and list_eggs to find the egg_id.' It also specifies prerequisites ('Requires Application API key') and distinguishes from list_eggs by indicating this is for detailed retrieval after identification.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating safe read operations with potentially incomplete data. The description adds valuable context beyond annotations: it specifies authentication requirements ('Requires Application API key'), administrative context ('admin action'), and return data structure ('Returns name, description, author, and metadata'), though it doesn't mention rate limits or error 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 efficiently structured in three sentences: purpose, return values, and prerequisites. Each sentence adds essential information without redundancy, and key details are front-loaded. There's no wasted verbiage or repetition.
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?
Given the tool's low complexity (single parameter, read-only operation) and comprehensive annotations, the description is mostly complete. It covers purpose, usage, authentication, and return structure. However, without an output schema, it could benefit from more detail on response format or error cases, though the annotations provide safety context.
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?
Schema description coverage is 100%, with the parameter fully documented in the schema. The description adds minimal value beyond the schema by mentioning that nest_id comes 'from list_nests,' but doesn't provide additional format or validation details. This meets the baseline expectation when schema coverage is complete.
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 specific action ('Get details'), resource ('a specific nest'), and scope ('by ID'), distinguishing it from sibling tools like list_nests (which lists all nests) and get_egg (which retrieves egg details). It explicitly identifies the resource as an 'egg category' for additional clarity.
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 provides explicit guidance on when to use this tool ('by ID'), when not to use it (use list_nests to find the nest_id), and names the alternative tool (list_nests). It also specifies prerequisites ('Requires Application API key') and context ('admin action').
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?
Annotations already indicate readOnlyHint=true and openWorldHint=true, but the description adds valuable context: it specifies this is an 'admin action' (implying elevated permissions), mentions the authentication requirement ('Requires Application API key'), and lists the specific fields returned (name, FQDN, etc.). This goes beyond what annotations provide 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: first states purpose and return fields, second provides usage guidance, third specifies authentication. Each sentence earns its place by adding distinct, necessary information.
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 read-only tool with good annotations and full schema coverage, the description is quite complete. It covers purpose, usage workflow, authentication, and return data structure. The only minor gap is lack of output schema, but the description compensates by listing return fields. It could slightly improve by mentioning error cases or rate limits.
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?
Schema description coverage is 100%, so the schema already fully documents the single parameter. The description adds minimal value by mentioning 'node_id' comes 'from list_nodes', but doesn't provide additional semantic context beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting.
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 ('Get detailed information'), the resource ('specific infrastructure node'), and distinguishes it from siblings by specifying it's for a single node (vs. list_nodes for multiple). It also mentions it's an 'admin action' which provides context about the tool's role.
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?
Explicitly states when to use ('Use list_nodes to find the node ID first') and provides prerequisites ('Requires Application API key'). This gives clear guidance on the workflow and authentication requirements.
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?
Annotations provide readOnlyHint=true and openWorldHint=true, indicating safe read operations. The description adds valuable context beyond annotations: 'Sensitive environment variables are masked' and 'Requires Application API key'. These disclose security and authentication behaviors not covered by annotations, though it doesn't mention rate limits or other operational constraints.
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 front-loaded with the core purpose in the first sentence, followed by usage guidance and behavioral notes. Every sentence serves a distinct purpose: defining the tool, differentiating from siblings, and disclosing key behaviors, with no wasted words.
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?
Given the tool's complexity (read-only configuration inspection) and the absence of an output schema, the description is largely complete. It covers purpose, usage, and key behavioral aspects like masking and authentication. However, it could mention the response format or any limitations (e.g., pagination), leaving minor gaps.
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?
Schema description coverage is 100%, with the single parameter 'server_id' fully documented in the schema. The description does not add any parameter-specific details beyond what's in the schema, so it meets the baseline of 3 for high schema coverage without extra value.
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 'Get' and the resource 'detailed static configuration for a server', listing specific components like name, description, resource limits, container config, allocations, and timestamps. It explicitly distinguishes from sibling 'get_server_resources' by specifying this is for 'server config inspection' versus 'live resource usage'.
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 provides explicit guidance: 'Use for server config inspection' and 'For live resource usage (CPU/RAM/disk), use get_server_resources instead'. This clearly defines when to use this tool versus an alternative, with no ambiguity.
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?
The description adds valuable behavioral context beyond annotations: it specifies this is an 'admin action' (authorization requirement), mentions the return format ('username, email, language, admin status, and timestamps'), and notes the prerequisite of using list_users first. While annotations provide readOnlyHint and openWorldHint, the description adds practical usage constraints.
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?
Extremely efficient three-sentence structure with zero wasted words. Each sentence serves a distinct purpose: stating the tool's function, specifying return values, and providing usage guidance. The description is front-loaded with the core purpose.
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 read-only tool with good annotations and a simple single parameter, the description is nearly complete. It covers purpose, usage guidance, return format, and authorization context. The main gap is the lack of output schema, but the description compensates by listing return fields. Could benefit from mentioning error conditions or rate limits.
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?
With 100% schema description coverage, the input schema already fully documents the single parameter. The description adds minimal parameter semantics beyond the schema, only reinforcing that it's a 'numeric ID' without providing additional format or validation details.
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 specific action ('Get detailed information'), target resource ('specific user account'), and key identifier ('by numeric ID'). It distinguishes from sibling tools like list_users by specifying this is for individual user details rather than listing users.
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?
Explicitly states when to use ('Use list_users to find the user ID first') and provides prerequisites ('Requires Application API key'). The description also indicates this is an 'admin action' which helps differentiate it from non-admin user operations.
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?
Annotations provide openWorldHint=true and destructiveHint=true, indicating this creates new resources with potential side effects. The description adds valuable context beyond annotations: it clarifies this is an 'admin action' requiring specific permissions ('Requires Application API key') and explains the downstream impact ('available for creating new servers via create_server'). No contradiction with annotations.
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?
Perfectly structured with three focused sentences: first states purpose, second provides usage guidance, third specifies requirements. Every sentence adds essential information with zero wasted words. The description is appropriately sized for a complex admin tool.
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 complex creation tool with 13 parameters and destructiveHint=true, the description provides excellent context about purpose, prerequisites, and downstream usage. The main gap is lack of output information (no output schema), but the description compensates well by explaining the egg's purpose and relationship to create_server.
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?
With 100% schema description coverage, the input schema already documents all 13 parameters thoroughly. The description adds minimal parameter semantics beyond the schema - it only mentions the need for 'nest_id' from list_nests. This meets the baseline expectation when schema coverage is complete.
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 ('Import or create') and resource ('a new egg (server template) in a nest'), explaining that eggs define Docker images and configurations for game servers. It distinguishes from siblings like 'create_server' by specifying this is an admin action for defining server templates, not creating actual servers.
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?
Explicitly provides when-to-use guidance: 'Use list_nests to find the nest_id first' and 'The egg will be available for creating new servers via create_server'. It also specifies prerequisites: 'Requires Application API key', clearly differentiating this admin action from regular server operations.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, but the description adds valuable context: it's an 'admin action' (implying elevated permissions), specifies authentication requirements ('Requires Application API key'), and mentions pagination behavior through the parameters. No contradiction with annotations.
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?
Extremely concise and well-structured - three sentences that each serve a distinct purpose: what the tool does, how to use it, and authentication requirements. No wasted words, front-loaded with the core functionality.
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 read-only listing tool with good annotations and full schema coverage, the description provides excellent context about permissions, prerequisites, and relationship to other tools. The main gap is lack of output schema, but the description partially compensates by specifying what information is shown. Could benefit from more detail about return format.
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?
Schema description coverage is 100%, so the schema already fully documents all parameters. The description adds minimal value beyond the schema - it mentions the node_id parameter context ('from list_nodes') but doesn't provide additional semantic information about the parameters beyond what's in the schema descriptions.
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 'List' and resource 'port allocations for a node', specifies it's an 'admin action', and distinguishes it from sibling tools by mentioning it requires node_id from list_nodes. It provides specific details about what information is shown (IP, port, alias, server usage).
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?
Explicitly states when to use ('Use list_nodes to find the node_id first') and provides prerequisites ('Requires Application API key'). It distinguishes from create_allocation and delete_allocation by being a read-only listing operation, and from other list_* tools by specifying it's for port allocations on a specific node.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe read operation with potentially dynamic data. The description adds valuable context beyond annotations: it specifies this is an 'admin action' requiring elevated permissions, mentions the specific data returned (mount name, source path, target path, read-only status), and explains what mounts are ('allow sharing host directories with server containers').
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 efficiently structured in three sentences: first states purpose and admin context, second specifies return data, third explains mounts and API key requirement. Every sentence adds value with zero wasted words, and key information is front-loaded.
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 tool with good annotations (readOnlyHint, openWorldHint), the description provides excellent context about permissions, return data, and mount functionality. The main gap is the lack of output schema, so the description carries the burden of explaining return values, which it does adequately but not exhaustively (e.g., no pagination or format details).
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?
With 0 parameters and 100% schema description coverage, the baseline would be 4. The description appropriately doesn't discuss parameters since none exist, instead focusing on what the tool does and returns. No parameter information is needed or missing.
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 ('List') and resource ('all mount points configured on the panel'), specifies it's an admin action, and distinguishes from siblings by focusing on mounts rather than servers, users, eggs, etc. It provides specific details about what information is returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this is an 'admin action' and 'Requires Application API key,' giving important prerequisites. However, it doesn't explicitly state when to use this versus alternatives or when not to use it, though the specificity of 'mount points' helps differentiate from other list 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?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe read operation with potentially large results. The description adds valuable context beyond annotations: it specifies this is an admin action, requires Application API key, and describes the return format (nest ID, name, author, description). It doesn't mention rate limits or pagination, but provides useful 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in three sentences: purpose statement with explanation, return value specification, and usage guidance with prerequisites. Every sentence adds value with no redundancy or wasted words.
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 read-only tool with no parameters and good annotations, the description provides excellent context about purpose, output format, and prerequisites. However, without an output schema, it could benefit from more detail about response structure (e.g., pagination, error cases). The admin action and API key requirements are well-covered.
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?
With 0 parameters and 100% schema description coverage, the baseline would be 4. The description appropriately doesn't discuss parameters since there are none, which is correct for this tool. It focuses instead on the tool's purpose and output.
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 ('List') and resource ('all nests (egg categories)'), specifies it's an admin action, explains what nests are with examples, and distinguishes from siblings by mentioning related tools (list_eggs, get_egg). It goes beyond just restating the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('to find specific server templates' via nest ID with list_eggs or get_egg) and mentions it's an admin action requiring Application API key. However, it doesn't explicitly state when NOT to use it or compare with the sibling 'get_nest' tool.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating safe read operations with potentially large result sets. The description adds valuable context beyond annotations: it specifies the return format (node ID, name, FQDN, resources, maintenance status), mentions pagination support, and states authentication requirements ('Requires Application API key').
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 efficiently structured in three sentences: first states purpose and return data, second provides usage guidance, third covers pagination and auth requirements. Every sentence adds value with zero wasted words.
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 read-only tool with good annotations and no output schema, the description provides excellent context: purpose, return format, usage guidance, pagination, and auth requirements. The only minor gap is not explicitly mentioning default values or error cases, but overall it's highly complete.
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?
Schema description coverage is 100%, with both parameters (page, per_page) well-documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema, so it meets the baseline expectation for high schema coverage.
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 specific action ('List all infrastructure nodes'), resource ('in the panel'), and scope ('admin action'), distinguishing it from sibling tools like get_node (which fetches a single node) and list_servers (which lists servers, not nodes). It provides a comprehensive overview of what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Use to check available capacity before creating servers'), providing clear context for its application. It also distinguishes it from create_server by indicating it's a prerequisite for capacity assessment.
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?
Annotations already indicate readOnlyHint=true and openWorldHint=true, but the description adds valuable context: it specifies this is an 'admin action', discloses the return format ('role ID, name, and timestamps'), and mentions the purpose ('Roles control admin panel access permissions'). No contradiction with annotations.
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 front-loaded with the core action and resource, followed by return details, role purpose, and authentication requirement. Every sentence adds value without redundancy, making it efficient and well-structured.
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?
Given the tool's low complexity (0 parameters, read-only, open-world), annotations cover safety, and no output schema exists, the description is reasonably complete. It explains what the tool does, returns, and requires. However, it could mention pagination or limits for a list operation to be fully comprehensive.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose and behavior. A baseline of 4 is applied for zero parameters.
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 ('List') and resource ('all admin roles defined on the panel'), specifies it's an 'admin action', and distinguishes from siblings by focusing on roles rather than servers, users, eggs, etc. It provides specific scope and context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Requires Application API key' as a prerequisite, providing clear context for when authentication is needed. However, it doesn't specify when to use this tool versus alternatives (e.g., if there are other role-related tools) or any exclusions.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe read operation with potentially incomplete results. The description adds valuable context beyond annotations: it specifies the admin perspective, mentions the return data structure, and states the API key requirement, which are not covered by annotations. No contradiction with annotations exists.
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 front-loaded with the core purpose in the first sentence, followed by usage guidance and prerequisites in subsequent sentences. Each sentence adds distinct value without redundancy, making it efficient and well-structured.
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?
Given the tool's moderate complexity (single parameter, read-only operation) and the presence of annotations covering safety and completeness hints, the description is largely complete. It explains the purpose, usage context, and prerequisites. However, without an output schema, it could benefit from more detail on return values or pagination, though it does mention what data is 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?
Schema description coverage is 100%, with the single parameter 'server_id' fully documented in the schema. The description does not add any parameter-specific information beyond what the schema provides, such as format details or examples. With high schema coverage, the baseline score of 3 is appropriate.
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 'List' and the resource 'databases attached to a server', specifying the perspective ('admin perspective') and what information is returned ('database host, name, and connection details'). It distinguishes from sibling tool 'list_client_databases' by contrasting admin vs. client-level access.
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 states when to use this tool ('admin perspective') and when to use an alternative ('For client-level database access, use list_client_databases instead'). It also includes a prerequisite ('Requires Application API key'), providing clear guidance on usage context and exclusions.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe read operation. The description adds valuable context beyond annotations: it specifies authentication requirements ('Requires Application API key'), explains the dual-purpose identifiers (id for admin tools, identifier for client tools), and mentions pagination behavior. No contradictions with annotations 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 efficiently structured with three sentences: purpose, usage guidance, and behavioral details. Each sentence adds critical information without redundancy, and key points (like authentication and identifier purposes) are front-loaded for clarity.
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?
Given the tool's complexity (list operation with pagination and authentication), annotations cover safety, and the description adds context on identifiers, authentication, and usage. However, without an output schema, the description could better detail the return format (e.g., structure of server objects). It's mostly complete but has a minor 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?
Schema description coverage is 100%, with clear documentation for both parameters (page and per_page). The description adds minimal parameter-specific information beyond the schema, only mentioning 'Supports pagination' without detailing how parameters affect it. This meets the baseline for high schema coverage.
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 specific action ('List all game servers'), resource ('on the Pterodactyl panel'), and scope ('with name, status, and resource limits'), distinguishing it from sibling tools like get_server (single server) or list_allocations (different resource). It explicitly mentions what information is returned, 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('Call this first to discover server IDs and identifiers') and distinguishes between different identifiers for admin vs. client tools, helping the agent choose alternatives appropriately. It also mentions pagination support, indicating when to use parameters.
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?
The description adds valuable behavioral context beyond what annotations provide. While annotations indicate read-only and open-world operations, the description specifies that this is an 'admin action,' discloses authentication requirements ('Requires Application API key'), and mentions pagination support. It doesn't contradict the readOnlyHint=true annotation since listing is a read operation.
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 efficiently structured with four sentences that each serve distinct purposes: stating the tool's purpose, specifying return fields, providing usage guidance, and disclosing behavioral requirements. There's no redundant information, and it's front-loaded with the core functionality.
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 read-only listing tool with good annotations and full parameter documentation, the description provides excellent contextual information. It covers purpose, usage guidance, authentication requirements, and output format details. The only minor gap is the lack of an output schema, but the description compensates by specifying what fields are 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?
With 100% schema description coverage, the input schema already fully documents both parameters (page and per_page) with their descriptions, types, and constraints. The description doesn't add any additional parameter semantics beyond what's in the schema, so it meets the baseline expectation without adding extra value.
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 ('List all user accounts'), specifies the resource ('registered on the panel'), and distinguishes it from siblings by mentioning it's an 'admin action' and listing specific return fields. It explicitly differentiates from other user-related tools like 'create_user' or 'update_user' by focusing on listing rather than modifying.
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 provides explicit guidance on when to use this tool: 'Use to find user IDs needed for create_server (owner) or update_server_details.' It also specifies prerequisites: 'Requires Application API key' and 'admin action,' giving clear context for appropriate usage scenarios.
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?
Annotations provide destructiveHint=true, idempotentHint=true, and openWorldHint=true. The description adds valuable context beyond annotations: it specifies that suspension is forceful, prevents user restarts, and requires an Application API key for authorization. No contradiction with annotations.
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?
Three sentences with zero waste: first defines the action, second provides usage context and alternative, third states auth requirement. Each sentence adds critical information.
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 destructive admin tool with no output schema, the description covers purpose, usage, behavioral effects, and auth requirements well. It could mention response format or error cases, but annotations help fill gaps.
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?
Schema description coverage is 100% with a single parameter 'server_id' well-documented in the schema. The description adds no additional parameter semantics beyond what's in the schema, but the baseline is 3 when schema coverage is high.
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 ('suspend'), the resource ('server'), and qualifies it as an 'admin action'. It distinguishes from siblings like 'unsuspend_server' and 'delete_server' by specifying forceful stopping without deletion.
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?
Explicitly states when to use ('to disable a server for policy violations or billing issues') and when not to use (implies not for temporary stops). Names the alternative tool 'unsuspend_server' for re-enabling.
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?
The description adds valuable behavioral context beyond annotations: it clarifies that 'All fields are optional - only provided fields will be changed' (partial update behavior) and specifies the authentication requirement ('Requires Application API key'). While annotations already indicate destructiveHint=true and openWorldHint=true, the description provides practical implementation details that help the agent understand how to use the tool correctly.
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 efficient - three sentences that each serve distinct purposes: stating the action, explaining update behavior, and providing prerequisites. There's zero wasted text, and the most critical information (the tool's purpose) appears first.
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 destructive mutation tool with 10 parameters and no output schema, the description provides excellent context about authentication requirements, partial update behavior, and discovery prerequisites. The main gap is the lack of information about return values or error conditions, but given the comprehensive parameter documentation in the schema and clear behavioral guidance, this is reasonably complete.
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?
With 100% schema description coverage, the input schema already documents all 10 parameters thoroughly. The description doesn't add significant parameter semantics beyond what's in the schema, though it does imply the partial update behavior ('only provided fields will be changed') which relates to parameter usage. This meets the baseline expectation for high schema coverage.
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 specific action ('Update an existing environment variable on an egg') and resource ('environment variable'), distinguishing it from siblings like 'create_egg_variable' and 'delete_egg_variable'. It also specifies this is an 'admin action', adding important context about required permissions.
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 provides explicit guidance on when to use this tool ('Use list_egg_variables to find the variable_id') and prerequisites ('Requires Application API key'). It also distinguishes it from the 'list_egg_variables' sibling tool for discovery purposes.
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?
Annotations provide destructiveHint=true and openWorldHint=true, but the description adds valuable behavioral context: it explains the partial update behavior ('Only specify the fields you want to change - current values are preserved for unspecified fields'), the timing of changes ('Changes take effect after server restart'), and the authentication requirement ('Requires Application API key'). These details go beyond what annotations provide 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in three sentences: the first states purpose and scope, the second explains behavioral details, and the third provides usage guidelines and prerequisites. Every sentence adds essential information with zero wasted words, making it front-loaded and highly readable.
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 destructive mutation tool with 11 parameters and no output schema, the description does well by covering purpose, behavioral traits (partial updates, restart requirement), authentication needs, and sibling differentiation. However, it doesn't describe the return value or error conditions, which would be helpful given the complexity. The annotations provide safety context, making this reasonably complete but not exhaustive.
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?
With 100% schema description coverage, the input schema already documents all 11 parameters thoroughly. The description mentions the types of resources being updated (memory, CPU, etc.) which aligns with the schema but doesn't add significant semantic value beyond what's already in the parameter descriptions. This meets the baseline expectation for high schema coverage.
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 specific action ('Update a server's resource limits') and enumerates the exact resources being modified (memory, CPU, disk, swap, IO weight, CPU pinning, and feature limits). It explicitly distinguishes this tool from its sibling 'update_server_details' which handles metadata changes, providing clear differentiation.
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 provides explicit guidance on when to use this tool versus alternatives: 'For server metadata (name, owner), use update_server_details.' It also specifies prerequisites: 'Requires Application API key' and indicates this is an 'admin action,' establishing clear context and exclusions.
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?
The description adds valuable behavioral context beyond annotations: it specifies that this is an 'admin action' requiring 'Application API key,' which clarifies authentication needs. It also explains the partial update behavior ('Only specify the fields you want to change - current values are preserved'). Annotations indicate destructiveHint=true and openWorldHint=true, which the description doesn't contradict but supplements with practical details.
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 front-loaded with the core purpose, followed by key behavioral details and usage guidelines in three concise sentences. Each sentence adds essential information without redundancy, making it efficient and well-structured for quick comprehension.
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?
Given the tool's complexity as a destructive update operation with no output schema, the description provides strong contextual completeness: it covers purpose, usage guidelines, authentication requirements, and update behavior. However, it doesn't detail potential side effects or error conditions, which could be useful for a destructive tool, leaving a minor 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?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description mentions the fields that can be updated ('name, description, owner, or external ID'), which aligns with the schema but doesn't add significant semantic value beyond it. The baseline of 3 is appropriate as the schema handles parameter documentation effectively.
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 ('Update'), the resource ('server's metadata'), and the specific fields that can be modified ('name, description, owner, or external ID'). It distinguishes this tool from sibling update_server_build by specifying that resource limits should be handled elsewhere, making the purpose specific and differentiated.
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 provides explicit guidance on when to use this tool versus alternatives: it states 'For resource limits, use update_server_build' and clarifies that this is for 'admin action' requiring 'Application API key.' It also specifies that only fields to be changed should be provided, with current values preserved for unspecified fields, offering clear usage context.
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?
The description adds valuable behavioral context beyond what annotations provide. While annotations indicate destructiveHint=true and openWorldHint=true, the description clarifies this is an 'admin action' with specific API key requirements, explains the partial update behavior (preserving unspecified fields), and notes the restart requirement for changes to take effect. No contradiction with annotations exists.
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 perfectly concise and well-structured in three sentences. Each sentence serves a distinct purpose: stating the tool's function, explaining the partial update behavior, and providing critical implementation details (restart requirement and authentication). There is zero wasted verbiage.
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 destructive mutation tool with no output schema, the description provides excellent context about authentication requirements, partial update behavior, and when changes become effective. It could potentially mention what happens if invalid values are provided or error conditions, but given the comprehensive annotations and schema coverage, it's largely complete for agent usage.
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?
With 100% schema description coverage, the input schema already documents all parameters thoroughly. The description adds minimal parameter semantics beyond the schema - it mentions the three configurable fields (startup, image, egg) and the partial update approach, but doesn't provide additional syntax or format details. This meets the baseline expectation when schema coverage is complete.
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 specific action ('Update a server's startup configuration') and identifies the exact resources that can be modified ('startup command, Docker image, or egg template'). It distinguishes this from sibling tools like update_server_build or update_server_details by focusing specifically on startup configuration.
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 provides explicit usage guidance: it specifies this is 'admin action' and 'Requires Application API key,' indicating permission requirements. It also explains when changes take effect ('Changes take effect after server restart') and provides a key behavioral guideline ('Only specify the fields you want to change - current values are preserved for unspecified fields').
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?
The description adds valuable behavioral context beyond what annotations provide. While annotations indicate destructiveHint=true and openWorldHint=true, the description clarifies that this is an 'admin action' and specifies authentication requirements ('Requires Application API key'). It doesn't fully describe rate limits or error behaviors, but provides important operational context not captured in annotations.
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 perfectly concise with three sentences that each serve distinct purposes: stating the tool's function, providing usage guidance, and specifying authentication requirements. There's no wasted language, and the most critical information appears first.
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 destructive mutation tool with no output schema, the description provides strong context about prerequisites, authentication, and admin requirements. It doesn't describe the return format or error conditions, but given the comprehensive parameter documentation in the schema and the behavioral context provided, it's mostly complete for agent usage.
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?
With 100% schema description coverage, the input schema already documents all parameters thoroughly. The description mentions the same parameters ('username, email, password, or admin status') but doesn't add meaningful semantic context beyond what's already in the schema descriptions. The baseline score of 3 is appropriate when the schema does the heavy lifting.
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 specific action ('Update an existing user account's details') and identifies the exact resources that can be modified ('username, email, password, or admin status'). It distinguishes this tool from sibling tools like 'create_user' and 'get_user' by specifying it's for updating existing users rather than creating new ones or retrieving information.
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 provides explicit guidance on when to use this tool ('Use list_users or get_user to find the user ID first') and identifies specific alternative tools for those prerequisite steps. It also specifies a key constraint ('admin action') that indicates when this tool should be used versus when it might not be appropriate.
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?
Annotations already indicate readOnlyHint=true and openWorldHint=true, but the description adds valuable context: 'Requires Application API key' (authentication requirement), 'admin action' (permission level), and details about the return format ('complete egg configuration including variables, install script, and Docker settings in the standard Pterodactyl egg export format'). This significantly enhances behavioral understanding beyond annotations.
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?
Three sentences with zero waste: first states purpose and context, second details return format, third provides prerequisite guidance. Every sentence adds value, and the structure is front-loaded with the core functionality.
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 read-only tool with full schema coverage and no output schema, the description is complete: it explains what the tool does, when to use it, authentication requirements, return format details, and how to obtain parameters. The annotations cover safety aspects, and the description fills in the remaining contextual gaps effectively.
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?
Schema description coverage is 100%, with both parameters clearly documented in the schema itself. The description references the parameters indirectly ('Use list_nests and list_eggs to find the nest_id and egg_id') but doesn't add semantic meaning beyond what the schema already provides. Baseline 3 is appropriate when schema does the heavy lifting.
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 specific action ('Export an egg as JSON'), the resource ('egg'), the purpose ('can be imported into another Pterodactyl panel'), and distinguishes it from siblings like 'import_egg' (which does the reverse) and 'get_egg' (which likely returns different information). The admin action context further clarifies its scope.
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?
Explicit guidance is provided: 'Use list_nests and list_eggs to find the nest_id and egg_id' tells the agent exactly how to obtain required parameters. It also distinguishes from 'import_egg' (the inverse operation) and implies this is for administrative backup/migration rather than regular data retrieval like 'get_egg'.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe read operation with potentially large results. The description adds valuable context about authentication requirements ('Requires Application API key') and specifies it's an 'admin action', which provides additional behavioral insight beyond what annotations provide.
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?
Three tightly-packed sentences with zero waste: first states purpose and return data, second provides usage guidance and sibling relationship, third specifies authentication requirement. Every sentence adds essential information.
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 tool with good annotations, the description provides excellent context about purpose, usage, authentication, and relationship to other tools. The only minor gap is lack of output schema, but the description specifies what data is returned (egg ID, name, description, Docker images, startup command).
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?
With 0 parameters and 100% schema description coverage, the baseline would be 4. The description appropriately doesn't discuss parameters since there are none, and instead focuses on what the tool returns and its purpose.
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 ('List') and resource ('available eggs/server templates'), specifies it's an admin action, and distinguishes from siblings by mentioning its use for finding egg IDs needed for create_server. It provides concrete examples of common eggs (Minecraft, Rust, Terraria).
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?
Explicitly states when to use ('Use to find the egg ID needed for create_server') and provides a clear alternative context by mentioning a specific sibling tool (create_server). Also specifies prerequisites ('Requires Application API key').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint=true, but the description adds significant behavioral context beyond that: it specifies the action is 'permanent' and 'cannot be undone,' warns about impact on existing servers, states it 'Requires Application API key' (auth requirement), and clarifies it's an 'admin action.' This enriches the agent's understanding without contradicting annotations.
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 front-loaded with the core action and warning, followed by usage guidance and auth requirement. Every sentence adds value: the first states purpose and admin context, the second warns of consequences, the third emphasizes irreversibility, the fourth gives usage tip, and the fifth specifies auth. No wasted words.
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 destructive tool with annotations (destructiveHint=true) but no output schema, the description provides complete context: it covers purpose, guidelines, behavioral risks (permanence, server impact), auth needs, and verification steps. This compensates for the lack of output schema by ensuring the agent understands the tool's implications fully.
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?
Schema description coverage is 100%, with clear descriptions for nest_id and egg_id. The description does not add meaning beyond the schema (e.g., it doesn't explain parameter relationships or usage nuances). Baseline 3 is appropriate since the schema adequately documents parameters.
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 specific action ('permanently delete'), resource ('an egg/server template'), and scope ('from a nest'), distinguishing it from sibling tools like delete_egg_variable or delete_server. It explicitly mentions this is an 'admin action,' further clarifying its administrative nature.
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 provides explicit guidance on when to use this tool: 'Use get_egg to verify the egg before deleting.' It also warns about consequences ('Servers currently using this egg will NOT be deleted but may not start correctly'), indicating when not to use it carelessly. No direct alternatives are named, but the context implies verification tools like get_egg.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint=true and openWorldHint=true, but the description adds significant context: 'This is permanent and cannot be undone' clarifies the irreversible nature, and 'Requires Application API key' specifies authentication needs. These details go beyond annotations, enriching behavioral understanding without contradiction.
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 front-loaded with the core action, followed by critical warnings and prerequisites in three concise sentences. Each sentence adds value: purpose, permanence warning, and usage guidance, with zero wasted words.
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?
Given the tool's destructive nature, annotations cover safety (destructiveHint), and the description adds essential context like permanence and auth requirements. With no output schema, the description doesn't need to explain return values, making it complete for this admin deletion tool.
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?
Schema description coverage is 100%, with each parameter documented (e.g., 'Nest ID that contains the egg'). The description adds no additional parameter semantics beyond referencing 'variable_id' from 'list_egg_variables'. Baseline 3 is appropriate as the schema fully covers parameters.
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 specific action ('Delete an environment variable from an egg') with the resource identified ('egg variable'). It distinguishes from siblings like 'delete_egg' (different resource) and 'update_egg_variable' (different action), providing precise verb+resource differentiation.
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?
Explicit guidance is provided: 'Use list_egg_variables to find the variable_id' indicates a prerequisite step, and 'admin action' plus 'Requires Application API key' specify access requirements. This clearly tells when and how to use this tool versus alternatives like 'list_egg_variables' for discovery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations. While annotations indicate destructiveHint=true and openWorldHint=true, the description elaborates on the specific destructive effects ('wipes ALL server files', 'permanently deleted'), mentions prerequisites ('Requires Application API key'), and advises on a precautionary step ('Consider create_backup'). This provides actionable insights not covered by annotations.
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 front-loaded with the core action and warning, followed by critical details and prerequisites. Every sentence adds value: the first states the purpose, the second details the destructive impact, the third advises backup consideration, and the fourth specifies authentication requirements. There is no redundant or wasted text.
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?
Given the tool's high complexity (destructive admin action) and lack of output schema, the description is complete enough. It covers the purpose, severe consequences, prerequisites, and a safety recommendation. The annotations provide additional structured hints, but the description fills in critical behavioral gaps, making it sufficient for informed use.
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 100% description coverage, with the single parameter 'server_id' well-documented in the schema. The description does not add any additional semantic information about parameters beyond what the schema provides, such as format or usage examples. This meets the baseline score of 3 for high schema coverage.
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 specific action ('reinstall a server's egg/template') and identifies it as an 'admin action', which distinguishes it from non-admin tools like list_servers or update_server_details. It explicitly mentions the resource (server) and the scope (egg/template reinstallation), avoiding tautology with the tool name.
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 provides explicit guidance on when to use this tool ('admin action') and when not to use it without precautions ('Consider create_backup before proceeding'). It also implicitly suggests alternatives by warning about data loss, though it doesn't name specific sibling tools like create_backup directly. The context is clear and includes exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint=true, but the description adds significant context beyond this: it specifies what gets destroyed (files, databases, backups), emphasizes permanence ('cannot be undone'), mentions removal from the panel, and notes the admin/API key requirement. This enriches the agent's understanding of the tool's behavior and risks.
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 front-loaded with critical information (permanent deletion, warning), uses no wasted words, and structures key points efficiently in a single sentence. Every phrase adds value, such as specifying data types and prerequisites.
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?
Given the tool's high complexity (destructive action) and lack of output schema, the description is complete: it covers purpose, risks, prerequisites, and behavioral details. Annotations support this with destructiveHint, and no output schema means the description doesn't need to explain return values, making it well-rounded for agent use.
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?
Schema description coverage is 100% with a clear parameter description, so the baseline is 3. The description adds no direct parameter information, but it implicitly reinforces the server_id's role by mentioning 'server' deletion. This provides slight additional context, raising the score slightly above baseline.
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 ('permanently delete') and resource ('a server and ALL its data'), distinguishing it from siblings like suspend_server or reinstall_server by emphasizing complete removal. It specifies the scope includes files, databases, and backups, making the purpose explicit and distinct.
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?
It provides explicit guidance on when to use ('admin action', 'Requires Application API key') and when not to use without caution ('Consider create_backup before proceeding'). It distinguishes from less destructive alternatives by highlighting irreversible deletion, though it doesn't name specific sibling tools like suspend_server as alternatives.
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:

[![pterodactyl-mcp MCP server](https://glama.ai/mcp/servers/mikketa/pterodactyl-mcp/badges/card.svg)](https://glama.ai/mcp/servers/mikketa/pterodactyl-mcp)

Score Badge

Copy to your README.md:

[![pterodactyl-mcp MCP server](https://glama.ai/mcp/servers/mikketa/pterodactyl-mcp/badges/score.svg)](https://glama.ai/mcp/servers/mikketa/pterodactyl-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/mikketa/pterodactyl-mcp'

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