Skip to main content
Glama

hosts_get

Read-only

Fetch a host from a Remnawave VPN panel by UUID to inspect its configuration and metadata.

Instructions

Get a host by UUID

Input Schema

NameRequiredDescriptionDefault
uuidYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.0.0

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond the name - no mention of behavior when the UUID is unknown (error vs empty), permissions required, or whether the response includes tags/config relationships. For a one-line description this is minimal but not contradictory.

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 five-word sentence with the key information front-loaded and zero filler. It is appropriately sized for a simple single-parameter read, though it is arguably under-specified rather than truly concise.

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 one-param read tool with annotations and no output schema, the description covers the minimum needed to invoke correctly. It lacks any error behavior, permission notes, or cross-reference to how to obtain a UUID, leaving some gaps for an agent operating among ~20 host-related siblings.

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 0%, so the description must carry the parameter meaning; it does identify the input as a host UUID, which is the essential semantic. However, it adds nothing about format expectations or the identifier's origin (e.g. from hosts_list) beyond what the name already implies.

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?

States a specific verb (Get) and resource (host) plus the lookup key (UUID), so the agent knows exactly what the call returns. It does not differentiate itself from siblings like hosts_list or hosts_get-equivalents (e.g. node_integrations_get, squads_get), but the retrieval-by-identifier intent is unambiguous.

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 guidance on when to use this versus hosts_list (enumerating hosts) or hosts_update/hosts_delete which also take a host identifier. The agent must infer the situation from the tool 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