Skip to main content
Glama
mrchris2000

mcp-devops-deploy

by mrchris2000
README.md
# MCP Deploy Automation

A Model Context Protocol (MCP) server for deployment automation. This server provides tools to manage deployments, environments, snapshots, and applications through DevOps Deploy's REST API.

## Features

- **🚀 Quick Deployments**: Deploy snapshots or specific component versions to any environment
- **📸 Snapshot Management**: Create, list, and deploy snapshots
- **🌍 Environment Management**: Discover and manage application environments
- **📊 Deployment Monitoring**: Track deployment status and progress
- **⏰ Scheduling**: Schedule deployments for future execution
- **🔄 Automation**: Set up deployment triggers and recurring deployments
- **📋 Inventory Tracking**: See what's deployed where and compare environments

## Prerequisites

- Node.js 18.0.0 or higher
- Access to an DevOps Deploy server
- Valid Deploy server access token

## Installation

```bash
npm install @securedevops/mcp-deploy-automation
```

## Configuration

Set up environment variables or provide command line arguments:

### Environment Variables
```bash
export DEPLOY_SERVER_URL="https://your-deploy-server:8443"
export DEPLOY_TOKEN="your-access-token"
```

## Best Practices

### 🔑 Use IDs Instead of Names
For better reliability and compatibility, always prefer using IDs over names when available:

1. **Start with discovery tools**: Use `list_applications` to get application IDs
2. **Get environment IDs**: Use `list_environments_for_application` to get environment IDs
3. **Get snapshot IDs**: Use `list_application_snapshots` to get snapshot IDs
4. **Use IDs in deployment operations**: This avoids naming conflicts and ensures accuracy

**Example workflow**:
```
1. list_applications → Get application ID
2. list_environments_for_application → Get environment IDs  
3. deploy_snapshot_to_environment using IDs instead of names
```

The tools will display both names and IDs in their output, making it easy to copy the IDs for subsequent operations.

## Example Use Cases

### 1. Automated Production Deployment
**Scenario**: You need to deploy a tested snapshot to production environment during a maintenance window.

**Steps**:
1. "List all applications to find my target application"
### 2. Environment Promotion Pipeline
**Scenario**: You need to promote code through development → staging → production environments.

**Steps**:
1. "Compare staging environment with production to see what changes are pending"
2. "Create a snapshot from the current staging environment called 'release-candidate-v2.1.4'"
3. "Deploy the snapshot to production environment using the 'Production Deploy' process"
4. "Monitor deployment status and ensure successful completion"
5. "Verify production inventory matches the deployed snapshot"

**Benefits**: Safe, controlled promotion through environments with full visibility and verification.

### 3. Scheduled Maintenance Deployment
**Scenario**: You need to schedule critical updates during off-hours maintenance windows.

**Steps**:
1. "List all environments for the 'Banking Platform' application"
2. "Schedule deployment of 'security-patch-v1.2.1' snapshot to production for tomorrow at 2:00 AM"
3. "Set up a deployment trigger for automatic rollback if deployment fails"
4. "Schedule weekly recurring deployments for the staging environment"

**Benefits**: Automated deployment scheduling reduces manual intervention and ensures deployments happen during optimal times.

## Available Tools

### 1. **deploy_snapshot_to_environment**
Deploy a named snapshot to a specific environment.

**Parameters:**
- `application` - Name or ID of the application
- `snapshot` - Name or ID of the snapshot to deploy
- `environment` - Name or ID of the target environment
- `applicationProcess` - Name or ID of the application process
- `description` (optional) - Description for the deployment
- `onlyChanged` (optional) - Deploy only changed versions (default: true)

### 2. **deploy_component_versions**
Deploy specific component versions to an environment.

**Parameters:**
- `application` - Name or ID of the application
- `environment` - Name or ID of the target environment
- `applicationProcess` - Name or ID of the application process
- `versions` - Array of component/version pairs
- `description` (optional) - Description for the deployment
- `onlyChanged` (optional) - Deploy only changed versions (default: true)

### 3. **list_application_snapshots**
Get all available snapshots for an application.

**Parameters:**
- `application` - Name or ID of the application

### 4. **list_environment_inventory**
Get current deployed versions in an environment.

**Parameters:**
- `application` - Name or ID of the application
- `environment` - Name or ID of the environment

### 5. **create_snapshot_from_environment**
Create a new snapshot based on current environment state.

**Parameters:**
- `application` - Name or ID of the application
- `environment` - Name or ID of the source environment
- `name` - Name for the new snapshot
- `description` (optional) - Description for the snapshot

### 6. **get_deployment_status**
Check status of a running or completed deployment.

**Parameters:**
- `requestId` - Request ID from a previous deployment

### 7. **schedule_deployment**
Schedule a deployment for future execution.

**Parameters:**
- `application` - Name or ID of the application
- `environment` - Name or ID of the target environment
- `applicationProcess` - Name or ID of the application process
- `date` - Date and time to schedule (yyyy-mm-dd HH:mm or unix timestamp)
- `snapshot` (optional) - Snapshot to deploy
- `versions` (optional) - Component versions to deploy
- `description` (optional) - Description for the deployment
- `recurrencePattern` (optional) - Recurrence: D (daily), W (weekly), M (monthly)

### 8. **list_environments_for_application**
Get all environments configured for an application.

**Parameters:**
- `application` - Name or ID of the application

### 9. **compare_environment_snapshots**
Compare deployed versions between environments or against a snapshot.

**Parameters:**
- `application` - Name or ID of the application
- `sourceEnvironment` - Name or ID of the source environment
- `targetEnvironment` (optional) - Name or ID of the target environment
- `targetSnapshot` (optional) - Name or ID of the target snapshot

### 10. **create_deployment_trigger**
Set up automated deployment triggers.

**Parameters:**
- `environment` - Name or ID of the environment
- `name` - Name for the deployment trigger
- `applicationProcess` - Name or ID of the application process
- `description` (optional) - Description for the trigger
- `triggerType` - Type: VERSION_CHANGE or SCHEDULE
- `schedulePattern` (optional) - Schedule pattern for SCHEDULE triggers

### 11. **list_applications**
Get information about all applications on the server.

**Parameters:** None

## Error Handling

The server provides detailed error messages and will indicate:
- Authentication failures
- Invalid application/environment names
- Network connectivity issues
- API response errors

## Development

To run the server in development mode:

```bash
git clone https://github.com/securedevops/mcp-deploy-automation.git
cd mcp-deploy-automation
npm install
npm start
```

## License

ISC License

## Contributing

Contributions are welcome! Please read our contributing guidelines and submit pull requests to our GitHub repository.

## Support

For issues and questions:
- GitHub Issues: https://github.com/securedevops/mcp-deploy-automation/issues
- Documentation: https://github.com/securedevops/mcp-deploy-automation#readme

TDQS

B3.4/5.0

Scored across 15 tools

Disambiguation4/5

Most tools target distinct resources and actions, with clear separation between snapshots, components, environments, and deployments. The only real overlap is between create_deployment_trigger and schedule_deployment, both of which set up future deployments and could be misselected.

Naming Consistency4/5

The large majority follow a consistent verb_noun pattern such as list_applications, deploy_component_versions, and get_deployment_status. Minor deviations like auth_diagnostics and create_deployment_trigger break the pattern slightly, but the naming remains predictable overall.

Tool Count4/5

Fifteen tools is at the upper boundary of a well-scoped deployment server, and each tool covers a distinct facet of the deployment workflow. A few tools such as auth_diagnostics and create_deployment_trigger feel slightly peripheral, but none seem redundant enough to cut.

Completeness3/5

Core deployment workflows are covered well: listing applications/components/environments, deploying snapshots or component versions, scheduling, and checking status. Notable gaps include no way to cancel or roll back a deployment, and triggers/snapshots only support creation with no update/delete lifecycle.

Maintenance

ActivityInactive
ResponsivenessNo issues