Skip to main content
Glama
Sign In

Meridian

by ai.the-meridian
OverviewDiscussions(2)Admin

List Deployments

deployments_list
Read-only

Lists an app's recent deployments with status and timing: deployment_id, environment_id, trigger, git_sha, git_ref, pr_number, status, current_step, build_step (built, reused when an existing image was deployed: a redeploy of an already-built commit or a promote, none for a rollback, null until a build starts), error_code and error_message (only present for a failed deployment), started_at/finished_at, and the deployer who triggered it (user_id/name/email; null for GitHub-push deploys). Takes the app_id returned by apps_list. Optionally scope to one environment_id (from environments_list), filter by status, and cap the result with limit (default 20, maximum 100). Use deployment_get for a single deployment's full detail, events, and log URLs.

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>"
    },
    "name": "deployments_list"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of deployments to return. Default 20, maximum 100.
app_idYesThe app uuid returned by `apps_list`.
statusNoFilter to a single status: queued, building, deploying, verifying, succeeded, failed, cancelled.
environment_idNoScope to a single environment uuid returned by `environments_list`. Omitted: deployments across every environment for the app.
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 readOnlyHint=true and destructiveHint=false, so safety is covered; the description goes further by defining field semantics that cannot be inferred elsewhere: build_step values ('built', 'reused' for redeploy/promote, 'none' for rollback, null until build starts), error_code/error_message present only on failure, and deployer null for GitHub-push deploys. Remaining gap: no statement about result ordering beyond the word 'recent' or about pagination past the limit cap.

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-loaded with purpose then return-field inventory in a compact block, with usage and the alternative tool at the end. The field enumeration is long but earns its place because there is no output schema; a few parenthetical explanations are dense but not 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 compensates by enumerating return fields and their conditional presence, and it covers the single required parameter's source. Minor incompleteness: no explicit sort order (just 'recent') and no indication of whether more results than the limit exist or how to page.

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%, so the schema already carries default/max for limit, status values, environment scoping, and organization_id resolution. The description restates limit's default and max and environment omitting behavior without adding syntax or format detail, so it lands at the baseline for a fully documented schema.

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+resource ('Lists an app's recent deployments') and immediately enumerates the returned fields, so the agent knows exactly what comes back. It explicitly contrasts itself with deployment_get for single-deployment detail, making sibling selection unambiguous.

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 explicit prerequisites and provenance for inputs ('Takes the app_id returned by apps_list', environment_id 'from environments_list'), states optional narrowing knobs (environment_id, status, limit), and names the alternative tool plus the condition selecting it ('Use deployment_get for a single deployment's full detail').

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