Skip to main content
Glama

Get Deployment

deployment_get
Read-only

Returns a single deployment's detail: the same fields as deployments_list, plus finished, steps, recent events and the build_logs_url/runtime_logs_url GCP Console deep links. Takes the app_id returned by apps_list and the deployment_id returned by deployments_list/deployment_create/deployment_rollback.

To follow a deploy to its end, pass wait_until: "finished": the call waits up to 50 seconds for the deployment to finish, then returns its current state. finished is true once the status is terminal (succeeded, failed, cancelled) and a failure's error_message is final; while it is false, call again with wait_until: "finished". Do not sleep between calls. waited_seconds says how long this call waited. error_message_pending is true while a failed deployment's reason is still waiting for the container's own output.

steps lists the phases queued, build, deploy, verify, each with status (pending, running, succeeded, failed, skipped, cancelled), started_at, finished_at, duration_seconds and detail (the Dockerfile instruction the build ran last, or the phase's latest event).

events are orchestration steps and build/release/container log lines, each with type, level, message, created_at. They come newest first by default (order: "desc") and limit keeps the latest ones (default 100, maximum 1000); order: "asc" returns the oldest first. Build boilerplate (git checkout advice, Docker credential warnings, BuildKit's builder dump and layer progress, npm update notices) is left out and counted in boilerplate_filtered; pass include_noise: true to get every line.

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_get"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of log events to return. Default 100, maximum 1000.
orderNo`desc` (default): newest events first, `limit` keeps the latest. `asc`: oldest first.
app_idYesThe app uuid returned by `apps_list`.
wait_untilNo`finished`: wait up to 50 seconds for the deployment to finish before answering. Omitted: answer at once.
deployment_idYesThe deployment uuid returned by `deployments_list`.
include_noiseNoReturn build boilerplate lines too. Default false.
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.7/5.0
Behavior5/5

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

Annotations already say readOnlyHint=true and non-destructive, and the description adds far more: the 50-second wait cap, which statuses are terminal, waited_seconds, error_message_pending semantics, newest-first default with limit keeping the latest, and boilerplate filtering counted in boilerplate_filtered.

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?

Purpose and required inputs are front-loaded, and the polling contract occupies a clear paragraph. It is on the long side, enumerating step statuses and event fields in detail that is useful reference but not strictly needed for tool selection.

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?

Covers the polling loop, terminal statuses, event ordering and noise filtering for a 7-parameter tool lacking an output schema. The only meaningful gap is organization_id, whose behavior appears in the schema but not the narrative.

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%, but the description still adds real meaning: the polling loop semantics of wait_until, and how include_noise interacts with boilerplate_filtered and order/limit. It leaves organization_id's slug-resolution behavior to the schema alone.

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 and resource ('Returns a single deployment's detail') and explicitly distinguishes itself from the sibling lister by noting it returns the same fields as `deployments_list` plus finished, steps, events, and log URLs.

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?

Tells the agent exactly where required IDs come from (apps_list, deployments_list/create/rollback) and gives explicit alternative behavior: omit wait_until to answer at once, or set it to 'finished' and re-call while finished is false, with 'Do not sleep between calls.'

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources