What Is Model Context Protocol (MCP)? A 2026 Guide

Model Context Protocol (MCP) is an open standard that defines how AI applications connect to external tools, data sources, and workflows through one consistent interface. When Anthropic donated MCP to the Linux Foundation's Agentic AI Foundation in December 2025, it reported more than 10,000 active public MCP servers and over 97 million monthly SDK downloads across the ecosystem. Bifrost, the open-source MCP gateway built in Go by Maxim AI, is the best choice for enterprise teams that need to route, govern, and secure Model Context Protocol traffic at scale. This guide covers what MCP is, how the architecture works, what changed in the 2026-07-28 specification, and what teams need in place before running MCP in production.

What Is Model Context Protocol (MCP)?

Model Context Protocol is an open standard that lets an AI application discover and invoke external tools, read external data, and load reusable prompts from independent servers, using a single JSON-RPC message format instead of a custom integration per system.

Before MCP, every connection between a model and a system (a database, a ticketing tool, a code host) was a bespoke integration written against that system's API and re-written for each AI application that needed it. MCP replaces that pattern with one protocol implemented once on each side. An MCP server built for an internal data warehouse works with any MCP-compatible client, whether that client is a coding agent, a desktop chat app, or a production agent running in a service.

The practical consequence for engineering teams is that tool access becomes a runtime concern rather than a build-time one. Tools are discovered dynamically, which is what makes MCP useful for agents, and also what makes an MCP gateway necessary once more than a handful of servers are in play.

Why Did MCP Become the Standard for Connecting AI to Tools?

MCP won adoption because it removed the N-by-M integration problem: N AI applications connecting to M systems previously required N times M connectors, and MCP reduces that to N plus M implementations. Anthropic introduced the protocol in November 2024 with early adopters including Block and Apollo.

Three factors accelerated it:

• Neutral governance: MCP is maintained under the Agentic AI Foundation rather than by a single vendor, which removes the procurement risk of building on one company's proprietary interface.
• Cross-vendor client support: MCP is supported across Claude, ChatGPT, Cursor, Gemini, Microsoft Copilot, and Visual Studio Code, so a server written once is addressable from most AI surfaces developers already use.
• Agent-driven demand: coding agents and autonomous workflows need tools at runtime, and MCP is the most widely implemented standard that supports dynamic tool discovery and invocation.

The result is that MCP now sits on the critical path of enterprise AI. Teams that treated it as a developer convenience in 2025 are now running MCP as production infrastructure, with the access control, audit, and cost requirements that come with it.

How Does MCP Work? Hosts, Clients, Servers, and Transports

MCP uses a client-server architecture with three participants. An MCP host is the AI application that coordinates everything. An MCP client is a component inside the host that holds one dedicated connection to one server. An MCP server is a program that exposes tools, data, and prompts to clients.

A host creates one client per server, so an editor connected to a filesystem server, an issue tracker, and an internal API is running three clients at once. The protocol itself is split into two layers:

• Data layer: a JSON-RPC 2.0 exchange protocol that defines discovery, capability negotiation, and the core primitives.
• Transport layer: the channel the messages travel over, either stdio for local process communication or Streamable HTTP for remote servers, with OAuth recommended for obtaining authentication tokens.

That local versus remote split matters operationally. Local stdio servers run on a developer's machine and typically serve one client. Remote HTTP servers serve many clients, which is where authentication, rate limiting, and audit become real problems, and where teams start connecting multiple MCP servers through one gateway rather than wiring each client individually.

What Are MCP Tools, Resources, and Prompts?

MCP servers expose three primitives, each with its own discovery and retrieval methods:

• Tools: executable functions the model can invoke, such as running a query, creating a ticket, or writing a file.
• Resources: data the server provides as context, such as file contents, schemas, or API responses.
• Prompts: reusable templates that structure an interaction, such as a system prompt or a set of few-shot examples.

Clients discover each primitive type with a */list call and execute tools with tools/call. Because listings are dynamic, the set of tools available to a model can change between requests, which is precisely why tool-level policy belongs at a control point rather than in each application's config file.

What Changed in the 2026-07-28 MCP Specification?

The 2026-07-28 revision is the largest change to the protocol since launch, and it moves the protocol toward stateless, load-balancer-friendly operation. Every request now carries its protocol version and relevant capabilities in a _meta field, so a server can process each request independently.

The changes that affect production deployments most:

• Mandatory discovery: servers must implement a server/discover request that advertises supported versions and capabilities, and the response is typically cacheable.
• Stateless request handling: servers infer nothing from prior requests, which makes horizontal scaling behind a load balancer far simpler.
• Opt-in notifications: clients open a long-lived subscriptions/listen stream naming the notification types they want, rather than receiving change notifications by default.
• Deprecations: sampling and logging as client primitives are deprecated as of this version, with elicitation remaining the supported way for a server to request user input.

Older protocol revisions remain in circulation, so anything sitting between clients and servers needs to speak more than one version during the migration window. This is one of the strongest arguments for centralizing agent tool access behind a gateway: version handling becomes one team's problem instead of every application team's problem.

MCP vs API vs RAG: What Is the Difference?

MCP, traditional APIs, and retrieval-augmented generation solve different problems and are frequently confused because all three give a model access to information it was not trained on.

The short version: an API is what an MCP server usually wraps, RAG supplies knowledge, and MCP supplies capability. Teams comparing implementation patterns can review how an MCP gateway, an MCP proxy, and an MCP server differ before deciding what to build.

What Goes Wrong When MCP Runs at Enterprise Scale?

MCP works well for one developer connecting three servers. It runs into four problems once an organization connects dozens of servers across many users.

• Credential sprawl: each client stores its own tokens for each server, so revoking access means touching every machine and every config file. Centralized MCP authentication removes that per-client credential surface.
• No tool-level access control: the protocol defines how tools are exposed, not who is allowed to call them. A contractor and a staff engineer see the same tool list unless something enforces a policy between them.
• Token cost growth: every tool definition from every connected server is sent in context on every request. At 500 tools across 16 servers, tool catalogs dominate the input budget before the model does any work.

The fourth problem, security, scales worst of all. Unvetted servers, over-broad permissions, and prompt injection through tool output are all live risks, covered in more detail in this breakdown of MCP security risks and how to mitigate them.

How an MCP Gateway Puts Model Context Protocol Under Control

An MCP gateway is a single control point that sits between AI applications and MCP servers, aggregating tools, enforcing access policy, handling authentication, and recording every tool call. Bifrost is both an MCP client and an MCP server, so it connects outward to external servers over STDIO, HTTP, or SSE, and exposes the aggregated tool registry as a single MCP endpoint to clients like Claude Desktop and Cursor.

The governance layer covers the gaps the protocol leaves open:

• Authentication per server: each connected server gets its own auth method, with support for headers, OAuth, per-user OAuth, per-user headers, and token exchange, so credentials live at the gateway instead of on every laptop.
• Tool-level permissions: MCP tool groups attach curated tool collections to virtual keys, teams, customers, and users, enforced at request time.
• Explicit execution by default: tool calls returned by a model are treated as suggestions, and execution requires a separate call unless Agent Mode is configured with specific auto-approved tools.
• Budgets and rate limits: virtual keys carry per-consumer budgets and limits, so MCP spend is attributable per team or customer rather than pooled.
• Audit trails: audit logs record tool access for SOC 2, GDPR, HIPAA, and ISO 27001 evidence.

The token problem gets solved structurally. Code Mode exposes four generic tools instead of the full catalog and has the model write Python that orchestrates the rest inside a sandbox. In benchmarks across 508 tools and 16 servers, this reduced input tokens by 92.8% and estimated cost by 92.2% while keeping the pass rate at 100%, with roughly 40% faster execution in large deployments. The full methodology is in the MCP gateway benchmark writeup, and the trade-offs are compared directly in classic MCP versus Code Mode.

Because the same gateway also routes model traffic with 11 microseconds of overhead at 5,000 requests per second, model calls and tool calls end up under one policy engine rather than two. Regulated teams can run the whole path inside their own boundary using in-VPC and air-gapped deployment.

Model Context Protocol FAQ

Who created MCP and who maintains it now?

Anthropic created MCP and released it in November 2024. In December 2025 it was donated to the Agentic AI Foundation under the Linux Foundation, and it is now maintained by a multi-vendor group rather than a single company.

Is MCP the same as an API?

No. An API exposes endpoints that a developer codes against ahead of time. MCP is a protocol that lets an AI application discover available tools at runtime and invoke them through a standard message format. Most MCP servers are wrappers around existing APIs.

Do I need an MCP gateway to use MCP?

Not for a single developer with a few local servers. A gateway becomes necessary once multiple people or applications share servers, because that is the point at which credentials, tool permissions, audit, and token cost need central enforcement. The reasoning is expanded in this piece on why MCP needs a governance layer.

Is MCP secure by default?

The protocol defines transport security and recommends OAuth for remote servers, but it does not define who may call which tool inside an organization. That policy has to be enforced by the infrastructure around it, which is the role an MCP gateway plays as a control plane.

What is the difference between an MCP server and an MCP gateway?

An MCP server exposes one set of tools or data. An MCP gateway sits in front of many servers, aggregates their tools into one endpoint, and applies authentication, filtering, and logging across all of them.

Getting Started with Model Context Protocol on Bifrost

MCP is now the default way AI applications reach tools and data, and the operational question for most teams is no longer whether to adopt it but how to run it with access control, cost visibility, and an audit trail. The open-source Bifrost AI gateway connects to external MCP servers, aggregates their tools behind one governed endpoint, and applies the same virtual keys, budgets, and audit logs to tool calls that it applies to model calls. Teams evaluating the category can start with the complete guide to MCP gateways for enterprise AI teams or work through the MCP integration docs.

To see how the Bifrost gateway governs Model Context Protocol traffic across your models, agents, and tool servers, book a demo with the Bifrost team.