Skip to main content
Glama
Sign In

Meridian

by ai.the-meridian
OverviewDiscussions(2)Admin

Rollback Deployment

deployment_rollback
Destructive

Rolls back to a previously-succeeded deployment by shifting 100% of live Cloud Run traffic to its existing revision (no rebuild). deployment_id is the PRIOR SUCCEEDED deployment to restore. There is no separate release identifier. Refused with a clear error if the target deployment did not succeed, has no runtime revision to restore, or its environment currently has another deployment in progress. Returns the newly-created rollback deployment (trigger rollback), which becomes the current live deployment for that environment.

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": {
      "app_id": "<app_id>",
      "deployment_id": "<deployment_id>"
    },
    "name": "deployment_rollback"
  }
}

Input Schema

NameRequiredDescriptionDefault
app_idYesThe app uuid returned by `apps_list`.
deployment_idYesThe prior succeeded deployment to roll back to, from `deployments_list`.
organization_idNoAn organisation uuid or slug. When supplied, `app_id` is resolved within that organisation and may be a slug instead of a uuid, mirroring the Meridian web app.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and openWorldHint=true; the description adds substantial context beyond that: no rebuild, traffic-shift semantics, three explicit refusal conditions, and the fact that a new deployment with trigger `rollback` is created as the current live deployment. It stops short of covering authorization requirements or whether the rollback is itself reversible.

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?

Front-loads the core action and mechanism, then the parameter clarification, then failure modes, then the return value. It is dense and every sentence carries information; the slight length is justified by the failure-mode enumeration.

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?

No output schema exists, so explaining the returned rollback deployment is valuable and present, as are the refusal conditions. Missing pieces are authorization requirements and whether the newly created rollback deployment can itself be rolled back—minor for a 3-parameter mutation tool with annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, giving a baseline of 3, but the description adds genuine meaning for deployment_id by clarifying it must be a previously succeeded deployment to restore and that no separate release identifier exists. It adds nothing about organization_id or app_id resolution, which the schema already handles.

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 verb (rolls back) and resource (deployment), plus the mechanism: shifting 100% of live Cloud Run traffic to an existing revision with no rebuild. This clearly distinguishes it from siblings like deployment_create and deployment_get.

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

Usage Guidelines4/5

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

Explicitly defines deployment_id as the PRIOR SUCCEEDED deployment and notes there is no separate release identifier, which prevents a common misuse. It also lists refusal conditions, giving clear usage context, but does not explicitly route the agent to alternatives such as deployment_create.

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

All Meridian toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources