The MCP Catalog: Curating Internal Servers for a 200-Engineer Org

Table of Contents

1. What is an MCP Catalog and Why It Matters
2. The Four Pillars: Discovery, Ownership, Deprecation, and Evaluation
3. Building Your Discovery Layer
4. Establishing Clear Ownership Models
5. Managing Deprecation Without Breaking the Org
6. The Evaluation Gate: Your Quality Gatekeeper
7. Real-World Implementation at Scale
8. Security and Compliance in Your MCP Catalog
9. Tools and Infrastructure
10. Summary and Next Steps

---

What is an MCP Catalog and Why It Matters

The Model Context Protocol (MCP) has fundamentally changed how large engineering organisations structure their internal tooling. Instead of scattered scripts, custom integrations, and siloed knowledge, teams now standardise on a protocol that lets Claude and other AI systems interact with internal services as first-class citizens.

But standardisation at scale creates a problem: how do you manage 50, 100, or 200+ internal MCP servers across a 200-engineer organisation without descending into chaos? How do engineers discover what’s available? Who owns each server? When should you retire something? How do you ensure quality without becoming a bottleneck?

This is the MCP catalog problem.

An MCP catalog is not just a list of servers. It’s a curated, discoverable, governed marketplace of internal tools that your engineering teams depend on. Think of it like a private npm registry, but for AI-powered integrations with your databases, APIs, legacy systems, and operational infrastructure.

The stakes are real. A poorly managed catalog leads to duplicate effort, security gaps, outdated servers running in production, and engineers wasting time hunting for tools that may or may not exist. A well-managed catalog multiplies force: teams ship faster, reduce toil, and compound the value of every internal investment.

Large organisations like Siemens have already solved this at scale with their own MCP catalog, and the patterns they’ve pioneered—discovery, ownership, deprecation, and evaluation gates—are now the standard playbook for any org with 100+ engineers.

The Four Pillars: Discovery, Ownership, Deprecation, and Evaluation

Before diving into implementation, understand the four forces that govern a healthy MCP catalog:

Discovery: Making Servers Findable

If your teams don’t know a server exists, it doesn’t exist to them. They’ll build a replacement, duplicate effort, and waste weeks.

Discovery means:

• Centralized registry: A single source of truth (not Slack, not confluence, not scattered docs) where every server is listed with metadata.
• Searchable by domain: Engineers should find servers by what they do (“database”, “logging”, “billing”), not by who built them.
• Clear descriptions and examples: Every server entry includes what it does, who owns it, how to use it, and a working code example.
• Usage metrics: Track which servers are actually used. Unused servers signal deprecation candidates.

Discovery is the first gate. If it fails, the entire catalog fails.

Ownership: Assigning Accountability

Every server must have a clear owner. Not “the platform team”, not “whoever wrote it”. A named person or small team (2–3 people) who:

• Responds to issues and questions within 48 hours.
• Maintains the server’s schema and documentation.
• Handles upgrades and breaking changes.
• Owns the decision to deprecate.

Without clear ownership, servers rot. They break silently, accumulate technical debt, and eventually become liabilities.

Deprecation: Retiring Servers Gracefully

Servers don’t live forever. Some become obsolete as your infrastructure evolves. Others are replaced by better alternatives. A good deprecation strategy:

• Signals intent early: Six weeks’ notice before removal, minimum.
• Provides migration paths: If you’re retiring a server, tell teams what to use instead.
• Tracks migration progress: Know how many teams are still using the old server and help them migrate.
• Sets a hard deadline: After the deadline, the server is gone. No exceptions.

Deprecation without a plan is chaotic. Deprecation with a plan is professional.

Evaluation Gate: The Quality Checkpoint

Not every server should join the catalog. An evaluation gate ensures:

• Security baseline: Does it pass basic security review? Are credentials handled correctly?
• Documentation quality: Can a new team member understand it in 15 minutes?
• Ownership clarity: Is there a named owner?
• Performance: Does it meet latency and reliability SLAs?
• Compatibility: Does it work with the latest MCP spec?

The gate is a one-time check before a server enters the catalog. It’s not a bottleneck—it’s a quality filter that protects the entire org.

Building Your Discovery Layer

Discovery is where most organisations fail. They build the servers but neglect the visibility layer. Here’s how to build one that actually works.

The Central Registry

Your registry should be:

• Version-controlled: Stored in Git, reviewed like code.
• Searchable: Indexed by name, description, tags, and owner.
• Machine-readable: JSON or YAML format so tooling can consume it.
• Timestamped: Include creation date, last update, and deprecation status.

A minimal entry looks like:

name: database-query-server
owner: data-platform-team
description: |
  Execute read-only queries against PostgreSQL production databases.
  Supports parameterized queries and result streaming.
version: 1.2.3
mcp_spec_version: "0.8"
status: active
deprecation_date: null
repository: https://github.com/yourorg/mcp-database-query
docs_url: https://docs.internal.yourorg.com/servers/database-query
example_usage: |
  {
    "query": "SELECT * FROM users WHERE id = ?",
    "params": [123]
  }
tags:
  - database
  - postgresql
  - read-only
last_updated: 2025-01-15
usage_count_monthly: 847

This single source of truth becomes the backbone of your discovery system.

Building the Discovery Interface

Your registry is useless if engineers can’t find it. Build multiple entry points:

1. Web dashboard: A searchable, filterable interface where teams browse servers by tag or keyword. Include owner contact, documentation links, and usage stats.

2. CLI tool: A command-line utility (mcp-catalog search database, mcp-catalog info database-query-server) for teams already in the terminal.

3. IDE integration: For teams using VS Code or JetBrains, a plugin that surfaces available servers as you write code.

4. Slack integration: A bot that responds to queries like “@mcp-bot find billing servers” and returns top matches.

5. API endpoint: A simple REST API that returns server metadata, used by internal tools and dashboards.

The more discovery surfaces you create, the more discoverable your catalog becomes. This is not overhead—it’s the core product.

Tagging and Categorisation

Tags are your discovery taxonomy. Use consistent, hierarchical tags:

• Domain tags: database, api, messaging, logging, billing, auth, infrastructure
• Type tags: read-only, write-enabled, async, streaming, real-time
• Maturity tags: experimental, beta, stable, legacy
• Compliance tags: soc2-audited, pii-aware, encrypted

Enforce a controlled vocabulary. Don’t let teams invent new tags—this destroys discoverability.

Usage Metrics and Analytics

Track which servers are actually used. This informs:

• Deprecation decisions: Low-usage servers are candidates for retirement.
• Investment priorities: High-usage servers deserve more maintenance resources.
• Adoption barriers: If a useful server has low usage, something is wrong with discovery or documentation.

Collect metrics like:

• Monthly active users per server
• Request volume and latency
• Error rates
• Documentation page views
• Time-to-first-use for new servers

This data drives decisions. Without it, you’re guessing.

Establishing Clear Ownership Models

Ownership is where accountability lives. Get this wrong, and your catalog becomes a graveyard of unmaintained servers.

Single Owner Model

Each server has one owner: a named engineer or small team (2–3 people) who:

• Responds to questions: 48-hour SLA for questions in Slack or email.
• Maintains documentation: Keeps docs up-to-date with each release.
• Handles incidents: If the server breaks, they’re on call.
• Owns deprecation decisions: They decide when to retire the server.
• Manages upgrades: They handle MCP spec updates and breaking changes.

The owner is listed in the registry and visible on the discovery dashboard. If you don’t know who owns a server, it’s not in your catalog.

Team Ownership for Large Servers

For critical servers (databases, authentication, billing), ownership should be a team responsibility:

• Primary owner: The person responsible for day-to-day maintenance.
• Backup owner: Covers when the primary is unavailable.
• Team rotation: Every 6 months, rotate who’s primary to spread knowledge.

This prevents single points of failure and builds redundancy.

Ownership Transition

When an owner leaves the organisation:

1. 30-day handoff period: The departing owner and their replacement work together to transfer knowledge.
2. Documentation audit: All server documentation is reviewed and updated.
3. Ownership transfer: The registry is updated to reflect the new owner.
4. Announcement: Teams are notified of the change.

Without a formal transition process, knowledge walks out the door with the person.

Ownership SLAs

Make ownership expectations explicit:

• Response time: Answer questions within 48 hours.
• Documentation: Keep docs current within 7 days of any change.
• Availability: Maintain 99.5% uptime SLA for critical servers.
• Security: Respond to security issues within 24 hours.
• Deprecation notice: Provide 6 weeks’ notice before retiring a server.

If an owner can’t meet these SLAs, the server shouldn’t be in the catalog. Move it to a “community” section or retire it.

Managing Deprecation Without Breaking the Org

Deprecation is where most organisations stumble. They either leave dead servers in the catalog forever, or they yank them out and break production systems.

The Deprecation Lifecycle

A server moves through phases:

Phase 1: Active

• Server is maintained and supported.
• Teams can freely use it.
• Owner responds to issues.

Phase 2: Deprecation Announced (Week 1)

• Owner decides the server is no longer needed.
• Deprecation date is set (minimum 6 weeks out).
• Registry is updated with deprecation status.
• Announcement is sent to all teams using the server (identified via usage metrics).
• Migration guide is published (“Use server-b instead”).

Phase 3: Migration Window (Weeks 2–6)

• Server continues to work normally.
• Owner actively helps teams migrate.
• Usage metrics show migration progress.
• If adoption is slow, extend the window by 2–4 weeks.

Phase 4: Sunset (Week 7)

• Server is removed from the registry.
• API endpoints return a “deprecated” error.
• Teams that haven’t migrated are contacted directly.

Phase 5: Removal (Week 8+)

• Server infrastructure is decommissioned.
• Documentation is archived.
• Owner closes all related issues and tickets.

Tracking Migration Progress

Use your usage metrics to track which teams are still using the deprecated server. Create a migration tracker:

deprecated_server: old-billing-api
replacement_server: new-billing-api
deprecation_date: 2025-03-15
teams_still_using:
  - payments-team: 450 requests/day (contacted 2025-01-20)
  - accounting-team: 200 requests/day (contacted 2025-01-20)
  - finance-team: 50 requests/day (migrated 2025-02-01)
migration_deadline: 2025-03-15
status: in-progress

This visibility drives accountability. Teams know you’re tracking them, and they migrate faster.

Handling Blockers

Some teams can’t migrate easily. Common blockers:

• Custom integrations: The new server doesn’t support their use case.
• Legacy systems: They can’t upgrade their client library.
• Resource constraints: They don’t have bandwidth to migrate.

For each blocker:

1. Understand it: Get specifics on what’s blocking migration.
2. Find a solution: Can the new server add support? Can the team get help migrating?
3. Extend the deadline: If necessary, give them more time (but set a hard new deadline).
4. Escalate if needed: If a critical team can’t migrate, escalate to engineering leadership.

The key is transparency. Teams should never be surprised by a deprecation deadline.

The Evaluation Gate: Your Quality Gatekeeper

The evaluation gate is a one-time check that every server passes before it joins the catalog. It’s not a review board—it’s a quality filter.

The Gate Checklist

Documentation (5 points)

• Server has a clear, one-paragraph description.
• README includes usage examples.
• Error codes are documented.
• Owner and contact info are listed.
• Any breaking changes from previous versions are documented.

Security (10 points)

• Credentials are stored in environment variables, not hardcoded.
• No sensitive data (API keys, passwords) in logs.
• Input validation is implemented.
• SQL injection and similar attacks are prevented.
• If the server accesses PII, it’s marked with a PII tag.
• Rate limiting is implemented for public-facing endpoints.
• Access control is enforced (if applicable).
• Encryption is used for sensitive data in transit and at rest.
• No known vulnerabilities in dependencies.
• Security audit trail is maintained.

Performance (5 points)

• Latency is under 500ms for 95th percentile (or documented).
• Throughput supports expected usage (documented).
• Caching is implemented where appropriate.
• No N+1 query patterns.
• Resource usage (CPU, memory) is reasonable.

Reliability (5 points)

• Uptime is 99.5% or better over the past month.
• Errors are handled gracefully (no crashes).
• Retry logic is implemented for transient failures.
• Health checks are available.
• Monitoring and alerting are configured.

Compatibility (5 points)

• Server implements the current MCP spec (0.8+).
• Works with at least two MCP clients (Claude, etc.).
• No deprecated MCP features are used.
• Version is bumped according to semver.
• Changelog is maintained.

Ownership (5 points)

• Owner is named and has agreed to maintain the server.
• Owner has contact info in the registry.
• Owner has agreed to the SLA (48-hour response time).
• Backup owner is identified for critical servers.
• Transition plan is in place if owner leaves.

Total: 35 points

Servers need 30+ points to pass the gate. Below 30, they’re returned for fixes and resubmitted.

Who Runs the Gate?

The gate should be run by a small team (2–3 people) who:

• Understand MCP deeply: They know the spec, common pitfalls, and best practices.
• Care about quality: They’re not rubber-stamping servers; they’re raising the bar.
• Are responsive: They review submissions within 5 business days.
• Are fair and consistent: They apply the same standards to every server.

This team is not gatekeepers—they’re quality coaches. They should help server owners fix issues, not just reject submissions.

Handling Gate Rejections

When a server doesn’t pass:

1. Provide specific feedback: List which checklist items failed and why.
2. Offer help: If it’s a documentation issue, help write the docs. If it’s a security issue, connect them with the security team.
3. Set a resubmission deadline: Give them 2 weeks to fix and resubmit.
4. Track resubmissions: Make sure they’re actually improving, not just resubmitting unchanged.

A rejected server is not a failure—it’s an opportunity to improve the catalog’s quality.

Real-World Implementation at Scale

How does this work when you have 50+ servers and 200 engineers? Here’s a battle-tested approach.

Phase 1: Inventory (Weeks 1–2)

First, find all existing internal servers:

1. Survey the org: Ask each team what servers they’ve built or depend on.
2. Audit repositories: Search your Git for MCP server code.
3. Interview senior engineers: They know about servers that aren’t documented.
4. Check production: See what’s actually running.

You’ll find 20–50 servers you didn’t know existed. Document them all, even if they’re rough.

Phase 2: Triage (Weeks 3–4)

Now categorise what you found:

• Keeper: Actively used, worth maintaining.
• Sunset: Obsolete, should be deprecated.
• Orphan: No clear owner, needs adoption.
• Duplicate: Multiple teams built the same thing.

For each keeper, assign a temporary owner. For sunsets, plan deprecation. For orphans, find an owner or retire them. For duplicates, consolidate.

Phase 3: Build the Registry (Weeks 5–6)

Create your central registry (Git repo, YAML files):

mcp-catalog/
├── servers/
│   ├── database-query.yaml
│   ├── billing-api.yaml
│   ├── auth-server.yaml
│   └── ...
├── docs/
│   ├── getting-started.md
│   ├── adding-a-server.md
│   └── deprecation-policy.md
├── tools/
│   ├── validate.py
│   ├── publish.py
│   └── metrics.py
└── README.md

Each server gets a YAML file with metadata. Use a CI/CD pipeline to validate every submission.

Phase 4: Set Up Discovery (Weeks 7–8)

Build your discovery interfaces:

1. Web dashboard: A simple static site that reads the registry and renders a searchable catalog.
2. CLI tool: A Python or Go tool that queries the registry.
3. Slack bot: A bot that responds to catalog queries.

Start simple. A web dashboard is enough for launch. Add complexity later.

Phase 5: Establish Ownership (Week 9)

Make ownership explicit:

1. Contact every owner: Confirm they’re willing to maintain their server.
2. Document SLAs: Send them the ownership SLA document.
3. Create an owners’ channel: A Slack channel where owners can ask questions and share knowledge.
4. Schedule monthly sync: Meet with owners once a month to discuss issues and deprecations.

Phase 6: Launch and Iterate (Week 10+)

Launch your catalog:

1. Announce it: Send a company-wide announcement with the dashboard link.
2. Hold a demo: Show teams how to discover and use servers.
3. Gather feedback: Ask teams what’s missing or confusing.
4. Iterate: Add features based on feedback.

Expect adoption to ramp over 4–6 weeks. Some teams will find it immediately useful; others will take time.

Security and Compliance in Your MCP Catalog

MCP servers often access sensitive systems: databases, payment APIs, customer data. Security is non-negotiable.

The Security Baseline

Every server in your catalog must:

1. Authenticate requests: Verify the caller is authorised.
2. Authorise actions: Ensure the caller can perform the requested action.
3. Encrypt sensitive data: In transit (TLS) and at rest (if stored).
4. Audit access: Log who accessed what and when.
5. Handle secrets securely: Use environment variables or a secrets manager, never hardcode.
6. Validate input: Prevent injection attacks and malformed requests.
7. Rate limit: Prevent abuse and DoS attacks.
8. Monitor and alert: Detect anomalies and security incidents.

This is the minimum. Some servers need more (e.g., servers accessing PII or payment data).

Security Review Process

Before a server joins the catalog:

1. Self-review: The owner completes a security checklist.
2. Peer review: Another engineer reviews the code for security issues.
3. Security team review (for sensitive servers): The security team audits servers accessing PII, payment data, or critical infrastructure.
4. Dependency scan: Automated tools check for known vulnerabilities in dependencies.

This is part of the evaluation gate. Security issues are a gate rejection.

Compliance Tagging

Tag servers with their compliance status:

• soc2-audited: Reviewed as part of SOC 2 audit.
• pii-aware: Handles personally identifiable information.
• encrypted: Uses encryption for sensitive data.
• audit-logged: All access is logged and auditable.

Teams can filter the catalog by compliance tags, making it easy to find servers that meet their requirements.

Incident Response

When a security issue is discovered in a server:

1. Notify the owner immediately: Don’t wait for a formal process.
2. Assess impact: How many teams are affected? What’s the risk?
3. Create a fix: The owner patches the issue.
4. Coordinate release: Deploy the fix to production.
5. Notify users: Tell teams using the server about the fix and when to upgrade.
6. Post-mortem: Document what happened and how to prevent it next time.

Speed matters. A security issue in a widely-used server should be fixed and deployed within 24 hours.

Tools and Infrastructure

You don’t need to build everything from scratch. Here’s what you need and where to find it.

The MCP Ecosystem

Start with the official Model Context Protocol documentation to understand the spec. Then explore the Awesome MCP Servers GitHub repository to see what’s already been built. Many of these servers are open-source and can be adapted for your use case.

For a more curated selection, check the MCP Servers Hub, which provides a browsable directory of production-ready servers. If you’re using Docker, Docker’s MCP catalog and toolkit offers trusted, pre-vetted servers for common workflows.

Building Your Registry

Your registry is a Git repo with YAML files. Tools you’ll need:

1. Validation: A script that checks every server entry against the schema.

   # Simple Python validator
   import yaml
   import sys
   
   with open('servers/database-query.yaml') as f:
       server = yaml.safe_load(f)
       assert 'name' in server
       assert 'owner' in server
       assert 'description' in server

2. Publishing: A script that publishes the registry to your web dashboard.

   # Build the static site
   python tools/publish.py
   # Deploy to your web server

3. Metrics collection: A script that queries your servers and collects usage data.

   # Collect usage metrics from each server
   for server in servers:
       usage = query_metrics(server['name'])
       update_registry(server['name'], {'usage_count_monthly': usage})

Discovery Tools

Web Dashboard: Use a static site generator like Hugo or Jekyll. Template:

<div class="server-card">
  <h3>{{ server.name }}</h3>
  <p>{{ server.description }}</p>
  <p><strong>Owner:</strong> {{ server.owner }}</p>
  <p><strong>Usage:</strong> {{ server.usage_count_monthly }} requests/month</p>
  <a href="{{ server.docs_url }}">Documentation</a>
</div>

CLI Tool: A simple Python script:

#!/usr/bin/env python3
import click
import yaml
import json

@click.command()
@click.argument('query')
def search(query):
    """Search for MCP servers."""
    with open('registry.yaml') as f:
        servers = yaml.safe_load(f)
    results = [s for s in servers if query.lower() in s['name'].lower()]
    print(json.dumps(results, indent=2))

if __name__ == '__main__':
    search()

Slack Bot: Use a framework like Bolt:

from slack_bolt import App

app = App(token=os.environ.get("SLACK_BOT_TOKEN"))

@app.message("find")
def handle_find(message, say):
    query = message['text'].replace('find', '').strip()
    servers = search_catalog(query)
    say(f"Found {len(servers)} servers matching '{query}'")

Monitoring and Metrics

You need visibility into:

1. Server health: Uptime, latency, error rate.
2. Usage: Which servers are used, how often, by whom.
3. Adoption: Are new servers being discovered and used?

Tools:

• Prometheus: Scrape metrics from each server.
• Grafana: Visualise metrics in dashboards.
• DataDog or New Relic: For comprehensive monitoring.

Minimal setup: Each server exposes a /metrics endpoint with Prometheus-compatible metrics. A Prometheus instance scrapes them every 30 seconds. Grafana visualises the data.

Summary and Next Steps

Building a curated MCP catalog is a strategic investment. It multiplies the value of every internal tool you build and makes your engineering org more efficient.

Here’s what you’ve learned:

1. Discovery: Make servers findable via a central registry, web dashboard, CLI, and Slack integration.
2. Ownership: Assign clear, accountable owners with defined SLAs.
3. Deprecation: Retire servers gracefully with 6+ weeks’ notice and migration support.
4. Evaluation: Gate every server with a quality checklist covering documentation, security, performance, reliability, and compatibility.
5. Implementation: Follow a phased approach: inventory, triage, registry, discovery, ownership, launch.
6. Security: Enforce authentication, authorisation, encryption, auditing, and input validation.
7. Tools: Use Git for version control, static sites for discovery, and Prometheus for metrics.

Getting Started

If you’re starting from scratch:

Week 1: Inventory all existing servers. Interview teams. Audit repositories.

Week 2: Triage servers into keeper, sunset, orphan, and duplicate buckets.

Week 3–4: Create a Git-based registry with YAML files for each server.

Week 5: Build a simple web dashboard that reads the registry and renders a searchable catalog.

Week 6: Set up a CLI tool for terminal-based discovery.

Week 7: Establish ownership. Contact every owner and confirm SLAs.

Week 8: Launch. Announce the catalog. Hold a demo. Gather feedback.

Week 9+: Iterate. Add features. Improve adoption.

Scaling Beyond 200 Engineers

At 200 engineers, you might have 50–100 servers. As you grow:

• Automate gate reviews: Use linters and automated security scanners to catch obvious issues.
• Decentralise ownership: Let teams own servers related to their domain. The platform team owns infrastructure servers.
• Specialise discovery: Add domain-specific catalogs (“database servers”, “API servers”, “infrastructure servers”).
• Invest in tooling: Build better dashboards, CLIs, and integrations as your catalog grows.
• Formalise governance: Document policies for deprecation, security, and ownership.

The principles stay the same. Discovery, ownership, deprecation, and evaluation are the pillars. The tools and processes scale with you.

Why This Matters

A well-managed MCP catalog is a force multiplier. Teams ship faster because they reuse existing servers instead of building from scratch. Security improves because every server passes a quality gate. Maintenance burden decreases because ownership is clear and deprecation is planned.

Over a year, a 200-engineer org using a curated MCP catalog saves thousands of engineering hours and prevents security incidents. That’s not just efficiency—that’s compounding value.

Start small. Inventory what you have. Build the registry. Launch discovery. Establish ownership. The rest follows.

For deeper insights into how engineering teams implement MCP servers for real-world use cases, explore Building MCP Servers in the Real World, which covers debugging, legacy system integration, and team collaboration patterns. If you’re optimising for performance at scale, Dynamic Tool Gating and Lazy Schema Loading for MCP provides research-backed techniques for managing schema complexity in large catalogs.

For organisations considering a broader AI transformation alongside MCP adoption, PADISO can help. As a Sydney-based venture studio and AI digital agency, PADISO partners with ambitious teams to build and scale AI-powered systems. Whether you’re a startup building your first AI infrastructure or an enterprise modernising your platform, PADISO offers fractional CTO leadership and co-build support to ship faster and more securely.

If your organisation needs help designing and implementing an MCP catalog, establishing AI Strategy & Readiness, or ensuring SOC 2 / ISO 27001 compliance as you scale internal tools, PADISO’s AI & Agents Automation services can accelerate your journey. The team has shipped 50+ MCP integrations and helped organisations at every scale—from seed-stage startups to mid-market enterprises—build secure, discoverable, well-governed internal tool ecosystems.

Your MCP catalog is not just infrastructure. It’s a competitive advantage. Build it right.