Skip to main content
Glama
hcloud MCP Server

hcloud MCP Server

by binrogithub

hcloud_show_er_router

hcloud_show_er_router
Read-onlyIdempotent

Get details of a specific ER (Enterprise Router) router

Instructions

Get details of a specific ER (Enterprise Router) router

Input Schema

NameRequiredDescriptionDefault
regionYesRegion
router_idYesER router ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

C2.9/5.0
Behavior2/5

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is fully covered by structured data. The description adds nothing behavioral beyond that — no indication of what 'details' comprise, what happens on an unknown router_id or region, or whether cross-region lookups behave differently under the open-world hint.

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

Conciseness4/5

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

A single short sentence with the resource front-loaded and no wasted words. It is efficient, though its brevity borders on under-specification rather than true crispness.

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

Completeness3/5

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

For a simple two-parameter read tool this covers the minimum, and the absence of an output schema means return-value explanation is not strictly required. However, a 'show details' tool would benefit from at least a hint about the kind of detail returned (routes, attachments, status) and how to source a valid router_id.

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 both parameters (region, router_id) are already documented in the schema, and the baseline of 3 applies. The description does not add any semantics such as ID format or region scoping rules.

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

Purpose4/5

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

The description states a specific verb ('Get details') and a specific resource ('a specific ER (Enterprise Router) router'), and usefully expands the acronym ER, which the name alone does not. It is distinguishable from hcloud_list_er_routers by the word 'specific', though it never names that list tool as the way to discover IDs.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no prerequisite information, and no mention that router_id must typically be obtained from hcloud_list_er_routers. An agent is left to infer the single-object vs. list distinction from the name alone.

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

Deploy Server

Other Tools