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

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:

{
  "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.