Skip to main content
Glama
Sign In
hcloud-mcp

hcloud-mcp

by Xodus-CO
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

get_server_metrics

Read-only

Retrieve CPU, disk, and network metrics for a Hetzner Cloud server over the last 30 days, with per-series summaries and optional raw time series for any time range.

Instructions

Get server metrics (last 30 days only). Output starts with a per-series summary {points,min,avg,max,last}, then the raw time_series unless include_values=false. Series: cpu → cpu (percent, per vCPU: 100 = one full vCPU, so divide by vCPU count for overall usage); disk → disk.0.iops.read/write (iop/s), disk.0.bandwidth.read/write (bytes/s); network → network.0.pps.in/out (packets/s), network.0.bandwidth.in/out (bytes/s) on the public interface. Time range: pass start+end (ISO-8601), or omit both and use last_minutes (default 60)

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>",
      "type": "<type>"
    },
    "name": "get_server_metrics"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesServer ID
endNoPeriod end, ISO-8601/RFC3339. Give with start
stepNoResolution in seconds. Omit to let the API pick (~200 samples); the API caps at 500 samples and adjusts step to fit
typeYesMetric types, e.g. ["cpu"] or ["cpu","network"]
startNoPeriod start, ISO-8601/RFC3339 (e.g. 2026-11-11T10:00:00Z). Give with end, or omit both and use last_minutes
last_minutesNoConvenience: period = now minus N minutes until now. Used only when start/end are omitted; default 60. Max 43200 (30-day retention)
include_valuesNoInclude the raw time series ([unix_ts, "value"] pairs) after the summary. Default true; set false for just the min/avg/max/last summary (much smaller output)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.1

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already establish readOnlyHint and openWorldHint, and the description adds substantial behavior beyond them: the 30-day retention cap, that output starts with a per-series {points,min,avg,max,last} summary followed by raw time_series unless include_values=false, and the exact units and naming of every series. It also clarifies the non-obvious cpu semantics (100 = one full vCPU).

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 retention constraint is front-loaded in parentheses, then output structure, then series definitions, then time-range rules. It is dense but every clause carries information an agent needs, with no repetition of schema text for its own sake.

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?

There is no output schema, so the description carries the return-value burden and does it thoroughly: summary shape, raw series format, and the include_values toggle. Combined with the annotations covering the safety profile, an agent has everything needed to call this correctly on the first attempt.

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 coverage is 100%, so the baseline would be 3; the description earns above that by adding semantics the schema does not carry, such as the cpu percent-per-vCPU interpretation and the interactive effect between include_values and output shape. The start/end vs last_minutes relationship is also restated as a single coherent rule rather than per-field text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ("Get server metrics") and immediately bounds it to the last 30 days. It also enumerates exactly which series come back for cpu/disk/network, so an agent knows the scope without opening the schema. It does not reference the sibling get_load_balancer_metrics, but the server-scoped name already makes the distinction obvious.

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?

Gives concrete selection guidance for parameters: pass start+end, or omit both and use last_minutes (default 60), and set include_values=false for a much smaller summary-only response. It does not state when to prefer this tool over sibling metric or server tools, but the usage rules it does provide are actionable and unambiguous.

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

Deploy Server

Other Tools