AI-powered DevOps knowledge base with practices, templates, and automation tools
Project description
DevOps Practices - MCP Server
Purpose: Centralized DevOps practices and standards for infrastructure projects.
Type: Model Context Protocol (MCP) Server for Claude Code
Version: 1.3.0
What This Provides
This MCP server provides shared DevOps practices that are common across infrastructure projects:
Available Practices (11)
- Air-Gapped Workflow - Working across laptop, CloudShell, bastion, and EKS
- Documentation Standards - HOW/WHAT/WHY structure, naming conventions
- Session Continuity - State tracking, handoff protocols
- Task Tracking - TRACKER.md, CURRENT-STATE.md, PENDING-CHANGES.md
- Git Practices - Using
git mv, commit conventions, backup protocols, GitLab Flow - Efficiency Guidelines - When to script vs copy-paste, batching commands
- Standard Workflow - Common operational patterns and workflows
- Runbook Documentation โญ - Mandatory session log standards and requirements
- Configuration Management โญ - Config organization, placeholders, environment isolation
- README Maintenance โญ - Directory documentation standards and best practices
- Issue Tracking ๐ - In-repository Jira-like issue tracking system (Advanced)
Available Templates (7)
- TRACKER.md - Task tracking template (milestones)
- CURRENT-STATE.md - Session handoff template
- CLAUDE.md - Simplified project instructions template
- RUNBOOK.md โญ - Session log template with all required sections
- ISSUE.md ๐ - Individual issue template (Advanced)
- ISSUES.md ๐ - Issue index template with stats dashboard (Advanced)
- issues/README.md ๐ - How to use the issue system (Advanced)
Architecture
devops-practices-mcp/
โโโ README.md # This file
โโโ mcp-server.py # MCP server implementation
โโโ requirements.txt # Python dependencies
โโโ .gitlab-ci.yml # GitLab CI/CD pipeline
โโโ health-check.sh # Health validation script
โโโ practices/ # Shared practice documents (11 files)
โ โโโ air-gapped-workflow.md
โ โโโ documentation-standards.md
โ โโโ session-continuity.md
โ โโโ task-tracking.md
โ โโโ git-practices.md
โ โโโ efficiency-guidelines.md
โ โโโ standard-workflow.md
โ โโโ runbook-documentation.md
โ โโโ configuration-management.md
โ โโโ readme-maintenance.md
โ โโโ issue-tracking.md # ๐ Advanced: In-repo issue tracking
โโโ templates/ # File templates (7 files)
โ โโโ TRACKER-template.md
โ โโโ CURRENT-STATE-template.md
โ โโโ CLAUDE-template.md
โ โโโ RUNBOOK-template.md
โ โโโ ISSUE-TEMPLATE.md # ๐ Individual issue template
โ โโโ ISSUES.md # ๐ Issue index with dashboard
โ โโโ issues-README.md # ๐ Issue system guide
โโโ tools/ # Automation tools ๐
โ โโโ issue-manager.sh # CLI for managing issues
โโโ config/ # MCP configuration
โโโ mcp-config.json # Server configuration
MCP Tools
The MCP server provides 5 tools for Claude to query practices and templates:
| Tool | Description | Example |
|---|---|---|
list_practices |
List all available practices | Returns list of 10 practices |
get_practice |
Get practice content by name | get_practice("task-tracking") |
list_templates |
List all available templates | Returns list of 4 templates |
get_template |
Get template content by name | get_template("TRACKER-template") |
render_template |
Render template with variable substitution | render_template("TRACKER-template", {"PROJECT_NAME": "my-project"}) |
Template Variable Substitution
Templates support ${VARIABLE} placeholders that are automatically substituted:
Auto-provided variables:
${DATE}- Current date (YYYY-MM-DD format)${TIMESTAMP}- UTC timestamp (YYYYMMDDTHHMMz format)${USER}- Current system user${YEAR}- Current year
Custom variables: Pass any additional variables when rendering:
render_template("RUNBOOK-template", {
"SESSION_NUMBER": "1",
"TITLE": "Kafka Deployment",
"CLUSTER_NAME": "example-eks-uat",
"OBJECTIVE_DESCRIPTION": "Deploy Kafka cluster to UAT"
})
All ${...} placeholders in the template are replaced with provided values.
CI/CD Pipeline
This repository includes a GitLab CI/CD pipeline (.gitlab-ci.yml) that automatically validates changes:
Pipeline Jobs
On every merge request and commit to main/develop:
- health-check - Runs the comprehensive health check script
- python-validation - Validates Python syntax and dependencies
- practice-validation - Ensures all practice files exist
- template-validation - Ensures templates contain variable placeholders
- link-checker - Checks documentation cross-references
Benefits
- โ Prevents breaking changes from reaching main branch
- โ Catches missing files or syntax errors automatically
- โ Ensures consistent quality standards
- โ No manual validation needed
Pipeline Status
Check pipeline status in GitLab:
- Green checkmark โ - All checks passed, safe to merge
- Red X โ - Checks failed, review errors before merging
Documentation
Quick Reference
- PRACTICE-INDEX.md - Quick lookup guide for which practice to use when
- Organized by task type (deploying, documenting, troubleshooting, etc.)
- Common scenarios with recommended practices
- Practice dependencies and relationships
Migration Guide
- MIGRATION-GUIDE.md - Roll out MCP to existing projects
- Step-by-step migration from monolithic CLAUDE.md
- Configuration setup for Claude Desktop/Code
- Testing and validation procedures
- Rollback plan if needed
Version History
- CHANGELOG.md - Complete version history and upgrade guides
- Version 1.0.0 (2026-02-13): 10 practices, 4 templates, health check tool
- Version 0.1.0 (2026-02-13): Initial release
Health Check
- health-check.sh - Validate MCP server before deployment
- 14 comprehensive checks (directory structure, files, Python environment, loading tests)
- Colored output with pass/fail counts
- Exit codes: 0 (healthy), 1 (unhealthy)
Usage:
cd devops-practices-mcp
bash health-check.sh
How Projects Use This
Project CLAUDE.md Structure
Each project has a simplified CLAUDE.md:
# Claude AI Assistant - [Project Name]
## MCP Service Integration
**Shared Practices**: `devops-practices` MCP server
Claude has access to shared DevOps practices via MCP:
- Air-gapped workflow
- Documentation standards
- Session continuity protocols
- Task tracking guidelines
- Git best practices
- Efficiency guidelines
## Project-Specific: [Project Details]
[Only project-specific instructions here]
Benefits
- DRY: Shared practices written once, used everywhere
- Consistency: All projects follow same standards
- Maintainability: Update once, all projects benefit
- Discoverability: Claude can query practices when needed
Installation & Setup
Recommended Location: ~/.mcp-servers/devops-practices/
This keeps MCP servers organized and makes configuration easier. All examples below use this location.
1. Clone Repository
# Clone to recommended location
git clone <repo-url> ~/.mcp-servers/devops-practices
cd ~/.mcp-servers/devops-practices
2. Install Dependencies
Using uv (recommended - 10-100x faster):
# Install uv if not already installed
curl -LsSf https://astral.sh/uv/install.sh | sh
# Install dependencies
uv pip install -r requirements.txt
Or using traditional pip:
pip install -r requirements.txt
Why uv?
- 10-100x faster than pip
- Better dependency resolution
- Built in Rust for performance
- Drop-in replacement for pip
3. Configure MCP Server
Edit ~/.config/claude/config.json (or wherever Claude config lives):
{
"mcpServers": {
"devops-practices": {
"command": "python",
"args": ["/home/<username>/.mcp-servers/devops-practices/mcp-server.py"],
"env": {}
}
}
}
Note: Replace <username> with your actual username, or use the full absolute path.
3. Restart Claude Code
# Restart Claude Code to load the MCP server
4. Test Connection
Ask Claude: "Can you list the available DevOps practices?"
Claude should be able to query the MCP server and list practices.
Real-World Use Cases
1. Multi-Environment Kafka Deployment
Scenario: Deploying Kafka across dev โ test โ uat โ prod
Without MCP:
- Duplicate 580-line CLAUDE.md in each project
- Repeat same issues on each environment (12 hours total)
- No standardized approach across teams
With MCP:
- Claude queries
get_practice("configuration-management")for installation SOPs - Copies dev runbook for test environment (56% time savings)
- All teams follow same standards automatically
Result: 5.25 hours vs 12 hours (56% faster)
2. Standardized Git Workflow
Scenario: Team needs consistent branching strategy
Without MCP:
- Each project has different branching approach
- New team members confused about workflow
- Git practices documented differently everywhere
With MCP:
- Claude queries
get_practice("git-practices") - Everyone gets same 200+ line GitLab Flow documentation
- Single source of truth for git standards
Result: Consistent workflow across all 15 projects
3. Air-Gapped Infrastructure Deployment
Scenario: Deploying to secure environment without internet
Without MCP:
- Re-explain workflow every session
- Copy-paste commands from old runbooks
- Inconsistent file transfer procedures
With MCP:
- Claude queries
get_practice("air-gapped-workflow") - Gets step-by-step: Laptop โ S3 โ Bastion โ Target
- Consistent process every time
Result: Zero security incidents, predictable deployments
4. Project Documentation Setup
Scenario: Starting new infrastructure project
Without MCP:
- Create CLAUDE.md from scratch (2 hours)
- Copy-paste from old projects (inconsistent)
- Miss important practices
With MCP:
User: "Create project structure for monitoring-stack project"
Claude: [Queries MCP for templates]
Claude: Creates TRACKER.md, CURRENT-STATE.md, RUNBOOK.md
All following latest standards
Result: 15 minutes vs 2 hours (88% faster)
5. Issue Tracking for Complex Projects
Scenario: Managing 50+ work items across 3-month project
Without MCP:
- Use external Jira (access issues, overhead)
- Or track in scattered markdown files
- No consistent format
With MCP:
- Claude queries
get_template("ISSUES") - Creates in-repo issue tracking with dashboard
- Uses
tools/issue-manager.shfor CLI management
Result: Git-based tracking, no external dependencies
Usage Examples
For Claude
When working on your projects:
Query Practice:
User: "What's the air-gapped workflow for file transfers?"
Claude: [Queries MCP: get_practice("air-gapped-workflow")]
Claude: [Receives markdown content]
Claude: "Here's the air-gapped workflow..."
Get Template (Raw):
User: "Show me the TRACKER template"
Claude: [Queries MCP: get_template("TRACKER-template")]
Claude: [Receives template with ${VARIABLES}]
Claude: "Here's the template..."
Render Template (With Variables):
User: "Create a TRACKER.md for my kafka-deployment project"
Claude: [Queries MCP: render_template("TRACKER-template", {
"PROJECT_NAME": "kafka-deployment",
"DATE": "2026-02-14",
"PHASE_NAME": "UAT Deployment"
})]
Claude: [Receives rendered template with all variables substituted]
Claude: [Creates TRACKER.md with actual values]
For Uttam Jaiswal
Update a Practice:
cd devops-practices-mcp
vim practices/documentation-standards.md
# Make changes
git add practices/documentation-standards.md
git commit -m "Update documentation standards: add new RUNBOOKS guidelines"
git push
# All projects using this MCP server now get updated standards
Branching Strategy
This repository uses GitLab Flow with semantic versioning to ensure stability for dependent projects.
Branch Structure
main โ Production releases only (v1.0.0, v1.1.0, etc.)
โ
develop โ Active development, integration branch
โ
feature/* โ New practices, templates
release/* โ Version preparation (v1.2.0)
hotfix/* โ Critical production fixes
Branch Types
| Branch | Purpose | Created From | Merges To |
|---|---|---|---|
main |
Production releases (tagged) | - | - |
develop |
Active development | main |
main (via release) |
feature/* |
New functionality | develop |
develop |
release/* |
Version preparation | develop |
main + develop |
hotfix/* |
Critical fixes | main |
main + develop |
Why GitLab Flow?
- โ
Stability:
mainalways contains tested, production-ready code - โ
Safety: Changes go through
developbefore reaching production - โ Testing: CI/CD validates all changes before merge
- โ Versioning: Clear semantic version releases (v1.0.0, v1.1.0, etc.)
- โ Traceability: Full history of what changed and when
Quick Workflows
Add New Practice/Template:
git checkout develop
git checkout -b feature/add-security-practice
# Make changes, commit
git push origin feature/add-security-practice
# Create MR โ develop
Create Release:
git checkout develop
git checkout -b release/v1.2.0
# Update CHANGELOG.md, version numbers
# Create MR โ main
# Tag release: git tag v1.2.0
# Merge back to develop
Critical Hotfix:
git checkout main
git checkout -b hotfix/critical-bug
# Fix, commit, push
# Create MR โ main (fast-track)
# Also merge to develop
Full Documentation: See CONTRIBUTING.md and git-practices.md
Governance
Who Maintains This
- Owner: Uttam Jaiswal Lead
- Contributors: DevOps Engineers
- Review Process: PR required for changes
Update Protocol
For New Practices/Templates:
- Create feature branch from
develop - Update practice or template files
- Run health check:
bash health-check.sh - Update documentation (README.md, PRACTICE-INDEX.md)
- Create MR with description โ
develop - Code review by team
- Merge to
developafter CI/CD passes
For Releases:
- Create release branch from
develop:release/v1.x.0 - Update CHANGELOG.md and version numbers
- Create MR โ
main - Tag release after merge:
git tag v1.x.0 - Merge release back to
develop - Announce to team (affects all dependent projects)
For Critical Fixes:
- Create hotfix branch from
main:hotfix/issue-name - Fix issue and test thoroughly
- Create MR โ
main(fast-track approval) - Tag hotfix release:
git tag v1.x.1 - Merge to
developto keep in sync - Announce urgent fix to team
See: CONTRIBUTING.md for detailed workflows
Versioning
- Major version (2.0): Breaking changes to structure
- Minor version (1.1): New practices added
- Patch version (1.0.1): Clarifications, fixes
Projects Using This MCP Server
| Project | Purpose | Location |
|---|---|---|
| kafka-deployment | Apache Kafka deployment | Example project |
| observability-stack | Observability stack | Example project |
| network-infra | Network infrastructure | Example project |
Development
See CONTRIBUTING.md for detailed contribution workflow, branching strategy, and code review process.
Adding a New Practice
- Create markdown file in
practices/ - Use clear structure with examples
- Update
mcp-server.pyif needed - Test with Claude
- Update this README (practice count)
- Update PRACTICE-INDEX.md (add to scenario lists)
- Update CHANGELOG.md (document the addition)
- Run health check:
bash health-check.sh
Adding a New Template
- Create template file in
templates/ - Use placeholders:
${PROJECT_NAME},${DATE}, etc. (see auto-provided variables in MCP Tools section) - No code changes needed -
render_templatehandles all${...}substitutions automatically - Test template:
render_template("your-template", {"VAR": "value"}) - Update this README (template count)
- Update CHANGELOG.md (document the addition)
- Run health check:
bash health-check.sh
Making Changes
- Before release: Run health check to validate all files
- After changes: Update CHANGELOG.md with version bump
- Breaking changes: Update MIGRATION-GUIDE.md with migration notes
- New features: Update PRACTICE-INDEX.md with usage scenarios
Troubleshooting
Claude Can't Access MCP Server
- Check MCP server is running:
ps aux | grep mcp-server.py - Check Claude config:
~/.config/claude/config.json - Check file paths are absolute
- Restart Claude Code
Practice File Not Found
- Verify file exists:
ls practices/ - Check filename matches exactly (case-sensitive)
- Check MCP server logs
Template Substitution Failing
- Verify placeholder syntax:
${VARIABLE} - Check template file encoding (UTF-8)
- Review mcp-server.py logs
License
MIT License - Free to use and modify
Maintained By: Uttam Jaiswal Last Updated: 2026-02-17 Version: 1.3.0
Project details
Release history Release notifications | RSS feed
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
Built Distribution
Filter files by name, interpreter, ABI, and platform.
If you're not sure about the file name format, learn more about wheel file names.
Copy a direct link to the current filters
File details
Details for the file devops_practices_mcp-1.3.0.tar.gz.
File metadata
- Download URL: devops_practices_mcp-1.3.0.tar.gz
- Upload date:
- Size: 65.1 kB
- Tags: Source
- Uploaded using Trusted Publishing? No
- Uploaded via: uv/0.10.2 {"installer":{"name":"uv","version":"0.10.2","subcommand":["publish"]},"python":null,"implementation":{"name":null,"version":null},"distro":{"name":"Ubuntu","version":"24.04","id":"noble","libc":null},"system":{"name":null,"release":null},"cpu":null,"openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":null}
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
0b8bb19f135d50fb859e26fa9670cc8a7a18d65b242c975c031f2f3b23306e45
|
|
| MD5 |
a3c65edbde7a583d82c61a6476391af4
|
|
| BLAKE2b-256 |
eb76b7ce2ba079792f2086ee5719bd6dcc8406f076befd0503dca2f3136d9705
|
File details
Details for the file devops_practices_mcp-1.3.0-py3-none-any.whl.
File metadata
- Download URL: devops_practices_mcp-1.3.0-py3-none-any.whl
- Upload date:
- Size: 81.0 kB
- Tags: Python 3
- Uploaded using Trusted Publishing? No
- Uploaded via: uv/0.10.2 {"installer":{"name":"uv","version":"0.10.2","subcommand":["publish"]},"python":null,"implementation":{"name":null,"version":null},"distro":{"name":"Ubuntu","version":"24.04","id":"noble","libc":null},"system":{"name":null,"release":null},"cpu":null,"openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":null}
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
5119cf8a69822df9dd7c309d3d45584e5e54dd8f7605c0b781dbaa6a43650ef5
|
|
| MD5 |
2d8c68b9e0ae038d61873367964500d6
|
|
| BLAKE2b-256 |
a66f0d1981229cfa42c97e07d0b42c8fa59b9082f1338f174d261643b935f72d
|