What is an MCP server?

An MCP server is a process that exposes tools, resources, and prompts to an AI host over the Model Context Protocol. In production, the server is only one layer; teams also need gateway policy, identity, logging, and isolation.

Which MCP gateway should an enterprise choose in 2026?

Choose based on your existing control plane. Microsoft-heavy tenants should start with Fabric and Entra ID, Postman shops should evaluate Postman MCP, edge-policy teams should look at Cloudflare, and mixed third-party server environments should start with Docker or IBM ContextForge.

What are the biggest MCP security risks?

The highest-risk issues are prompt injection through tool results, over-broad OAuth scopes, and supply-chain exposure from third-party servers. Pin versions, sandbox execution, scope tokens per resource, and log every tool call.

How should MCP be used in CI/CD?

Run MCP servers as pinned sidecars, test them through tools/list and representative tools/call requests, scan dependencies for CVEs, and fail builds when schemas or authorization behavior drift.

The MCP Server Boom Moved the Moat to Gateways

The short answer: an MCP server is now production infrastructure for exposing tools to agents, but the real engineering work has moved to gateways, authorization, and sandboxing.

That shift happened fast. Anthropic announced the Model Context Protocol in November 2024, and by mid-2026 the public server ecosystem had moved from novelty demos to tens of thousands of listed servers across registries, with the Docker MCP Catalog acting as the most visible distribution point.

An MCP server exposes tools, resources, and prompts to an AI host over JSON-RPC. The host might be Claude Code, Cursor, VS Code Copilot Agent Mode, JetBrains, or an internal agent runtime; the gateway is the policy layer that puts many servers behind one governed endpoint.

TL;DR: MCP is useful when you have multiple hosts, multiple tools, or tool churn. Treat every MCP server as executable supply-chain code with credentials attached. Pick the gateway according to your identity and isolation model, then make CI/CD prove the server contract before deploy.

Key takeaways

The current stable MCP spec is dated 2025-11-25; the next dated release candidate is 2026-07-28, with stateless Streamable HTTP as the headline change.
The Model Context Protocol specification defines a client-server contract, while gateways decide auth, tenancy, observability, and runtime isolation.
The Docker MCP Catalog docs show why containerized discovery became the default developer path for mixed third-party servers.
Serious MCP security authorization now means OAuth 2.1, PKCE, Resource Indicators, audience binding, and narrow scopes per server.
Use MCP in CI/CD like any other integration boundary: pin versions, run sidecars, test tools/list and tools/call, and scan before deploy.

Why the MCP server layer matters now

The protocol itself is intentionally small. Hosts initialize sessions, ask servers for tool definitions, pass schemas to the model, and mediate calls when the model chooses a tool.

That simplicity is why MCP spread. A team can expose GitHub issues, database queries, logs, docs, browser automation, and internal APIs through the same integration shape instead of rebuilding per-agent adapters.

But the simplicity also hides the production problem. An MCP server often holds credentials, touches sensitive systems, and returns untrusted text directly into model context.

That makes MCP less like a plugin format and more like a new tool-control plane. For more on the agent side of that boundary, see GenAlphAI’s guide to AI agent architecture and its explainer on enterprise AI governance.

What is current in the MCP server ecosystem 2026?

As of June 21, 2026, the latest stable MCP spec is 2025-11-25, the project’s first-anniversary release. The MCP project has also announced a 2026-07-28 release candidate, with stateless Streamable HTTP intended to remove sticky-routing requirements for horizontally scaled remote servers.

The transport story is mostly settled. Local development still uses stdio, while remote deployments should use Streamable HTTP; the older HTTP+SSE transport was deprecated in the 2025-03-26 spec line, according to the MCP transports documentation.

The official SDK footprint is also broad. The MCP SDK page lists TypeScript, Python, C#, and Go as Tier 1 production-supported SDKs, with Java, Rust, and Swift in Tier 2.

The registry count is noisier. Glama displayed 40,451 servers on June 21, 2026, while a May 31, 2026 Appnova snapshot put Glama near 29,261, mcp.so near 21,638, PulseMCP near 16,000, and Smithery above 10,000.

Those directories overlap, so the defensible claim is simpler: public MCP servers are now in the tens of thousands, while Docker is the cleanest packaging path for many teams.

Public MCP registry snapshots, May-June 2026

The gateway is the product surface now

A gateway terminates MCP for one or more backend servers, then adds identity, routing, logs, rate limits, tenant boundaries, and policy. That is where enterprise architecture now lives.

Here is the practical MCP gateway comparison for June 2026.

Gateway	Best fit	Auth model	Isolation story	Maturity as of June 2026
Docker MCP Gateway	Mixed third-party servers, local dev, self-hosted isolation	OAuth 2.1 plus Dynamic Client Registration patterns	One server per container and network boundary	Stable in Docker Desktop tooling
Postman MCP	Teams whose APIs already live in Postman collections	Postman OAuth, enterprise SSO options	Postman team and workspace controls	GA hosted server plus OSS server
Microsoft Fabric MCP	Fabric, OneLake, Entra ID tenants	Entra ID and Fabric workspace RBAC	Fabric workspace and OneLake controls	Core MCP in Preview; OneLake reported GA
IBM ContextForge	Open-source multi-tenancy, IBM Z, POWER	OAuth 2.1, DCR, LDAP/AD options	Per-tenant virtual servers	v1.0.0 GA on May 5, 2026
Cloudflare MCP Portals	Edge access and identity-aware per-call policy	OAuth 2.1 plus Cloudflare Access	Access policy and portal boundaries	Remote MCP since March 25, 2025
Smithery	Managed hosting and community discovery	OAuth 2.1 plus DCR	Per-connection scoping	Triggers in preview

Docker’s advantage is packaging and isolation. The Docker MCP Gateway docs describe a reverse proxy between AI clients and many containerized MCP servers, while the docker/mcp-gateway repository gives teams an open-source path.

Postman’s advantage is API governance. The Postman MCP docs and open-source server make the strongest case when OpenAPI collections are already the system of record.

Microsoft’s advantage is identity and data-plane locality. The Fabric MCP overview ties MCP to Fabric workspace RBAC and Entra ID, while Microsoft’s official MCP catalog aggregates the company’s published servers.

IBM’s advantage is open-source multi-tenancy and unusual architecture support. IBM ContextForge shipped v1.0.0 GA in May 2026, and the PyPI package shows mcp-contextforge-gateway 1.0.3 dated June 10, 2026.

Cloudflare’s advantage is policy at the edge. The company’s remote MCP server guide, authorization docs, and MCP Server Portals docs make it the cleanest fit when Access policy already protects internal apps.

MCP security authorization is the hard part

The dangerous part of MCP is that tool results are model input. A server can return attacker-controlled text, and the model may treat that text as instruction.

OWASP’s LLM01:2025 Prompt Injection remains the baseline reference here. Docker’s GitHub prompt injection scenario shows the concrete version: a tool fetches seemingly normal issue or comment text, then the returned payload tries to override the user’s intent.

Authorization is the second failure mode. The MCP authorization tutorial describes the right pattern: OAuth 2.1, PKCE, Resource Indicators, and tokens scoped to a specific protected resource.

Dynamic Client Registration matters because it avoids shipping static client secrets to every host. Descope’s MCP client registration methods and Stytch’s DCR explainer explain the same direction from the identity-provider side.

Still, “zero-touch OAuth” only solves credential issuance. It doesn’t prove a server is safe, prevent broad scopes, or stop prompt injection through tool output.

A minimum viable MCP policy

Use this as a starting checklist before any production MCP server reaches an agent host:

Require OAuth 2.1 with PKCE for remote servers.
Bind access tokens to the MCP server URL with Resource Indicators.
Deny broad scopes by default, especially write scopes.
Tag tool results as data and strip instruction-like content where possible.
Pin server images or packages by digest or exact version.
Run third-party servers in containers, gVisor, Firecracker, or another sandbox.
Log every tools/list and tools/call, including user, tool, server, scopes, and result size.
Keep Inspector and local dev tools out of shared networks.

The last point is not theoretical. The MCP Inspector RCE, reported as CVE-2025-49596 with CVSS 9.4 by The Hacker News, made default npx usage a real operational concern for development environments.

When should you use MCP in CI/CD?

Use MCP in CI/CD when the server contract is part of your production agent path. A server that changes its schema or auth behavior can break an agent as surely as a REST API change can break a backend.

The pattern is straightforward. Start the MCP server as a sidecar, point a test host at it, call initialize, verify tools/list, then execute representative tools/call requests with known inputs and expected outputs.

For GitHub Actions, that usually means a Docker MCP Gateway service container plus pinned backend server images. There is no first-party actions/mcp-server standard as of June 2026, so most teams wrap docker/mcp-gateway or their chosen gateway directly.

A minimal contract test should fail on these changes:

A tool disappears or is renamed.
A JSON schema changes without a version bump.
A tool gains a new write permission.
OAuth scopes broaden.
A result starts returning unstructured text where structured output was expected.
The server image has a known critical CVE.

This is also where evaluation discipline matters. If your agent depends on tool behavior, fold MCP contract tests into the same evaluation harness you use for model behavior; GenAlphAI’s AI evaluation guide covers the broader testing pattern.

The contrarian call: direct APIs still win small systems

The shareable takeaway: MCP pays off when tool count and host count grow; direct APIs still win for one host, one tool, and tight latency budgets.

A direct function call is easier to audit and faster to execute. If your system calls one internal API from one agent runtime, adding MCP adds a process boundary, a schema boundary, and an auth hop.

MCP becomes compelling when the matrix expands. Two hosts times ten tools times three environments creates enough integration surface that a protocol boundary starts saving real engineering time.

Anthropic’s code execution with MCP points toward the more durable architecture: expose capabilities cleanly, then let agent runtimes execute against a governed capability filesystem instead of hand-wiring every call path.

Decision framework: which gateway should you pick?

Start with identity, because auth integration beats most feature comparisons.

If your enterprise runs on Microsoft Entra ID and Fabric, evaluate Microsoft Fabric MCP first. If Postman is your API source of truth, Postman MCP will feel more natural than a fresh gateway layer.

If you need mixed third-party tools on developer machines or self-hosted clusters, start with Docker MCP Gateway and the Docker MCP Catalog. The container boundary is a concrete security advantage.

If you need open-source multi-tenancy, per-tenant tool catalogs, or IBM Z and POWER support, IBM ContextForge is the serious candidate. If you need identity-aware access in front of self-hosted internal apps, Cloudflare MCP Server Portals should be on the shortlist.

If you mainly want managed hosting and registry discovery, Smithery is the fast path, with Triggers previewing event-driven MCP flows.

What this means for you

For a senior engineering team, Model Context Protocol best practices should start with ownership boundaries rather than SDK choice.

Assign an owner for each MCP server as if it were a production microservice. Require a threat model for every server that touches customer data, source code, financial systems, tickets, logs, or deployment tools.

Pick one gateway pattern for each environment. Local development can use Docker or hosted vendor endpoints; CI should use pinned sidecars; production should use the identity stack your security team already audits.

Then enforce three invariants: narrow tokens, isolated execution, and observable calls. That is the difference between a useful tool layer and an ungoverned agent with credentials.

The MCP server ecosystem 2026 is large enough that the protocol is no longer the story. The durable advantage now comes from choosing the right gateway, proving server behavior in CI/CD, and treating every tool call as a governed production event.