Your MCP Config Is Production Infrastructure (Stop Treating It Like a Toy)

I watched someone's agent break spectacularly last week. The culprit? A hardcoded API key in their MCP config that got rotated, cascading through three different connectors and taking down their entire automation pipeline.

Here's the thing: your MCP configuration isn't a playground anymore. It's production infrastructure running your business. But most people are managing it like it's still a demo.

The MCP sprawl problem is real

You start with one connector. Then you add GitHub integration. Then Slack. Then your CRM. Before you know it, you have 12 MCP servers with credentials scattered everywhere, no versioning, and zero rollback plan when something breaks at 2 AM.

I've seen configs with:

• Production database credentials in plaintext
• Stale permissions pointing to deleted services
• Workflow drift where the config diverges from documentation
• No audit trail of who changed what when

This isn't sustainable. Here's how to fix it.

Version your MCP configs like code

Your mcp_servers.json should live in version control. Period. But not with secrets baked in:

{
  "github": {
    "command": "npx",
    "args": ["-y", "@modelcontextprotocol/server-github"],
    "env": {
      "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
    }
  }
}

Use environment variables for secrets. Always. Set up a .env.template file so new team members know what they need.

Build CI checks for your config

Add a simple validation step to your deployment pipeline:

# validate-mcp.sh
#!/bin/bash

# Check for hardcoded secrets
if grep -r "sk-" mcp_servers.json; then
  echo "ERROR: Hardcoded API key detected"
  exit 1
fi

# Validate JSON structure
jq empty mcp_servers.json || exit 1

# Check required env vars are documented
for var in $(jq -r '.. | .env? // {} | keys[]' mcp_servers.json); do
  if ! grep -q "$var" .env.template; then
    echo "ERROR: $var not documented in .env.template"
    exit 1
  fi
done

Use a secret broker pattern

Instead of scattering credentials across configs, centralize them. I use a simple pattern where all MCP servers pull from one secure store:

{
  "secret-broker": {
    "command": "./scripts/secret-broker.py",
    "args": ["--vault-path", "/secure/secrets"]
  }
}

Your secret broker becomes the single point of credential management. Rotate a key? Update it once, restart the broker, everything reconnects.

Warning: Never commit configs with real credentials, even to private repos. Use git-secrets or similar tools to catch this automatically.

Document your rollback plan

When your MCP config breaks production, you need a 30-second recovery path:

1. Keep the last known-good config as mcp_servers.backup.json
2. Script the rollback: cp mcp_servers.backup.json mcp_servers.json && restart-agent
3. Test your rollback monthly (seriously)

Audit your connector permissions

That GitHub connector you added six months ago? It probably has access to repos that don't exist anymore. Your Slack integration? Still connected to channels from the old team structure.

Run quarterly audits. Remove stale permissions. Your future self will thank you when you're not debugging phantom errors from deleted resources.

The bottom line: MCP configurations are infrastructure now. Treat them with the same discipline you'd use for any production system. Version control, CI checks, secret management, and rollback plans aren't overkill — they're table stakes.