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

Tool	Description
deploy_static_site	Deploy 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.
deploy_web_service	Deploy a web service 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 any backend framework — the service must have a Dockerfile.

The agent automatically detects your project's parameters from the local codebase. For static sites, it reads your build command and output directory. For web services, it reads your Dockerfile, port, and health check path. Just tell the agent what to deploy and where.

Environment Management

Tool	Description
list_environments	List all environments in the organization. Returns IDs, names, types, regions, classifications, and dashboard links.
create_environment	Create a new environment. Supports choosing infrastructure (shared cloud or custom runners) and classification (Production/Staging/Development).
edit_environment	Rename an existing environment.

Infrastructure

Tool	Description
list_runners	List available infrastructure for deploying environments. Shows shared cloud runners and custom AWS runners.

Monitoring & Logs

Tool	Description
get_deployment_logs	Fetch runtime logs from a deployed web service. Supports time range filtering, regex search patterns, and returns up to 500 log lines per request. Use this to debug errors, monitor behavior, or audit activity.

Jobs & Approvals

Tool	Description
get_job_status	Check the status of an async job (environment creation, deployment, etc.). Returns progress, logs, and completion info.
get_approval_status	Check 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 a web service

Ask your coding agent:

"Deploy my API server to staging"

The agent will:

1. Detect your repository and branch from the local project
2. Read the Dockerfile for the EXPOSE port, or search app code for listen calls
3. Search for a health check endpoint (e.g., /health, /healthz)
4. Call list_environments to find the staging environment
5. Call deploy_web_service with the detected parameters
6. Poll get_job_status until the build completes
7. Report back with the service URL

If no Dockerfile exists, the agent will create one for your framework, commit it, push, and then deploy.

Example 3: Deploy to production (with approval)

Ask your coding agent:

"Deploy to production"

The agent will call deploy_static_site or deploy_web_service 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 4: 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 5: 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 6: 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.

Example 7: Fetch error logs from a service

Ask your coding agent:

"Get the last hour of error logs from my production API"

The agent will:

1. Call list_environments to find the production environment
2. Call list_deployments to find the API service
3. Call get_deployment_logs with a time range of the last 60 minutes and a search pattern like error|exception
4. Summarize the errors found and suggest fixes

Example 8: Automate error monitoring with scheduled tasks

Combine get_deployment_logs with Claude Code's /schedule command to create an autonomous error monitoring pipeline. Run /schedule in Claude Code and configure a task with this prompt:

"Fetch error logs from my production service for the last hour. Analyze the errors, trace root causes in the codebase, and open a PR if you find fixable bugs."

The scheduled task runs in the cloud on Anthropic's infrastructure — it works even when your machine is off. Claude clones your repo on each run, fetches logs, analyzes errors, and opens pull requests with fixes. Read the full guide: Autonomous Error Fixing with Scheduled Tasks.

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.