Skip to main content
Glama

Deploy

deploy
Destructive

Start a deploy into an existing running service: from an uploaded archive (uploadId, after its PUT), or archive as the base64 of a gzip tar for a tiny project under 1 MiB. Returns the deploy id; the deploy runs on its own. The service must already exist; a project with no server yet is ordered, not deployed.

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": {
      "serviceId": "<serviceId>"
    },
    "name": "deploy"
  }
}

Input Schema

NameRequiredDescriptionDefault
archiveNobase64 of a small .tgz (under 1 MiB); a larger project comes as uploadId
uploadIdNothe upload id, after its PUT
preflightNothe pre-flight report of the checks run on the person's machine; required: the call refuses without a passing one
serviceIdYesthe id of a service on this account

Output Schema

NameRequiredDescriptionDefault
okYes
dataNo
errorNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / archive / description
      Previous value: -"base64 of a small .tgz (under 1 MiB); larger projects use request_upload"New value: +"base64 of a small .tgz (under 1 MiB); a larger project comes as uploadId"
    • changedInput schema / properties / preflight / description
      Previous value: -"the pre-flight report from the preflight tool protocol; required: the call refuses without a passing one"New value: +"the pre-flight report of the checks run on the person's machine; required: the call refuses without a passing one"
    • changedInput schema / properties / serviceId / description
      Previous value: -"the service id from list_services"New value: +"the id of a service on this account"
    • changedInput schema / properties / uploadId / description
      Previous value: -"from request_upload, after the PUT"New value: +"the upload id, after its PUT"
  2. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the bar is lower, and the description adds real context: the call "Returns the deploy id; the deploy runs on its own," telling the agent the operation is asynchronous and to poll deploy_status rather than wait. It also states the service must pre-exist, reinforcing the refusal paths. It does not say what content of the running service is replaced by the new deploy, which is the main gap for a destructive operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense sentences with the primary mode stated first, the size-limited fallback second, and the lifecycle caveat last. No filler, and the async return behavior is front-loaded where it matters.

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 destructive, asynchronous tool with a nested preflight object and an output schema, the description covers the prerequisite, the two ingestion paths, and the fire-and-forget execution model. What remains unsaid — the effect on the currently running service and the deploy/rollback relationship — would be valuable but is partly recoverable from the sibling rollback and deploy_status.

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 every parameter, including the nested preflight report, is already documented in structured fields. The description restates the uploadId-vs-archive split and adds the "after its PUT" sequencing hint, but adds nothing for preflight or serviceId beyond the schema. Baseline 3 is appropriate.

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 specific verb and resource ("Start a deploy into an existing running service") and enumerates the two input modes, so the agent knows exactly what the call does. It implicitly separates itself from create_project ("a project with no server yet is ordered, not deployed") but never names the closest siblings, redeploy and deploy_status, so the differentiation is not fully airtight.

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?

Gives a clear precondition (service must already exist) and a decision rule between the two archive modes: uploadId for a normal project, inline base64 gzip tar only for "a tiny project under 1 MiB." It also states the negative case (no server yet → ordered, not deployed). Missing an explicit steer to redeploy for an already-deployed service.

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