Publishing an MCP Server: The First DevOps Entry in Anthropic's Registry

Open https://registry.modelcontextprotocol.io and search “devops.”

One result.

io.github.ai-4-devops/devops-practices - the first and only DevOps-focused MCP server in Anthropic’s official registry as of February 2026.

Published. Live. Solving real team consistency problems for infrastructure engineers using Claude Code. Result of hours and days spent solving a nagging problem that wouldn’t quit.

But three months ago, I wasn’t thinking about publishing to registries. I was thinking about how to stop engineers from producing inconsistent documentation across parallel PoCs. How a 580-line CLAUDE.md file kept drifting across projects. How standards that worked for one engineer didn’t propagate to others.

This is how that problem became the only DevOps entry in the MCP Registry - every error message, wrong turn, and lesson learned along the way.

The Problem That Started This

I was mentoring a group of engineers from DevOps-Den through cutting-edge proof-of-concept projects.

Multiple team members. Multiple PoCs running in parallel. Critical work - these weren’t lab experiments. They were validation projects supporting onsite production teams who needed answers fast.

The problem surfaced within the first week.

Engineer A would deploy infrastructure one way. Engineer B would document it differently. Engineer C would follow a third approach entirely. Same technology. Same goals. Completely inconsistent outputs.

The root cause wasn’t skill - it was absence of shared standards.

Each engineer had their own CLAUDE.md file with instructions for Claude Code. Some were 200 lines. Some hit 580+ lines. When I updated a best practice in one project, it didn’t propagate to others. By the third PoC, engineers were following different standards than they had in the first.

The stakes were real: These weren’t lab experiments. They were PoCs for pre-production validation - technology evaluation work that would directly influence production adoption decisions. Inconsistent approaches meant unreliable validation results. That wasn’t acceptable.

What I needed was centralized standards that every project - and every engineer - could query. Same practices. Same templates. Same quality bar.

That’s what Model Context Protocol (MCP) servers are for. And that’s what I built.

What I Built (And Why It Matters for Teams)

DevOps Practices MCP Server provides shared infrastructure knowledge for teams using Claude Code to build proof-of-concepts and production systems.

What it contains:

• 11 Best Practices - Session continuity, task tracking, git workflows, configuration management, air-gapped deployments, documentation standards
• 7 Templates - TRACKER.md, CURRENT-STATE.md, RUNBOOK.md, ISSUES.md, plus a full in-repo issue tracking system
• 7 MCP Tools - Functions Claude calls to access content: get_practice, get_practice_summary, list_practices, search_practices, get_template, list_templates, render_template

What problem it solves: The team consistency problem. Instead of maintaining massive CLAUDE.md files that drift across projects, you write standards once in an MCP server. Every project - every engineer - queries the same source. No drift. No duplication. One update propagates everywhere.

This solves the exact problem described in my recent article on agentic AI development systems. That article outlined Phase 3: Centralized Standards via MCP as a theoretical architecture pattern for code generation. This MCP server is that pattern, implemented for operational standards. Same principle - centralized, versioned, queryable knowledge - different domain. Code agents need engineering standards. DevOps teams need operational practices. Both benefit from externalizing standards into infrastructure that AI can query automatically.

Why this matters for team leads:

When you’re mentoring engineers through complex PoCs, you can’t be in every Slack channel, every screen share, every decision point. The MCP becomes your operational documentation that Claude enforces automatically. An engineer starting a new PoC doesn’t ask “how should I document this?” - Claude queries the MCP and gets the answer. Consistency without micromanagement.

What makes it unique: Most MCP servers focus on code generation, data analysis, or content creation. This one focuses on infrastructure practices, documentation patterns, and operational templates.

It’s prescriptive, not generative. It provides proven practices, not generated code. Built from real mentoring experience, not theoretical best practices.

The Real-World Impact: Multi-Team PoC Consistency

Scenario: Three engineers conducting Kubernetes observability stack validation for pre-production technology evaluation.

Without MCP (Week 1):

• Engineer A uses Prometheus + Grafana, documents in custom format (4 hours setup)
• Engineer B uses same stack but different documentation structure (5 hours, incompatible with A’s format)
• Engineer C copies B’s approach but misses critical configurations (6 hours, needed rework)
• Each PoC presents different conclusions to stakeholders
• Production teams receive inconsistent validation results for adoption decisions

With MCP (Week 2 onward):

• All three engineers query get_practice("03-01-configuration-management") for deployment SOPs
• Claude renders RUNBOOK-template with consistent structure across all three PoCs
• All three use get_practice("04-03-runbook-documentation") for session logs
• Production teams receive consistent, comparable validation results for informed adoption decisions
• Time savings: 40% reduction in setup + rework time
• Quality improvement: Zero documentation inconsistencies flagged in reviews

The hidden win: New engineers joining the team didn’t need extensive onboarding on “how we do things here.” Claude Code with the MCP enforced standards from day one.

The Publishing Journey (What Actually Happened)

Publishing an MCP server isn’t “run a command and it works.” It’s navigating multiple systems - GitHub, PyPI, and the MCP Registry - each with its own validation rules.

Here’s what that journey looked like.

Phase 1: The MCP Registry Submission Attempts

Anthropic’s MCP Registry offers two submission methods:

1. Discussion-based: Manual review by maintainers
2. CLI-based: Automated validation and publishing

I did both for redundancy.

Discussion submission went smoothly. Posted comprehensive details at https://github.com/modelcontextprotocol/registry/discussions/974. Waiting for manual review.

CLI-based publishing was where the learning happened.

Phase 2: The server.json Evolution

The server.json file went through 6+ iterations before passing validation. Here are the key errors and fixes:

The Critical Blocker:

Attempted:

1
2
3
4
5
6

{
  "packages": [{
    "registryType": "github",
    "identifier": "ai-4-devops/devops-practices"
  }]
}

Error: unsupported registry type: github

Supported types: npm, pypi, nuget, maven

This was the turning point. CLI-based publishing blocked. Needed to publish to PyPI first.

Phase 3: The PyPI Pivot

GitHub wasn’t a supported registry type. Needed to publish to PyPI first.

Restructured the project to proper Python packaging (src layout, pyproject.toml), used uv for building and publishing (5 seconds to build, 30 seconds to publish - orders of magnitude faster than pip workflows), and pushed to PyPI.

The complete packaging migration, file structure, token scoping decisions, and commands are documented in JOURNEY.md.

Key lesson: Modern Python packaging matters. Using src layout and tools like uv made updates and republishing trivial instead of painful.

Phase 4: The Ownership Validation Error

Attempted:

1

~/registry/bin/mcp-publisher publish server.json

Error:

1
2
3

PyPI package 'devops-practices-mcp' ownership validation failed.
The server name 'io.github.ai-4-devops/devops-practices' must appear as
'mcp-name: io.github.ai-4-devops/devops-practices' in the package README.

The Fix: Added marker to README.md:

1
2
3
4
5

# DevOps Practices MCP Server

mcp-name: io.github.ai-4-devops/devops-practices

AI-powered DevOps knowledge base providing best practices and templates...

Why? This proves PyPI package ownership. It links the PyPI package to the MCP server name. Without it, anyone could publish a PyPI package and claim it as an MCP server they don’t control.

Since README changed, needed version bump to 1.3.1. Rebuilt. Republished to PyPI.

Phase 5: The Final Success

1

~/registry/bin/mcp-publisher publish server.json

Output:

1
2
3
4
5
6
7
8

Publishing server io.github.ai-4-devops/devops-practices to version 1.3.1
Resolving package identifier: devops-practices-mcp
Downloading package from pypi
Extracting package
Validating package
Searching for 'mcp-name: io.github.ai-4-devops/devops-practices' in README
✓ Successfully published
✓ Server io.github.ai-4-devops/devops-practices version 1.3.1

Published. Live. Official.

Version 1.4.0: The Stability Release

A week after v1.3.1 went live, engineers hit a critical bug: stdio protocol corruption from stderr logging. Claude couldn’t communicate reliably with the MCP server. Engineers would query successfully for the first few requests, then fail unpredictably.

The fix: File-only logging to ~/.cache/claude/mcp-devops-practices.log. No stderr output. Clean stdio protocol. Server stability jumped from “works sometimes” to production-ready.

Also reorganized all 11 practices with GG-SS prefix patterns (Group-Sequence) for better discoverability and added 2 new MCP tools.

Full details in CHANGELOG.

What This Means (Positioning and Context)

When you search “devops” in the MCP Registry, this is the only result.

That’s not because DevOps teams aren’t using AI. It’s because most MCP servers 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)
• Documentation patterns (TRACKER, ISSUES, runbook templates)
• Operations templates (session handoff, SoP formats)
• Structured guidance (GG-SS organized practices)

It’s infrastructure-first. Built for ops teams, not developers. Reusable patterns across all your projects. AI-native design organized for Claude to query contextually.

Perfect for: Team leads mentoring engineers through PoCs. DevOps engineers building production systems with Claude Code. Anyone who needs consistent outputs across multiple projects and team members.

Team Adoption: What Changed After the MCP

Before MCP (mentoring friction):

• Engineers asking “how should I structure this?” multiple times per PoC
• Inconsistent documentation across team members
• Repetitive Slack conversations explaining the same standards
• Quality reviews flagging format inconsistencies
• Onboarding new engineers taking 2-3 days on “our way of doing things”

After MCP (automatic consistency):

• Engineers query MCP directly via Claude - no Slack needed for standards questions
• Documentation automatically follows team patterns
• Quality reviews focus on technical content, not format
• New engineers productive from day one - Claude enforces standards automatically
• Time saved: ~40% reduction in mentoring overhead for documentation and process questions

The unexpected win: Engineers started contributing practice improvements back to the MCP. When someone discovered a better workflow, they’d submit a PR to update the practice. The MCP became living team knowledge, not static documentation.

Lessons Learned (For Anyone Publishing an MCP Server)

1. MCP Registry Submission is Iterative

server.json schema is strict. Expect multiple validation failures. Read error messages carefully - they’re specific and guide you to solutions.

2. Not All Registry Types Are Supported

GitHub is NOT a supported registry type (as of February 2026). You need to publish to PyPI, npm, nuget, or maven first.

3. PyPI Packaging Matters

Use modern Python packaging (src layout, pyproject.toml with complete metadata, tools like uv). It pays dividends in discoverability and ease of updates.

4. The Ownership Validation Requirement

mcp-name: namespace/server-name in your README is required. This links your PyPI package to your MCP server identity. Without it, publishing fails.

5. Registry Structure Evolves

The MCP registry CLI path changed between v1.3.1 and v1.4.0 (from cli/mcp-publisher to cmd/publisher). Always check current repository structure. Don’t blindly follow old documentation.

6. Stability Over Features

The critical logging fix in v1.4.0 taught me: a broken MCP server is worse than no MCP server. When you’re supporting a team relying on the MCP for critical PoCs, stability matters more than feature count. Test stdio protocol thoroughly.

7. Version Everything Consistently

When bumping versions, update:

• pyproject.toml
• src/package/init.py
• server.json (in two places: root version and package version)
• CHANGELOG.md

Miss one, and you’ll create confusion across your team.

8. CI/CD Builds Team Trust

When engineers are using your MCP server in production PoCs, they need confidence that updates won’t break their workflow. GitHub Actions with comprehensive validation jobs signals “this is professionally maintained infrastructure, not a personal script.”

What’s Next

Immediate:

• Waiting for manual review of Discussion submission
• Monitoring GitHub Issues for bug reports and feature requests from the team
• Considering additional practices based on feedback from DevOps-Den engineers

Longer-term:

• Explore if GitHub registry type support gets added to MCP
• Consider npm packaging for easier installation via npx
• Build additional companion tooling (issue-manager.sh is first iteration)

Community: If you’re mentoring engineers through infrastructure PoCs and hitting the consistency problem, this MCP might help. If you’re publishing your own MCP server, the JOURNEY.md file in the repository documents every error I hit and how to fix it.

Frequently Asked Questions

What is an MCP server and why does it matter for teams?

Model Context Protocol (MCP) is Anthropic’s standard for AI systems to query external knowledge services. An MCP server provides centralized, versioned knowledge that Claude can retrieve at runtime. For teams, this means writing standards once and having every engineer’s Claude Code instance query the same source. No drift, no duplication, automatic consistency across team members.

How does this solve the team consistency problem?

Instead of each team member maintaining their own CLAUDE.md file (which inevitably drifts), all team members query the same MCP server. Update the MCP server once, all team members benefit immediately. Claude enforces the same standards across all projects automatically. No manual synchronization needed.

Can engineers contribute improvements to the MCP?

Yes. MIT licensed, repository at https://github.com/ai-4-devops/devops-practices. When an engineer discovers a better workflow, they can submit a PR to update the practice. Review, merge, and the improvement propagates to the entire team automatically. The MCP becomes living team knowledge.

Installation instructions and usage examples are in the repository README.

Final Thoughts

Publishing an MCP server taught me more about scaling team knowledge than years of writing documentation ever did. The validation errors, the PyPI packaging requirements, the ownership verification - these aren’t obstacles. They’re quality gates that ensure the MCP Registry stays reliable.

The DevOps Practices MCP is live, stable, and solving real team consistency problems for infrastructure engineers using Claude Code.

If you’re mentoring engineers through PoCs and hitting the consistency problem, this is one solution that works in production. If you’re building your own MCP server, the JOURNEY.md file documents every error and fix along the way.

The infrastructure is live:

• GitHub: https://github.com/ai-4-devops/devops-practices
• PyPI: https://pypi.org/project/devops-practices-mcp/
• MCP Registry: https://registry.modelcontextprotocol.io/?q=devops

Questions? Issues? Contributions? https://github.com/ai-4-devops/devops-practices/issues

The Broader Shift: Machine-Readable DevOps Discipline

This MCP server represents something larger than solving a team consistency problem.

For decades, DevOps knowledge has lived in documentation that humans read and interpret. Runbooks in Confluence. Best practices in wikis. Standards in Slack threads. Knowledge that exists but isn’t executable. Every engineer interprets it slightly differently.

MCP servers change that. They make operational knowledge machine-readable, versionable, and automatically enforceable. When Claude Code queries this MCP, it’s not searching documentation and hoping to understand context. It’s loading precise, structured practices that were designed to be executed, not just read.

This is DevOps discipline as infrastructure. Standards that can’t drift because they’re retrieved at runtime, not copied. Practices that evolve in one place and propagate everywhere automatically. Knowledge that AI agents consume directly, without human translation.

The agentic AI architecture I wrote about previously needs this. Multi-agent systems building software at scale require centralized standards they can query deterministically. This MCP proves the pattern works - not just for code generation, but for operational practices, infrastructure patterns, and team coordination.

When every team’s operational knowledge becomes machine-readable and queryable via MCP, the compounding effect will reshape how distributed teams work. Not because documentation improves. Because documentation becomes executable infrastructure.

That’s the shift this represents. And it starts with solving the 580-line CLAUDE.md problem.

If it’s not written down and enforced automatically, it doesn’t scale. That’s what this MCP is for.