InfraNest

What needs attention on a server

server_attention

Read-onlyIdempotent

A short summary of the server: its uptime, whether alerts are quiet and until when, and the metric trend closest to crossing its alert threshold. Fields are null when there is nothing to say. unusual lists the last 24 hours’ runs of hours that were unusual for this server at that hour of the week, one per metric: from, to, peak and peak_at, the normal range (low, typical, high) it was judged against, the weeks behind it and, when the range is a peer’s, borrowed_from. They are never sent as alerts. full_mounts lists the mounts at 90% or fuller now (mount_point, used_percent, collected_at), whether or not an alert rule watches the disk. alert_rules counts the active rules watching the server; with none, no_alert_rules says so, with the app route to add one. certificates lists the certificate problems whose fix is on this server (code, severity, the certificate_id and its route), with the key and kind of the Home item each one is, so a ticket filed from either place is the same ticket; key is null for one Home does not list. unusual lists hours that were unusual for this server at that hour of the week, each with the normal range it was judged against; say "unusually high for this hour" with those numbers. full_mounts are disks 90% full or more, reported whether or not a rule watches them. When no_alert_rules is set, nothing on this server alerts anyone: say so, and link app_url so the person can add a rule.

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": "server_attention"
  }
}

Input Schema

Name	Required	Description	Default
`server_id`	Yes	The server id, from list_servers or the number of a search hit server:N.
`organization_id`	No	The organization to read. Leave it out when the token reaches only one.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 2, 2026

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."

First observedOct 30, 2026

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive behavior, and the description adds meaningful context beyond that: fields are null when there is nothing to report, unusual runs are never sent as alerts, full_mounts are surfaced regardless of whether a rule watches the disk, and no_alert_rules means nothing alerts anyone. This is genuinely useful behavioral detail, though it stops short of noting cost or latency of the aggregation.

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

Conciseness2/5

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

The purpose is front-loaded, but the body is roughly twice as long as needed: `unusual` is explained in full twice (its fields and the "unusually high for this hour" phrasing), and `full_mounts` (90%+ mounts, reported regardless of rules) is likewise restated. Several sentences do not earn their place.

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 carries the full burden of explaining return values, and it does so field-by-field: unusual (from/to/peak/normal/weeks/borrowed_from), full_mounts, alert_rules, certificates (code/severity/certificate_id/route/key/kind). Only minor gaps remain, such as whether omitted/null sections can be distinguished from empty ones.

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 (server_id, organization_id) are documented in the schema, including the provenance hint for server_id. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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 opening sentence gives a specific verb-like framing ("a short summary of the server") and enumerates the exact contents: uptime, alert quiet status, and the metric trend closest to its threshold. That clearly separates it from siblings like get_server or server_metrics, though it never names an alternative tool explicitly.

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

Usage Guidelines3/5

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

Usage is only implied: the field descriptions suggest a triage/'what needs attention' entry point, and the closing line says to link app_url when no_alert_rules is set. There is no explicit statement of when to call this versus get_server, server_metrics, or status_overview, and no exclusions.

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

All InfraNest tools Inspect

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.