Skip to main content
Glama
Sign In

InfraNest

by io.infranest
OverviewDiscussionsAdmin

Get a server

get_server
Read-onlyIdempotent

One server with its volumes, tags, cost breakdown and what its provider lets InfraNest do with it. Also says whether it can be renamed, whether its monitoring agent’s readings are being refused, and in reconnect_for which of server_rebuild, server_restore and root_password_reset its signed-in provider connection must reconnect to allow (always empty for an API token, whose permissions cannot be read). One server in full: provider, addresses, size, tags, agent and monitoring state. For how it is doing use server_attention; for its readings server_metrics or server_metric_history.

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": {
      "server_id": "<server_id>"
    },
    "name": "get_server"
  }
}

Input Schema

NameRequiredDescriptionDefault
server_idYesThe server id, from list_servers or the number of a search hit server:N.
organization_idNoThe organization to read. Leave it out when the token reaches only one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / server_id / description
      Previous value: -"The server id, from list_servers."New value: +"The server id, from list_servers or the number of a search hit server:N."
  2. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already cover readOnly/idempotent/non-destructive, so the safety profile is free. The description goes further with non-obvious domain behavior: reconnect_for lists which operations the signed-in provider connection must reconnect for, and is always empty for API tokens whose permissions cannot be read. It does not cover failure modes (unknown server_id, cross-organization access), which keeps it off a 5.

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

Conciseness3/5

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

The content is front-loaded and useful, but the opening ('One server with its volumes, tags, cost breakdown...') and the later 'One server in full: provider, addresses, size, tags, agent and monitoring state' restate the same return inventory twice. A single consolidated return summary plus the sibling routing would be tighter.

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

Completeness4/5

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

With no output schema, the description must describe return content, and it does: provider, addresses, size, tags, agent and monitoring state, plus the reconnect_for nuance. What is missing is edge-case behavior for an invalid or inaccessible server_id, which matters for a lookup tool keyed on an integer 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% and both parameters are documented there, so the schema carries the semantics. The description mentions reconnect_for, but that is a response field rather than a parameter, so it adds no parameter meaning beyond the schema. 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?

States a specific resource (one server) and enumerates what it returns: volumes, tags, cost breakdown, provider permissions, rename eligibility, monitoring-agent refusal state, and reconnect_for. It also explicitly separates itself from server_attention, server_metrics and server_metric_history, so an agent can pick it without opening a schema.

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?

Names three alternative tools and the condition that selects each ('For how it is doing use server_attention; for its readings server_metrics or server_metric_history'). That is explicit routing guidance, not implied usage.

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

All InfraNest toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources