Skip to main content
Glama

DeployProject

Destructive

Deploys a new version of a project and answers as CreateProject does: files written over its own (/.env, /compose.yaml, a source file), x_pethost (name, routes, password), mount_volume, a new archive (upload_id), a commit, or an earlier deploy's files again (rollback_deploy_id). compose.yaml rules: CreateProject's.

It builds build: images, pulls missing ones, runs compose up on the whole project and waits until each service runs (healthy, if it has a healthcheck) or each job exits 0, and until each routed service listens on its route's port (up to 15 s: one that does not is the project's SERVICE_PORT_CLOSED problem, its route answering 502, not a failed deploy). So it also starts stopped services, reruns jobs, recreates changed services and those bind-mounting project files, and fails on an unhealthy service. While Project.x_pethost_applies_at_once, a version differing only in x-pethost (or not at all) applies at once, restarting nothing but a service whose published port a route takes or leaves. Any other deploy applies its routes and password as it ends: to hide new content from its first second, set the password first, in a call of its own, then deploy the content.

A commit other than GithubSource.newest_commit turns auto_deploy off (pinned), even if it fails; only set_source turns it back on.

NOT_FOUND = no such project, or no such kept deploy. ABORTED = base_deploy_id is not Project.deploy_id: reread, redo. FAILED_PRECONDITION = as CreateProject, or commit not on the branch. RESOURCE_EXHAUSTED = too many or too large files: send them with CreateTransfer. ALREADY_EXISTS = operation_id started another kind of operation. When it FAILED, Operation.made_current says whether the files were applied: then fix them, or roll back.

Input Schema

NameRequiredDescriptionDefault
filesNoWritten in order over the current files, or over the new version's: e.g. [{path: "/.env", text: "…"}] writes that file whole, and the files not named stay. With no new version pethost.compose.yaml is refused: write /compose.yaml. github: only /.env. None = redeploy.
commitNogithub project: a commit of its branch (SHA, ≥7 chars), from ListCommits.
upload_idNofiles project: an archive from CreateTransfer; replaces all files but /.env and x-pethost.
x_pethostNoEdits x-pethost by part, after `files`: metadata by key; routes all at once. x-pethost as data. Absent parts stay.
project_idNo
mount_volumeNoNot with upload_id, or github. Adds `<volume>:<container_path>` to the service, declaring the volume if needed.
operation_idNoFor a safe retry: the same id returns the first call's operation and starts nothing. [A-Za-z0-9][A-Za-z0-9._-]*, ≤128 chars; empty = generated.
wait_secondsNoSeconds to wait for the deploy's end, ≤45. Absent = 45; 0 = answer once it started. Still IN_PROGRESS then: GetOperation waits on.
newest_commitNogithub project: true = GithubSource.newest_commit, read now.
base_deploy_idNoProject.deploy_id as you read it: ABORTED if the project was deployed since. Empty = no check.
timeout_secondsNoFor the whole deploy, builds included; 0 = default.
rollback_deploy_idNofiles project, a rollback: the operation_id of an earlier deploy with files_kept (Project.operations). Its files return as a new version; /.env, x-pethost and volumes stay.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations flag destructive/openWorld but the description carries substantive extra detail: what `files` overwrite, that stopped services are started and containers recreated, the wait logic (healthcheck/job-exit/route-listening up to 15s), the SERVICE_PORT_CLOSED vs 502 distinction, the at-once x-pethost path, the pinned-commit side effect on auto_deploy, and per-error-code semantics including Operation.made_current. This goes well beyond the annotation safety profile.

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 purpose is front-loaded, but the body is an extremely dense, run-on wall of text with heavy abbreviations and cross-references ('answers as CreateProject does') that strains comprehension. Given the tool's complexity the length is defensible, but the structure does not earn the density.

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?

For a 12-parameter, nested, mutation-heavy tool with no output schema, the description covers lifecycle, waiting, error codes, and interdependencies (auto_deploy pinning, route/password timing) well. Return-value details are omitted, but they are largely delegated to CreateProject's answer shape, leaving only minor gaps.

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 92% and the schema itself documents every parameter and nested field in detail, so the baseline is 3. The prose adds some cross-parameter meaning (operation_id retry semantics, base_deploy_id abort behavior, rollback_deploy_id scope) but much of the rest defers to 'CreateProject's rules' rather than adding new parameter semantics.

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?

The opening sentence states a specific verb and resource ('Deploys a new version of a project') and immediately bounds the operation ('answers as CreateProject does'), so the agent knows it acts on an existing project rather than creating one. The subsequent enumeration of inputs (files, x_pethost, mount_volume, upload_id, commit, rollback) makes the scope concrete and distinguishable from CreateProject.

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?

It gives explicit sequencing and preconditions: set the password in a separate call before deploying to hide content, write /compose.yaml when no new version exists, and use base_deploy_id then 'reread, redo' on ABORTED. It names alternatives and their selecting conditions ('GetOperation waits on' when still IN_PROGRESS, CreateTransfer for oversized files, set_source to re-enable auto_deploy), which is exactly the when/when-not/alternative guidance the dimension asks for.

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