# DevOps MCP Server

A small, working **Model Context Protocol (MCP) server** that automates common
DevOps tasks — CI/CD pipeline control, PR review, Git operations, and
monitoring/alerting — all gated behind a role-based access control layer.

Built as a portfolio project to demonstrate the concepts from an *MCP for
DevOps* course: MCP server architecture, security & access control, CI/CD
platform integration, PR review agents, approval workflows, and Git
automation.

## Why this project

Rather than one script per topic, this wires the concepts into **one
coherent system**: an AI assistant (or any MCP client) can call these tools
to check pipeline health, review a pull request for risky/secret-leaking
code, automate git branching/commits, and trigger deploys — but every action
is authorized against a role first, and every decision (allowed *or denied*)
is written to an audit log.

## Architecture

```
devops-mcp-server/
├── server/
│   ├── main.py        # MCP server entry point — registers all tools
│   ├── security.py     # RBAC: roles, authorization, audit log
│   ├── pipelines.py     # Simulated CI/CD backend + monitoring/alerts
│   ├── pr_review.py    # Static analysis PR review agent
│   └── git_ops.py       # Real git automation (subprocess against sandbox repo)
├── sandbox_repo/        # A real local git repo the tools operate on
├── demo/
│   └── run_demo.py      # Scripted walkthrough exercising every tool
└── requirements.txt
```

### Concept → implementation map

| Course topic | Where it lives |
|---|---|
| MCP Architecture / Server Design | `server/main.py` — tools registered via `FastMCP` |
| Security and Access Control in MCP | `server/security.py` — `Role` enum, `AccessControl`, audit trail |
| MCP Integration with CI/CD Platforms | `server/pipelines.py` — `list_pipelines`, `trigger_pipeline` |
| Pipeline Monitoring and Alerting | `server/pipelines.py` — `_raise_alert`, `list_alerts` |
| Building Intelligent PR Review Agents | `server/pr_review.py` — secret/risk pattern detection, recommendation |
| Approval Workflows / Human-AI Collaboration | `pipelines.py` — production deploys require `ADMIN` approval |
| Automated Git Operations via MCP | `server/git_ops.py` — branch creation, commits via real `git` |

## Roles (simulated identity directory)

| User | Role | Can do |
|---|---|---|
| `dave` | VIEWER | Read-only: view pipelines, status, alerts, repo state |
| `carol` | DEVELOPER | + review PRs, create branches, commit |
| `bob` | OPERATOR | + trigger pipelines, deploy to staging |
| `alice` | ADMIN | + approve production deploys, view audit log |

Every tool declares its minimum required role. Unauthorized calls are
rejected **and logged** — nothing fails silently.

## Running it

```bash
pip install -r requirements.txt

# Option A: scripted demo (no MCP client needed) — recommended first run
python demo/run_demo.py

# Option B: run as a real MCP server over stdio, e.g. to plug into
# Claude Desktop / any MCP client
python -m server.main
```

To wire it into an MCP client config (e.g. Claude Desktop), point it at:

```json
{
  "mcpServers": {
    "devops-mcp-server": {
      "command": "python",
      "args": ["-m", "server.main"],
      "cwd": "/path/to/devops-mcp-server"
    }
  }
}
```

## What the demo shows

`demo/run_demo.py` runs a full scripted transcript:

1. A `VIEWER` can read pipeline data but is **denied** when trying to trigger one.
2. An `OPERATOR` triggers a staging deploy — succeeds and runs.
3. An `OPERATOR` triggers a **production** deploy — it stalls in `awaiting_approval`.
4. The `OPERATOR` tries to self-approve production — **denied** (needs `ADMIN`).
5. An `ADMIN` approves it — the deploy proceeds.
6. A `DEVELOPER` submits a diff containing a hardcoded API key — the PR review
   agent flags it as **critical** and recommends `REQUEST_CHANGES`.
7. A `DEVELOPER` creates a real git branch and commits a real file to the
   sandbox repo — verifiable afterward with `git log`.
8. A `VIEWER` tries to read the audit log — **denied** (`ADMIN`-only).
9. An `ADMIN` reads the full audit log, showing every allowed/denied call.

## Notes on scope

- The CI/CD backend and identity directory are **simulated in-memory** so the
  project runs standalone with no cloud credentials — the interface shape
  (`list` / `status` / `trigger` / `approve`) mirrors a real GitHub
  Actions/Jenkins integration.
- Git operations are **real** — they run actual `git` commands against
  `sandbox_repo/`, so you can inspect the result with `git log` yourself.
- The PR review agent uses deterministic static-analysis rules so the demo
  runs fully offline; swapping in an LLM call (e.g. the Anthropic API) for
  natural-language review comments is a natural next step and slots cleanly
  into `pr_review.py`.