Deployment.io

Available MCP Tools


Reference of all tools exposed by the deployment.io MCP server. These are the actions a coding agent can perform when connected to your organization.

Deployments

ToolDescription
deploy_static_siteDeploy a static site to an environment. Creates a new deployment if one doesn't exist for the repo+branch+environment combination, or triggers a redeploy if it does. Supports React, Vue, Astro, Next.js static export, Vite, and more.

The agent automatically detects your repository URL, branch, build command, and output directory from your local project. Just tell it what to deploy and where.

Environment Management

ToolDescription
list_environmentsList all environments in the organization. Returns IDs, names, types, regions, classifications, and dashboard links.
create_environmentCreate a new environment. Supports choosing infrastructure (shared cloud or custom runners) and classification (Production/Staging/Development).
edit_environmentRename an existing environment.

Infrastructure

ToolDescription
list_runnersList available infrastructure for deploying environments. Shows shared cloud runners and custom AWS runners.

Jobs & Approvals

ToolDescription
get_job_statusCheck the status of an async job (environment creation, deployment, etc.). Returns progress, logs, and completion info.
get_approval_statusCheck the status of a pending approval request. Used when a deployment requires human sign-off before proceeding.

Usage Examples

Example 1: Deploy a static site to staging

Ask your coding agent:

"Deploy my app to staging"

The agent will:

  1. Detect your repository, branch, build command, and output directory from the local project
  2. Call list_environments to find the staging environment
  3. Call deploy_static_site with the detected parameters
  4. Poll get_job_status until the build completes
  5. Report back with the live URL

Example 2: Deploy to production (with approval)

Ask your coding agent:

"Deploy to production"

The agent will call deploy_static_site targeting the production environment. If approval is required, the agent will:

  1. Return a link to the approvals page in the dashboard
  2. Wait for a team member to review the agent's summary of what is being deployed and why
  3. Once approved, the build starts automatically
  4. The agent polls get_approval_status and get_job_status to report the result

Example 3: Deploy a specific branch

Ask your coding agent:

"Deploy the feature-xyz branch to staging"

The agent will use git show feature-xyz:package.json to read the correct build configuration from that branch, then deploy it to the staging environment.

Example 4: Create an environment on custom infrastructure

Ask your coding agent:

"Create a new staging environment called 'api-staging' on my AWS account"

The agent will:

  1. Call list_runners to find available infrastructure
  2. Show you the options (shared cloud vs. your custom AWS runners)
  3. Call create_environment with the selected runner, name, and classification
  4. Return a link to the new environment in the dashboard

Example 5: Check job and approval status

Ask your coding agent:

"What's the status of my latest deployment?"

The agent will call get_job_status with the job ID to check progress, show build logs, and report whether the deployment succeeded or failed. If the deployment requires approval, the agent can call get_approval_status to check whether a reviewer has approved it.

Access Control

  • Scopes: Each tool requires specific scopes on the API key (e.g., environments:read, deployments:*). Scopes are configured when the key is created or during OAuth authorization.
  • RBAC: Members only see and modify resources they have been granted access to. Owners have full access.
  • Approvals: Deployments to production environments require human approval before proceeding. Staging and development environments are auto-approved by default. Approval policies are configurable per agent key.

Shared Cloud Infrastructure Note

Deployments on the shared cloud runner (Deployment.io cloud) are automatically deleted after 24 hours. Use a custom runner connected to your own AWS account for persistent deployments.