pterodactyl-mcp

Get Pterodactyl server resource usage

ptero_get_server_resources

Read-onlyIdempotent

Check a server's live power state and resource usage: memory, disk, CPU, network, and uptime. See if it's running or offline and monitor current metrics.

Instructions

Get the live power state and current resource usage of a server: whether it is running, memory and disk in use, CPU percentage, network bytes in and out, and process uptime.

Use this to answer "is the server up?", "what is the memory doing?" or "how long has it been up?". This is the tool that reports running vs offline — ptero_get_server reports panel lifecycle status, which is a different thing.

Figures are cached by the panel for about 20 seconds, so calling repeatedly in quick succession returns identical numbers; that is the cache, not a frozen server. cpu_absolute is a percentage across all cores (200 means two full cores), and compares against the limits.cpu from ptero_get_server. When the server is offline every figure is 0. This tool does not explain why something is wrong — use ptero_get_console_log for that.

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
`server`	Yes	Server short identifier these figures describe.
`uptime_ms`	Yes	Milliseconds since the process started. 0 when offline.
`disk_bytes`	Yes
`disk_human`	Yes
`cpu_absolute`	Yes	CPU percent across all cores: 100 = one full core, 200 = two cores.
`is_suspended`	Yes
`memory_bytes`	Yes
`memory_human`	Yes
`uptime_human`	Yes
`current_state`	Yes	Daemon power state: offline, starting, running, or stopping.
`network_rx_bytes`	Yes
`network_rx_human`	Yes
`network_tx_bytes`	Yes
`network_tx_human`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 26, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, and non-destructive hints, so the bar for behavioral disclosure is lower. The description adds valuable context beyond those hints: 20-second panel caching, cpu_absolute meaning across cores, comparison with limits.cpu, and zeroed metrics when offline.

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?

Every sentence serves a distinct purpose: definition, use cases, sibling differentiation, caching caveat, CPU semantics, offline behavior, and follow-up routing. The information is dense but front-loaded and stays relevant with no filler.

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

Completeness5/5

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

For a single-optional-parameter read-only tool with an output schema, the description covers the surprising behaviors an agent needs to interpret results correctly and even routes to the console-log tool for deeper diagnosis. Nothing essential is missing.

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 sole parameter 'server' is fully documented in the input schema, including how to discover valid identifiers and the default-server fallback. With 100% schema coverage, the description does not need to repeat parameter detail, so the baseline of 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 specific verb and resource: it gets live power state and resource usage metrics. It also explicitly distinguishes itself from ptero_get_server, which reports panel lifecycle status, so an agent can identify the right tool without ambiguity.

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

Usage Guidelines5/5

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

It gives concrete question patterns ('is the server up?', 'what is the memory doing?') and names the two alternatives: ptero_get_server for panel lifecycle status and ptero_get_console_log for diagnosing why something is wrong. This is explicit when-to-use and when-not-to-use guidance.

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