Skip to main content
Glama

_delimit_deploy_impl

Dispatch to eight deploy operations (plan, build, publish, verify, rollback, status, site, npm). Orchestrates container lifecycle, static site deploys, or npm publishing from one call.

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": project_path is path-sanitized FIRST (an escape returns {"error": ...} before the gate). gate "deploy_site". LOCAL git ops (add/commit/push) + a NETWORK Vercel build trigger.

  • "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
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
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".
git_refNoGit ref (branch/tag/SHA). Used by "plan", "build", "publish", "verify". Default None = backend HEAD; drives the image tag for "build".
to_shaNoSHA to roll back to. Used by "rollback" only. None lets the backend select the previous deployed SHA.
project_pathNoPath to the project. Used by "site" and "npm". Default "." (cwd). For "site" it is sanitized and must not escape the workspace root; for "npm" it must contain a package.json..
messageNoGit commit message. Used by "site" only.
bumpNoSemver bump "patch" (default) / "minor" / "major". Used by "npm" only.patch
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
dry_runNoIf True, run the npm chain without the final publish. Used by "npm" only. Default False.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

No annotations are provided, so the description carries full burden. It thoroughly discloses behaviors: actions gated by require_premium, deterministic error for unknown actions, detailed per-action side effects (read-mostly, local writes, network writes, mutations, etc.), error handling, and dry_run suppression behavior. This is comprehensive.

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 description is very long and detailed, with multiple paragraphs and bullet-like sections. It is well-structured with headers, but could be more concise. Some per-action details might be better placed in separate docs. However, for a complex dispatch tool, brevity is difficult; it earns a 3.

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?

Given the tool's complexity (10 parameters, 8 actions, no annotations, output schema exists), the description is remarkably complete. It covers all actions, side effects, parameter usage by action, error handling, and output wrapping. Every necessary aspect for correct selection and invocation is covered.

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?

Input schema has 100% description coverage for all 10 parameters. The description adds contextual value beyond schema, such as case-insensitive action matching, dry_run behavior (suppresses only final publish), and which parameters are ignored per action. However, much parameter usage is already in schema, so baseline 3; extra context earns a 4.

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 clearly states it is a 'unified deployment entry point' that dispatches to eight deploy actions. It specifies the verb (dispatches) and resource (deploy operations), and distinguishes from sibling aliases and related tools like delimit_obs_status, delimit_test_smoke, and delimit_release_status.

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?

Explicitly states when to use ('as the single MCP-registered deploy surface when the caller wants to pick the deploy operation by name') and when NOT to use ('from internal code paths or when you want the operation's behavior and gate to surface at the right name'), with specific alternatives listed (e.g., 'prefer the specific alias'). Also contrasts with non-deploy tools for health checks, smoke tests, and release tracking.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/delimit-ai/delimit-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server