Skip to main content
Glama
Sign In

InfraNest

by io.infranest
OverviewDiscussionsAdmin

What a deploy changed

deploy_changes
Read-onlyIdempotent

The commits and pull requests since the previous successful deploy to the same place, each pull request with its author and the files it touches (up to 50; changed_files is the full count). Returns first: true when there is no earlier deploy to compare with, and unavailable: true when GitHub could not say. verification says whether the deploy made its monitors worse, as in the deploy list. The commits between this deploy and the one before it on the same target. The first deploy on record has nothing to compare against and says so.

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": {
      "deploy_id": "<deploy_id>"
    },
    "name": "deploy_changes"
  }
}

Input Schema

NameRequiredDescriptionDefault
deploy_idYesThe deploy id, from list_deploys or an incident_timeline's deploys.
organization_idNoThe organization to read. Leave it out when the token reaches only one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/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, so the description earns credit for adding real behavioral context: the 50-file cap with `changed_files` as the full count, the `first: true` no-predecessor case, and the `unavailable: true` failure case when GitHub cannot answer. It stops short of explaining what `verification` values mean or the overall response shape, but this is well beyond annotation restatement.

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 lead sentence is well front-loaded and dense, but the description then repeats itself: 'The commits between this deploy and the one before it on the same target' restates the opening clause, and 'The first deploy on record has nothing to compare against and says so' duplicates the `first: true` sentence. Roughly a third of the text is redundant.

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 carry the return-value burden and largely does: it names the payload (commits, PRs, authors, files, counts) and the edge-case flags. Minor gap is the unspecified semantics of `verification` and the exact structure of the commit list, but an agent has enough to call and interpret it.

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 both parameters are documented in the schema, including the provenance of `deploy_id` and the optional `organization_id`. The description adds no additional parameter-level meaning, 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?

Opens with a concrete resource and scope: commits and pull requests since the previous successful deploy to the same target, including PR authors and touched files. An agent can tell this apart from list_deploys because it references 'the deploy list' and 'an incident_timeline's deploys' as the source of the id, though it never explicitly says 'use list_deploys first'.

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 implied by the phrasing ('since the previous successful deploy', 'as in the deploy list') but there is no explicit when-to-use/when-not guidance or named alternative. The agent must infer that this is the drill-down after picking a deploy id.

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