InfraNest

Deploys to a monitor or server

list_deploys

Read-onlyIdempotent

The deploys linked to one monitor (monitor) or server (server) between from and to; the window defaults to the 24 hours before to, which defaults to now. Also lists the repositories linked to it. Each deploy carries its verification: after a successful production deploy (the repository default branch, an environment GitHub or its name marks as production, or as the production setting of the repository says) its monitors are checked more often for an hour, then that hour is compared with the hour before it — state (watching until until, then done; cut_at when a newer deploy reached one of its monitors first and ended the window there for that monitor), verdict (better, unchanged, worse or insufficient; with reason: plan_interval and the plan interval in plan_interval_seconds when the plan check interval left too few checks for a verdict), a summary of the p95 response time and failure share, and per monitor and location the numbers on both sides. For a monitor, only what the deploy did to that monitor; null when the deploy was not verified. Here, pass monitor_id or server_id. For "did we ship something just before this broke", pass the window around an incident's start; deploy_changes shows what a deploy contained. Each deploy's verification.verdict says whether it made the monitor worse (p95 and failed checks per location, the hour after against the hour before).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_deploys"
  }
}

Input Schema

Name	Required	Description
`to`	No	Up to this time (ISO 8601); default now.
`from`	No	From this time (ISO 8601); default 24 hours before `to`.
`server_id`	No	The server whose deploys to list, from list_servers. Pass this or monitor_id.
`monitor_id`	No	The monitor whose deploys to list, from list_monitors. Pass this or server_id.
`organization_id`	No	The organization to read. Leave it out when the token reaches only one.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 30, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered; the description adds genuine behavioral context about how verification works (monitors checked more often for an hour, then compared against the preceding hour, and when a window is cut short). Most of the remaining text describes return-value structure rather than invocation behavior, which is useful but less about how to call the tool.

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?

Front-loaded with the core purpose, but the body is a single sprawling run of sentences with deep nested parentheses (the production-deploy definition, the state/verdict enumeration, per-monitor/per-location detail) that is hard to parse on first read. Substantial output detail is packed in where a shorter summary plus the field names would suffice.

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?

There is no output schema, so the description carries the burden of explaining the verification object (state, until, cut_at, verdict, reason, summary) and does so thoroughly. It is complete for an agent to call and interpret results, though the density of the return explanation slightly undercuts its usefulness.

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 coverage is 100% and each parameter already documents its default and provenance (from list_servers / list_monitors). The description restates the from/to defaults and the monitor_id-or-server_id rule without adding syntax or format detail beyond the schema, so the 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?

Opens with a specific verb and resource ('The deploys linked to one monitor or server between from and to') and scopes the resource precisely. It also distinguishes itself from the sibling deploy_changes by stating that deploy_changes shows what a deploy contained, while this tool lists deploys and their verification outcomes.

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?

Gives an explicit use case ('did we ship something just before this broke' → pass the window around an incident's start) and names the alternative tool for the adjacent question. It also states the selection condition between the two id parameters ('Here, pass monitor_id or server_id').

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.