MCP servers are the orchestration layer, not the demo.

The bridge problem

A team we worked with spent three weeks building a deployment bot. It pulled from GitHub, ran checks against their staging environment, posted results to Slack, and updated Jira. Nineteen API integrations. Four hundred lines of glue code. A credentials file the security team would not sign off on.

Then staging changed its auth flow, and the whole thing broke in a way that took two engineers a day to untangle.

That story repeats itself everywhere AI tooling meets enterprise reality. The model is capable. The systems are capable. What is missing is a defensible way to connect them. Most teams either build brittle glue code or paste output back and forth between the two.

What MCP actually is

The Model Context Protocol is a small specification — a way to expose a set of tools (named functions with typed inputs) to an AI client over standard input/output. Three properties matter for enterprise use:

• Local processes. An MCP server runs on the developer's machine or inside the company's network. It is not an internet-facing service.
• Stdio transport. The AI client talks to the server through standard streams, the same way the shell talks to any CLI. No HTTP endpoint. No port to open. No firewall rule.
• Declarative tool surface. The server tells the client what tools exist, what inputs they expect, and what they return. The client decides when to call them.

Credentials never leave the local environment. The attack surface is the same as the attack surface of the CLI tools the developer already runs. Security teams can reason about it without a new threat model.

What it replaces

Look at any enterprise AI stack today and you will find one of three patterns connecting the model to the rest of the company:

1. Paste in, paste out. The human is the integration layer. Slow, error-prone, but auditable.
2. A bespoke gateway. Some team built an HTTP shim that proxies model calls to internal APIs. Custom auth, custom rate limits, custom maintenance. Eventually unowned.
3. Vendor-locked plugin. The AI vendor's own connector. Works only with their model, only against the integrations they prioritize.

MCP replaces all three with one project-scoped configuration file, .mcp.json, that lives in the repo and declares which local servers the AI session should start. Same config, different developers, same integrations.

{
  "mcpServers": {
    "deploy":   { "command": "python", "args": ["./tools/deploy.py"] },
    "database": { "command": "npx", "args": ["-y", "@org/mcp-postgres"] }
  }
}

The economics

The MCP ecosystem has crossed the threshold where building your own server is cheaper than buying a connector. Over ten thousand active public MCP servers and seventy-five official connectors exist as of early 2026, with adoption across the major AI clients (Claude, ChatGPT, Cursor, Gemini, Microsoft Copilot, VS Code). The protocol is governed by a foundation, not a single vendor.

That changes the make-vs-buy math. A custom MCP server for your internal billing API is a one-afternoon project, written once, used by every developer with an AI client, replaceable in place when you switch models. A vendor connector is a recurring line item, locked to a single client, and unmaintained the day the vendor pivots.

What we recommend

For most engineering teams the right starting point is small and concrete:

• One MCP server per system of record the team actually queries during development — your DB, your deploy pipeline, your ticket tracker. Not all of them. The ones a developer reaches for daily.
• A .mcp.json in the repository. Treat it like .editorconfig — version controlled, reviewed in PRs, applies to every contributor.
• No production secrets in the server's env. The MCP server should read the same credentials a developer would use locally. Production access goes through the production deployment, not the AI session.

MCP is not the headline feature. It is the plumbing that makes the headline feature actually safe to plug in. Most AI projects fail at the plumbing, not the model.