# 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](/blog/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. --- Source: https://deployment.io/docs/coding-agents/available-mcp-tools/