Skip to main content
Glama

Delimit Deploy Impl

_delimit_deploy_impl
Destructive

Dispatch a deployment operation by name: plan, build, publish, verify, rollback, status, site, or npm. Manage container, site, and npm deployments from a single entry point.

Instructions

Unified deployment entry point — dispatches to one of eight actions (Pro).

When to use: as the single MCP-registered deploy surface (delimit_deploy) when the caller wants to pick the deploy operation by name in one call rather than choosing a specific delimit_deploy_* alias. Covers the full container chain (plan -> build -> publish -> verify -> rollback), the deploy-state read (status), and the two non-container ship paths (site / npm). When NOT to use: from internal code paths or when you want the operation's behavior and gate to surface at the right name — prefer the specific alias (delimit_deploy_plan, delimit_deploy_build, delimit_deploy_publish, delimit_deploy_verify, delimit_deploy_rollback, delimit_deploy_status, delimit_deploy_site, delimit_deploy_npm). For a pure runtime health check use delimit_obs_status; for a pre-deploy smoke test use delimit_test_smoke; for release-tracking metadata use delimit_release_status.

Sibling contrast: each delimit_deploy_ wrapper is a thin alias over this implementation (they exist so the action's docstring lives at the right name). This is the dispatch core. The "plan" action additionally shares logic with delimit_deploy_plan via the internal _deploy_plan_chain helper.

Side effects: ALL actions are gated by require_premium — unlicensed callers receive a license payload and no backend call is made. Errors are deterministic: an unrecognized action returns {"error": "Unknown action ''. Valid: ..."} before any gate or backend call. Per action:

  • "plan": delegates to _deploy_plan_chain (gate key "deploy_plan"). Read-mostly but ORCHESTRATES a chain: a worktree-sanity precheck, then delimit_security_audit (FAIL-CLOSED — halts with status="blocked" on audit error or any critical finding without producing a plan), then the deploy-bridge plan, then a best-effort delimit_gov_evaluate. Produces no deploy artifact itself.

  • "build": gate "deploy_build". WRITES locally — shells out to the container builder (consumes local disk/CPU for image layers). No network push at this step.

  • "publish": gate "deploy_publish". NETWORK WRITE — pushes previously built images to the configured container registry.

  • "verify": gate "deploy_verify". Read-only network PROBES (HTTP health checks, container/dependency inspection) of a deployed revision. May return partial results on backends without health endpoints.

  • "rollback": gate "deploy_rollback". MUTATES the running environment to point at to_sha (reversal-only).

  • "status": gate "deploy_status". READ-ONLY query of the deploy state store. No write, no probe.

  • "site": repo_path is required and project_path resolves inside it. gate "deploy_site". LOCAL scoped git ops + a NETWORK Vercel build. The default uses only pre-staged changes; explicit paths are the only way the tool stages files. A post-push Vercel timeout returns pending with continuation identifiers instead of closing the transport.

  • "npm": gate "deploy_npm". A PRODUCTION DEPLOY — bumps package.json (LOCAL write), runs prepublishOnly, npm pack, then npm publish (a publicly-visible NETWORK write, effectively not undoable). dry_run=True suppresses only the final publish; the bump and pack still run. Every result is wrapped via _with_next_steps for orchestrator hints.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
appNoApplication name / project key in the deploy backend. Used by "plan", "build", "publish", "verify", "rollback", "status". Required for a real container operation. (Ignored by "site" and "npm".)
envNoTarget environment, typically "staging" or "production". Used by "plan", "verify", "rollback", "status".
tagNonpm dist-tag. Used by "npm" only. Default "latest"; use "next" or a custom tag to avoid auto-installing the new version for existing users.latest
bumpNoSemver bump "patch" (default) / "minor" / "major". Used by "npm" only.patch
pathsNo
actionNoWhich deploy operation to perform. One of "plan", "build", "npm", "publish", "site", "status", "verify", "rollback". Default "status". Case/space-insensitive (lowered + stripped). Other values return a deterministic {"error": ...}.status
to_shaNoSHA to roll back to. Used by "rollback" only. None lets the backend select the previous deployed SHA.
dry_runNoIf True, run the npm chain without the final publish. Used by "npm" only. Default False.
git_refNoGit ref (branch/tag/SHA). Used by "plan", "build", "publish", "verify". Default None = backend HEAD; drives the image tag for "build".
messageNoGit commit message. Used by "site" only.
ventureNo
repo_pathNoRequired Git worktree root for every deploy action.
observationNo
staged_onlyNo
target_urlsNo
project_pathNoRepository-relative site/package directory. It must remain inside repo_path..
service_unitNo
expected_hostNo
vercel_timeoutNo
intended_releaseNo
deployment_healthNo
observation_max_age_sNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv4.19.1
    • addedInput schema / properties / deployment_health
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "additionalProperties": true,
      +      "type": "object"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null
      +}
    • addedInput schema / properties / expected_host
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null
      +}
    • addedInput schema / properties / intended_release
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null
      +}
    • addedInput schema / properties / observation
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "additionalProperties": true,
      +      "type": "object"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null
      +}
    • addedInput schema / properties / observation_max_age_s
      Added value: +{
      +  "default": 300,
      +  "type": "integer"
      +}
    • addedInput schema / properties / service_unit
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null
      +}
  2. Changed7 schema fields changedv4.13.2
    • addedInput schema / properties / paths
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null
      +}
    • changedInput schema / properties / project_path / description
      Previous value: -"Path to the project. Used by \"site\" and \"npm\".\nDefault \".\" (cwd). For \"site\" it is sanitized and must not\nescape the workspace root; for \"npm\" it must contain a\npackage.json."New value: +"Repository-relative site/package directory. It must\nremain inside repo_path."
    • addedInput schema / properties / repo_path
      Added value: +{
      +  "default": "",
      +  "description": "Required Git worktree root for every deploy action.",
      +  "type": "string"
      +}
    • addedInput schema / properties / staged_only
      Added value: +{
      +  "default": true,
      +  "type": "boolean"
      +}
    • addedInput schema / properties / target_urls
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null
      +}
    • addedInput schema / properties / venture
      Added value: +{
      +  "default": "",
      +  "type": "string"
      +}
    • addedInput schema / properties / vercel_timeout
      Added value: +{
      +  "default": 60,
      +  "type": "integer"
      +}
  3. Changed10 schema fields changedv4.13.1
    • changedInput schema / properties / action / description
      Previous value: -"Which deploy operation to perform."New value: +"Which deploy operation to perform. One of \"plan\", \"build\",\n\"npm\", \"publish\", \"site\", \"status\", \"verify\", \"rollback\".\nDefault \"status\". Case/space-insensitive (lowered + stripped).\nOther values return a deterministic {\"error\": ...}."
    • changedInput schema / properties / app / description
      Previous value: -"Application name (for plan/build/publish/verify/rollback/status)."New value: +"Application name / project key in the deploy backend. Used by\n\"plan\", \"build\", \"publish\", \"verify\", \"rollback\", \"status\".\nRequired for a real container operation. (Ignored by \"site\"\nand \"npm\".)"
    • changedInput schema / properties / bump / description
      Previous value: -"Version bump patch/minor/major (for action='npm')."New value: +"Semver bump \"patch\" (default) / \"minor\" / \"major\". Used by\n\"npm\" only."
    • changedInput schema / properties / dry_run / description
      Previous value: -"Preview without publishing (for action='npm')."New value: +"If True, run the npm chain without the final publish. Used\nby \"npm\" only. Default False."
    • changedInput schema / properties / env / description
      Previous value: -"Target environment staging/production (for plan/verify/rollback/status)."New value: +"Target environment, typically \"staging\" or \"production\". Used\nby \"plan\", \"verify\", \"rollback\", \"status\"."
    • changedInput schema / properties / git_ref / description
      Previous value: -"Git reference branch/tag/SHA (for plan/build/publish/verify)."New value: +"Git ref (branch/tag/SHA). Used by \"plan\", \"build\",\n\"publish\", \"verify\". Default None = backend HEAD; drives the\nimage tag for \"build\"."
    • changedInput schema / properties / message / description
      Previous value: -"Git commit message (for action='site')."New value: +"Git commit message. Used by \"site\" only."
    • changedInput schema / properties / project_path / description
      Previous value: -"Path to project (for action='site' or action='npm')."New value: +"Path to the project. Used by \"site\" and \"npm\".\nDefault \".\" (cwd). For \"site\" it is sanitized and must not\nescape the workspace root; for \"npm\" it must contain a\npackage.json."
    • changedInput schema / properties / tag / description
      Previous value: -"npm dist-tag (for action='npm')."New value: +"npm dist-tag. Used by \"npm\" only. Default \"latest\"; use \"next\"\nor a custom tag to avoid auto-installing the new version for\nexisting users."
    • changedInput schema / properties / to_sha / description
      Previous value: -"SHA to rollback to (for action='rollback')."New value: +"SHA to roll back to. Used by \"rollback\" only. None lets the\nbackend select the previous deployed SHA."
  4. Addedv4.5.5

TDQS

A4.8/5.0
Behavior5/5

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

The description goes far beyond the annotations (readOnlyHint=false, destructiveHint=true). It discloses per-action side effects: which actions write locally, which push to network, which are read-only probes, which are effectively not undoable (npm publish), the fail-closed behavior of plan, the dry_run semantics, and the deterministic error behavior. It also discloses the license gate (require_premium) and the _with_next_steps wrapping. This is exceptionally transparent.

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?

The description is long but earns its length: it covers eight actions, each with distinct side-effect profiles, plus usage routing and error semantics. The structure is well-organized with clear sections (When to use, When NOT to use, Sibling contrast, Side effects, per-action bullets). It is front-loaded with the core purpose and routing. It could be slightly tightened, but the density is justified for a complex dispatch tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 22-parameter dispatch tool with no required parameters and an output schema, the description is remarkably complete. It explains the action dispatch mechanism, the per-action parameter relevance, the side-effect profile, the gate behavior, and the error contract. The only minor gap is that a few parameters (venture, observation, target_urls, etc.) are not explained in the description, but the schema covers them at 50% and the description covers the critical action-to-parameter mapping.

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 50%, and the description compensates substantially by explaining which parameters are used by which actions (e.g., 'repo_path is required and project_path resolves inside it' for site, 'dry_run=True suppresses only the final publish; the bump and pack still run' for npm). It doesn't document every parameter (venture, observation, target_urls, service_unit, expected_host, etc. are not mentioned), but the action-to-parameter mapping it provides is high-value and goes beyond the 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?

The description opens with a specific verb and resource ('Unified deployment entry point — dispatches to one of eight actions') and immediately distinguishes itself from the sibling aliases by naming them explicitly. It clearly states this is the dispatch core and the aliases are thin wrappers, so an agent can tell it apart from delimit_deploy_plan, delimit_deploy_build, etc. without opening the schema.

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?

The description has an explicit 'When to use' and 'When NOT to use' section. It names the exact conditions for using this tool (single MCP-registered deploy surface, caller wants to pick operation by name) and the alternatives (specific delimit_deploy_* aliases, delimit_obs_status, delimit_test_smoke, delimit_release_status). This is exemplary routing guidance.

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

Deploy Server

Other Tools