DevOps Practices MCP Server
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@DevOps Practices MCP Servershow me the TRACKER.md template"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
DevOps Practices - MCP Server
mcp-name: io.github.ai-4-devops/devops-practices
Purpose: Productivity framework for DevOps engineers using AI assistance (Claude Code) while working on PoCs.
Type: Model Context Protocol (MCP) Server for Claude Code
Version: 1.4.0
Status: ๐ Officially Published in the MCP Registry (Published: February 18, 2026)
Published Versions:
๐ MCP Registry: v1.4.0 โ Git tag v1.4.0 (
34ca572)๐ Latest Development: main branch (may include unreleased features)
Who is this for? DevOps engineers using Claude Code (VS Code plugin) for PoC development. What it does: Provides structure (TRACKER, ISSUES, docs, SoPs) so you can focus on building without worrying about documentation overhead. What it's NOT: Not a DevOps tutorial - it's a productivity framework for AI-assisted development.
Why This MCP Server?
Solves the CLAUDE.md Bloat Problem
Tired of maintaining massive CLAUDE.md files (1000+ lines) across multiple projects? This MCP centralizes reusable DevOps instructions for engineers working on multiple PoCs, eliminating repeated instructions across projects and folders.
The Problem:
โ Large CLAUDE.md files eat up context window
โ Same practices duplicated across every project
โ Reinventing TRACKER.md, ISSUES.md, docs, SoPs for every PoC
โ Inconsistent standards across projects
โ Context wasted on instructions instead of actual work
The Solution:
โ Pre-built structure - Templates for TRACKER, ISSUES, docs, SoPs
โ Focus on work - Not on "how should I document this?"
โ Consistency - Same standards across all your PoCs
โ Team alignment - Same patterns enable seamless collaboration and easy handovers across sessions, systems, and team members
โ Faster startup - Copy template, start working
โ Context saved - No bloated CLAUDE.md files
What you get (structure, not knowledge):
๐ TRACKER.md template - Start tracking immediately, don't design tracking
๐ ISSUES.md system - Start logging issues, don't setup Jira
๐ Documentation standards - Start writing docs, don't debate structure
๐ Runbook templates - Start documenting ops, don't create SoP formats
๐ Session continuity - Start handoffs, don't design handoff protocols
When searching "devops" in the MCP Registry (as of February 2026), this is the only result. While other MCPs focus on:
๐ง Development tools (code generation, testing, debugging)
๐ Data analysis (databases, APIs, analytics)
๐จ Content creation (writing, design, media)
This MCP provides:
๐๏ธ Configuration structure - How to organize configs per environment, generate new env configs from completed ones, create and validate SoPs
๐ Documentation patterns - TRACKER, ISSUES, docs, runbook templates ready to copy
๐ Operations templates - Session handoff, runbook formats, documentation standards
๐ฏ Structured guidance - GG-SS organized practices for quick discovery
What makes it different:
Prescriptive, not generative - Provides proven practices, not generated code
Infrastructure-first - Built for ops teams, not developers
Reusable patterns - Templates and standards across all your projects
AI-native design - Organized for Claude to query and apply contextually
R&D optimized - Accelerates proof-of-concept development and experimentation
Perfect for: DevOps engineers using Claude Code (VS Code plugin) to build PoCs and conduct R&D with AI assistance.
Related MCP server: Document Organizer MCP Server
How It Works
No server management required:
โ Auto-start: Spawns when Claude Code/Desktop starts
โ Background: Runs silently while you work
โ On-demand: Claude queries practices as needed
โ Auto-stop: Shuts down when Claude closes
โ Fallback: Access practices via GitHub/local if MCP unavailable (see Troubleshooting)
Configuration Options:
You can configure the MCP server globally (all projects) or per-project:
Option 1: Global Configuration (~/.claude.json)
{
"mcpServers": {
"devops-practices": {
"command": "python3",
"args": ["-u", "~/.mcp-servers/devops-practices/mcp-server.py"],
"env": {"PYTHONUNBUFFERED": "1"}
}
}
}Option 2: Project-Level Configuration (.mcp.json in project root)
{
"mcpServers": {
"devops-practices": {
"command": "python3",
"args": ["-u", "~/.mcp-servers/devops-practices/mcp-server.py"],
"env": {"PYTHONUNBUFFERED": "1"}
}
}
}Setup Steps:
Install the MCP server (see Installation section below)
Add configuration to
~/.claude.json(global) or.mcp.json(per-project)Restart Claude Code/Desktop
MCP server runs automatically - no manual startup needed
Note: The -u flag and PYTHONUNBUFFERED ensure real-time logging for debugging.
What This Provides
This MCP server provides shared DevOps practices that are common across infrastructure projects:
Available Practices (11)
Organized using GG-SS prefix pattern (Group-Sequence) for better discoverability:
Naming Pattern: GG-SS-practice-name
GG = Group ID (01-04) - Functional category
SS = Sequence ID (01-03) - Order within group
Example:
03-02-air-gapped-workflow= Group 03, Sequence 02
Group Legend:
01 = Workflow & Processes (how to work effectively)
02 = Version Control & Project Management (git, issues)
03 = Infrastructure & Configuration (K8s, deployments, config)
04 = Documentation Standards (docs, READMEs, runbooks)
Group 01: Workflow & Processes
01-01-session-continuity - State tracking, handoff protocols, CURRENT-STATE.md
01-02-task-tracking - TRACKER.md, CURRENT-STATE.md, PENDING-CHANGES.md
01-03-efficiency-guidelines - When to script vs copy-paste, batching commands
Group 02: Version Control & Project Management
02-01-git-practices - Using
git mv, commit conventions, backup protocols, GitLab Flow02-02-issue-tracking ๐ - In-repository Jira-like issue tracking system (Advanced)
Group 03: Infrastructure & Configuration
03-01-configuration-management โญ - Config organization, placeholders, environment isolation
03-02-air-gapped-workflow - Working across laptop, CloudShell, bastion, and EKS
03-03-standard-workflow - Common operational patterns and workflows
Group 04: Documentation Standards
04-01-documentation-standards - HOW/WHAT/WHY structure, naming conventions
04-02-readme-maintenance โญ - Directory documentation standards and best practices
04-03-runbook-documentation โญ - Mandatory session log standards and requirements
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
โโโ .github/workflows/ci.yml # GitHub Actions pipeline
โโโ health-check.sh # Health validation script
โโโ practices/ # Shared practice documents (11 files, GG-SS organized)
โ โโโ 01-01-session-continuity.md
โ โโโ 01-02-task-tracking.md
โ โโโ 01-03-efficiency-guidelines.md
โ โโโ 02-01-git-practices.md
โ โโโ 02-02-issue-tracking.md # ๐ Advanced: In-repo issue tracking
โ โโโ 03-01-configuration-management.md
โ โโโ 03-02-air-gapped-workflow.md
โ โโโ 03-03-standard-workflow.md
โ โโโ 04-01-documentation-standards.md
โ โโโ 04-02-readme-maintenance.md
โ โโโ 04-03-runbook-documentation.md
โโโ 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 configurationMCP Tools
The MCP server provides 5 tools for Claude to query practices and templates:
Tool | Description | Example |
| List all available practices | Returns list of 10 practices |
| Get practice content by name |
|
| List all available templates | Returns list of 4 templates |
| Get template content by name |
|
| Render template with variable substitution |
|
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 GitHub Actions pipeline (.github/workflows/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 GitHub:
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.shHow 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
โ ๏ธ Fallback: If MCP unavailable, see Appendix or GitHub practices
## Project-Specific: [Project Details]
[Only project-specific instructions here]
## Appendix: Critical Practices (Fallback)
[Emergency practice summaries if MCP down - see CLAUDE-template.md]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
Resilient: Fallback to GitHub/local/appendix if MCP unavailable
Template: See CLAUDE-template.md for full structure including fallback appendix
Installation & Setup
๐ง Manual Installation (Most Stable - Recommended for Development)
Best for: Developers, contributors, or anyone who wants full control
1. Clone Repository
# Clone to recommended location
git clone https://github.com/ai-4-devops/devops-practices.git ~/.mcp-servers/devops-practices
cd ~/.mcp-servers/devops-practices2. Install Dependencies
# Using uv (10-100x faster)
curl -LsSf https://astral.sh/uv/install.sh | sh
uv pip install -r requirements.txt
# Or using traditional pip
pip install -r requirements.txt3. Configure MCP Server
Edit ~/.claude/config.json:
{
"mcpServers": {
"devops-practices": {
"command": "python3",
"args": ["-u", "~/.mcp-servers/devops-practices/mcp-server.py"],
"env": {"PYTHONUNBUFFERED": "1"}
}
}
}4. Restart Claude Code/Desktop
5. Verify MCP Connection
Ask Claude: "Can you list the available DevOps practices from the MCP server?"
๐ก Tip: Claude may need a reminder to check the MCP. If it doesn't respond with practice names, try:
"Please verify you can access the devops-practices MCP server"
"List all available MCP tools"
Restart Claude Code again
๐งช Experimental / Testing (For Nerds)
โ ๏ธ Note: These methods are experimental and not yet fully tested. Use Manual Installation (above) for reliable setup.
Option 1: MCP Registry via Claude Desktop UI (Experimental):
Open Claude Desktop
Go to Settings โ Developer โ MCP Servers
Search for "devops-practices"
Click "Install"
Restart Claude Code/Desktop
Option 2: Install via uvx (โจ Recommended - automatic venv):
# Add MCP server using uvx (handles venv automatically)
claude mcp add devops-practices -- uvx devops-practices-mcp
# Restart Claude Code/Desktop to activateWhy recommended: uvx automatically manages the virtual environment for you - no setup needed.
Option 3: Install with uv + venv (For Python developers):
# Install uv if you don't have it
curl -LsSf https://astral.sh/uv/install.sh | sh
# Create virtual environment
uv venv ~/.venvs/devops-practices-mcp
# Activate venv
source ~/.venvs/devops-practices-mcp/bin/activate
# Install MCP server
uv pip install devops-practices-mcp
# Add to Claude configuration (using venv's python)
claude mcp add devops-practices -- ~/.venvs/devops-practices-mcp/bin/python -m devops_practices_mcp
# Restart Claude Code/Desktop to activateWhy use this: Full control over the virtual environment with modern uv tooling.
Option 4: Install to user directory (Legacy - no venv):
# Install using pip (to ~/.local/)
pip install --user devops-practices-mcp
# Add to Claude configuration
claude mcp add devops-practices -- python3 -m devops_practices_mcp
# Restart Claude Code/Desktop to activateOption 5: Install system-wide (Requires sudo):
# Install system-wide (requires root)
sudo pip install devops-practices-mcp
# Add to Claude configuration
claude mcp add devops-practices -- python3 -m devops_practices_mcp
# Restart Claude Code/Desktop to activateOption 6: Manual configuration (Edit config files directly):
Install via pip or uvx, then edit ~/.claude/config.json:
{
"mcpServers": {
"devops-practices": {
"command": "uvx",
"args": ["devops-practices-mcp"],
"env": {}
}
}
}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 SOPsCopies 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("02-01-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 standardsResult: 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]Updating Practices
For Contributors:
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 standardsBranching 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 fixesBranch Types
Branch | Purpose | Created From | Merges To |
| Production releases (tagged) | - | - |
| Active development |
|
|
| New functionality |
|
|
| Version preparation |
|
|
| Critical fixes |
|
|
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 PR โ developCreate Release:
git checkout develop
git checkout -b release/v1.2.0
# Update CHANGELOG.md, version numbers
# Create PR โ main
# Tag release: git tag v1.2.0
# Merge back to developCritical Hotfix:
git checkout main
git checkout -b hotfix/critical-bug
# Fix, commit, push
# Create PR โ main (fast-track)
# Also merge to developFull 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
developUpdate practice or template files
Run health check:
bash health-check.shUpdate documentation (README.md, PRACTICE-INDEX.md)
Create PR with description โ
developCode review by team
Merge to
developafter CI/CD passes
For Releases:
Create release branch from
develop:release/v1.x.0Update CHANGELOG.md and version numbers
Create PR โ
mainTag release after merge:
git tag v1.x.0Merge release back to
developAnnounce to team (affects all dependent projects)
For Critical Fixes:
Create hotfix branch from
main:hotfix/issue-nameFix issue and test thoroughly
Create PR โ
main(fast-track approval)Tag hotfix release:
git tag v1.x.1Merge to
developto keep in syncAnnounce 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 neededTest 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 automaticallyTest 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
Symptoms: Claude doesn't return practices when asked, or acts like MCP doesn't exist
Solutions:
Remind Claude explicitly: "Please check the devops-practices MCP server and list available practices"
Verify MCP is loaded: Ask "What MCP servers do you have access to?"
Check configuration: Verify
~/.claude/config.jsonhas correct paths (must be absolute paths)Restart Claude Code: MCP servers load on startup
Check logs: Look at
~/.cache/claude/mcp-devops-practices.logfor errorsVerify MCP process: Run
ps aux | grep mcp-server.pyto confirm it's running
๐ก Pro Tip: Claude sometimes "forgets" to check MCP servers. Explicitly remind it to verify the MCP before proceeding with tasks.
Log location: ~/.cache/claude/mcp-devops-practices.log
MCP Server is Down or Unavailable
Symptoms: MCP server process crashed, not responding, or cannot start
Fallback Options:
Option 1: GitHub Practices (Recommended)
Access practices directly from GitHub:
https://github.com/ai-4-devops/devops-practices/tree/main/practices
Ask Claude to read practices via GitHub URLs when MCP unavailable.Option 2: Local Clone
# Access practices from local clone
ls ~/.mcp-servers/devops-practices-mcp/practices/
# Read practice directly
cat ~/.mcp-servers/devops-practices-mcp/practices/03-02-air-gapped-workflow.mdOption 3: CLAUDE.md Appendix
Projects using the CLAUDE-template.md have a built-in appendix
with critical practice summaries for emergency fallback.
See: templates/CLAUDE-template.md (Appendix section)Prevention:
Use .mcp.json for project-level config (more reliable)
Add MCP health check to pre-session checklist
Keep local clone updated:
git pull origin mainMonitor logs:
tail -f ~/.cache/claude/mcp-devops-practices.log
Related: MIGRATION-GUIDE.md for project-specific fallback setup
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-20 Version: 1.4.0
Available Tools
5 toolsget_practiceB
Get a DevOps practice document by name
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the practice (e.g., "air-gapped-workflow", "documentation-standards") |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure; it does communicate a read-only retrieval operation on a named document. However, it says nothing about return format, missing-name errors, or any constraints, leaving some behavioral ambiguity for a tool without an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that conveys the core operation without filler. Every word contributes to purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter retrieval tool, the description is mostly sufficient: it names the operation and key parameter. Its main gaps are the lack of a pointer to list_practices for valid names and no mention of the return payload, but the tool's simplicity limits the downside.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the single 'name' parameter with examples at 100% coverage, so the description's reference to 'by name' adds little new meaning. This matches the baseline score for fully documented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get'), a concrete resource ('DevOps practice document'), and the lookup method ('by name'). It is unambiguous, though it does not explicitly contrast with sibling tools like get_template or list_practices, so it relies on resource naming for differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to choose this tool over alternatives such as list_practices for discovering valid names or get_template for a different resource type. An agent can infer the use case from the name and schema, but the description does not state exclusions or fallback tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_templateB
Get a file template by name
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the template (e.g., "TRACKER-template", "CURRENT-STATE-template") |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get' without specifying whether the return value is raw file content, metadata, or something else, nor does it mention error behavior or side effects. For a retrieval tool this is a minimal but notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one direct sentence with no wasted words, and the core action and resource are front-loaded. For a simple one-parameter tool, this is appropriately concise and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one required parameter, no output schema, no annotations), the description is nearly sufficient for making a correct call. However, it does not clarify what a file template is or what the tool returns, and since there is no output schema, that missing return-value context leaves a gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's 'by name' aligns with the required name parameter but adds no meaning beyond the schema's own examples like 'TRACKER-template'. The schema already fully documents parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('file template by name'), so an agent can tell this fetches a specific template. However, it does not explicitly distinguish itself from siblings like list_templates or render_template, leaving some ambiguity about the difference between getting a raw template and rendering one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus the listed sibling tools such as list_templates or render_template. The description does not mention alternatives, prerequisites, or scenarios where another tool would be more appropriate. Usage context must be entirely inferred from the name and parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_practicesA
List all available DevOps practices
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It does imply a read-only, exhaustive enumeration via 'all available,' but it gives no detail on output structure, ordering, or whether results are summaries or full objects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence with no filler. Every word contributes meaning and the description is appropriately minimal for a zero-parameter listing tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list-all tool, the description is mostly sufficient, but it omits what the returned list contains (names vs full details) and how it relates to get_practice. Without an output schema, a bit more context would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so the description is not required to explain parameter semantics. The baseline for 0 params is 4, and nothing is lacking here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'List all available DevOps practices.' It clearly distinguishes from siblings like get_practice (singular fetch) and list_templates (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool instead of get_practice or list_templates. The description only states the action, with no context, exclusions, or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_templatesA
List all available file templates
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but the operation is a simple read-only list; the word 'List' implies no side effects. However, it does not disclose return format, pagination, or what 'available' means in terms of permissions or state, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with no filler, saturated with the core action and resource. It is optimally concise for a trivial list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description is adequate, but it leaves unexplained what exactly a 'file template' is, what the response list contains, and how this tool relates to sibling template operations. The lack of an output schema amplifies these omissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters, so there is no parameter burden for the description to carry. The baseline of 4 applies per the rubric for 0-param tools, and the description adds no unnecessary parameter-related details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('List') and resource ('all available file templates'), making the tool's purpose immediately obvious. It is naturally distinguished from siblings like get_template and render_template because listing all templates is a different operation scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as get_template or render_template. There is no mention of context, prerequisites, or exclusion criteria, so an agent must infer usage entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
render_templateA
Render a template with variable substitution. Supports ${VAR} format. Auto-provides DATE, TIMESTAMP, USER, YEAR.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the template (e.g., "TRACKER-template", "RUNBOOK-template") | |
| variables | No | Dictionary of variables to substitute (e.g., {"PROJECT_NAME": "my-project", "SESSION_NUMBER": "1"}) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses the ${VAR} substitution format and the auto-provided variables (DATE, TIMESTAMP, USER, YEAR), which is useful, but it does not explain behavior for missing variables, precedence over user-supplied values, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, starting with the core purpose and then adding format and auto-provided variables. Every sentence contributes new information without excess verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description captures the main function and variable behavior, but it leaves the return value implicit (rendered text) and does not cover edge cases like missing variables or conflicts with auto-provided names. Adequate but with noticeable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents both parameters and their composition. The description adds the substitution syntax but no per-parameter semantics beyond what the schema provides, matching the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Render a template with variable substitution,' a specific verb and object that clearly defines the action. This differentiates it from sibling tools like get_template and list_templates, which fetch or list rather than produce a substituted output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this tool when you need a template rendered with variables. However, it does not explicitly state when not to use it or point to alternatives (e.g., get_template for the raw template source), leaving the distinction to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
5 tool updates
v1.4.0- First observed
get_practice - First observed
get_template - First observed
list_practices - First observed
list_templates - First observed
render_template
TDQS
Scored across 5 tools
Each tool targets either practices or templates, with separate list/get operations and a distinct render action. The resource nouns in tool names make selection unambiguous.
All tool names follow a consistent verb_noun pattern: list_practices, get_practice, list_templates, get_template, render_template. The naming is predictable and easy to navigate.
Five tools is well-scoped for a DevOps practices and templates server. Each tool serves a clear purpose without unnecessary overlap or bloat.
The set covers listing and retrieving practices, listing and retrieving templates, plus rendering templates with variable substitution. This is complete for a read-and-render reference server, with no obvious dead ends.
Maintenance
Related MCP Connectors
DORA OS Conductor โ 16-tool meta-orchestrator for DORA compliance workflow automation.
AI-native Day 0 modernization platform for PRDs, architecture, work orders, and code transformation.
Plan a Virtual Delivery Center for any initiative: pods, roles, AI agents, Delivery Units.
Claude Code / MCP skills for the dev pipeline: discover, spec, design, build, ship, operate.
Related MCP Servers
- AlicenseNot gradedqualityAmaintenanceEnables intelligent Kubernetes deployments, automated documentation testing, organizational pattern management, and shared prompt libraries. Provides AI-powered recommendations based on cluster capabilities and automates DevOps workflows through conversational interfaces.650 npm335MIT
- FlicenseBqualityNot gradedmaintenanceEnables systematic document organization with PDF-to-Markdown conversion, intelligent categorization, and automated workflow management. Supports project documentation standards and provides complete end-to-end document processing pipelines.8-

CLP MCP - DevOpsofficial
-licenseNot gradedqualityNot gradedmaintenanceEnables comprehensive DevOps infrastructure management through tools for Jenkins, Ansible, Terraform, Kubernetes, and Docker operations. Features a sophisticated memory system for context retention and provides validation, generation, and optimization capabilities across DevOps workflows.1-- -licenseNot gradedqualityNot gradedmaintenanceEnables AI assistants to generate professional documentation using structured templates based on the POWER framework. Provides access to standardized templates for README, architecture, API, components, and schema documentation.-