pterodactyl-mcp

Get Pterodactyl server details

ptero_get_server

Read-onlyIdempotent

Retrieve a server's full static configuration: name, node, resource limits, ports, SFTP, Docker image, and startup command. Use to answer how a server is set up.

Instructions

Get the full configuration of one server: name, node, panel lifecycle status, resource limits, feature limits, every network allocation (ip/port/notes, and which is primary), SFTP host and port, Docker image and the resolved startup command.

Use this to answer "how is this server configured", "what ports does it have", "how much memory is it allowed", or "what is it running".

This is static configuration. It does NOT tell you whether the server is up or what it is currently consuming — use ptero_get_server_resources for that. For the ports alone, ptero_list_allocations is narrower. Note that a port being allocated does not mean a service actually bound to it; confirm that in the console log or the relevant plugin config file.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`server`	No	Server short identifier (e.g. 1a2b3c4d). Omit to use PTERODACTYL_DEFAULT_SERVER. Call ptero_list_servers to discover valid identifiers.

Output Schema

TableJSON Schema

Name	Required	Description
`name`	Yes
`node`	Yes	Name of the node hosting the server.
`uuid`	Yes
`limits`	Yes	Resource ceilings configured on the panel.
`status`	Yes	Panel lifecycle status: null when normal, else installing/install_failed/reinstall_failed/suspended/restoring_backup. This is NOT the power state — use ptero_get_server_resources for running/offline.
`identifier`	Yes
`invocation`	Yes	Resolved startup command. Redacted by the panel without startup:read permission.
`allocations`	Yes	Ports assigned to this server.
`description`	Yes
`docker_image`	Yes	Container image the server runs in.
`egg_features`	No
`is_suspended`	Yes	Suspended servers reject power and console actions.
`server_owner`	No	True when the API key owns the server rather than being a subuser.
`sftp_details`	Yes
`is_installing`	Yes
`feature_limits`	Yes
`is_transferring`	Yes	True while the server is being moved between nodes.
`is_node_under_maintenance`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 26, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read. The description adds meaningful behavioral context beyond annotations: 'This is static configuration' and the limitation that an allocated port does not imply a bound service. No contradictions.

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

Conciseness5/5

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

The description is detailed but every sentence serves a distinct purpose: the first enumerates contents, the second gives concrete use cases, the third clarifies limits and routes to siblings. Information is front-loaded and structured logically. Nothing is redundant.

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 presence of an output schema and comprehensive annotations, the description covers all necessary operational context: what data is returned, how it differs from similar tools, and the important semantic caveat about port allocations. An agent can confidently select and interpret the result without further guessing.

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% for the single 'server' parameter, which already explains the short identifier, the default via PTERODACTYL_DEFAULT_SERVER, and how to discover valid identifiers. The description adds no additional parameter-specific details beyond the schema, so the baseline 3 applies.

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 opens with a precise verb and resource ('Get the full configuration of one server') and enumerates exactly what is returned: name, node, lifecycle status, resource limits, feature limits, allocations, SFTP, Docker image, startup command. It also names the sibling tools it is not (ptero_get_server_resources, ptero_list_allocations), making selection unambiguous.

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

Usage Guidelines5/5

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

The description explicitly states when to use it ('Use this to answer...') and what it does NOT do ('does NOT tell you whether the server is up... use ptero_get_server_resources'). It also gives a narrower alternative for ports alone and a practical caveat about allocated vs. bound ports. This fully covers when-to-use and when-not-to.

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