Custom MCPs in CI Pipelines

Here is where MCP development and CI/CD converge. Your custom MCP server — the one you built in Module 1 — can run inside your CI pipeline to give Claude access to systems that the default tools cannot reach. A database MCP lets Claude verify that a migration file produces the expected schema. A feature flag MCP lets Claude check that new code paths are properly gated. An infrastructure MCP lets Claude verify that a Terraform plan matches the expected changes.

The setup is mechanical: install the MCP server in the CI runner, configure it in the workflow's MCP settings, and reference the tools in your Claude prompt. The same MCP server you use locally for development becomes a CI tool with zero modification. The protocol is the same. The tools are the same. The context is different — production credentials instead of development credentials, CI runner filesystem instead of your laptop.

Security is the non-negotiable concern when running MCP servers in CI. Your MCP server has access to whatever credentials and systems you give it. In a local development environment, the blast radius is your machine. In CI, the blast radius is your production infrastructure.

The principle is least privilege. The database MCP in CI gets read-only credentials that can query schema metadata but not read customer data. The feature flag MCP gets read-only access to flag configurations but cannot toggle flags. The infrastructure MCP can read Terraform state but not apply changes. Every MCP server in CI should be a read-only observer, never a read-write actor. If Claude needs to make changes, those changes should go through the normal PR and approval process, not through a CI-triggered MCP call.