TL;DR
- The Model Context Protocol (MCP) is an open standard that standardizes how artificial intelligence models connect to external tools, databases, and context repositories.
- MCP replaces custom point-to-point integrations with a client-host-server architecture operating over JSON-RPC 2.0.
- Servers expose three core primitives to host applications: resources for reading data, prompts for templated workflows, and tools for executing actions.
- Unmanaged MCP connections introduce context window bloat and security blind spots, making centralized gateways necessary for enterprise scale.
- Bifrost acts as both an MCP client and server, providing key-level tool filtering, audit logging, and code execution to cut token costs.
The Model Context Protocol (MCP) is an open standard that establishes a structured communication layer between artificial intelligence applications and external data systems. Introduced by Anthropic in late 2024 and maintained under the Linux Foundation's Agentic AI Foundation, MCP addresses the fragmentation that previously required custom code for every model-and-tool pairing. Instead of building bespoke API connectors for every application, engineering teams can implement MCP to let agents query databases, interact with file systems, and execute enterprise workflows dynamically. For platform teams running agents in production, Bifrost, an open-source AI gateway written in Go by Maxim AI, unifies these connections by pairing model routing with centralized MCP management.
Understanding the Model Context Protocol: Core Concepts and Origins
The Model Context Protocol is an open standard that provides a universal, transport-agnostic interface for AI agents to discover, read, and invoke external tools and context. Prior to MCP, connecting five AI agents to ten internal services required writing and maintaining fifty separate integrations. MCP reduces this integration burden to an N+M model: each data source implements the protocol once as a server, and each AI client implements the protocol once as a consumer.
Traditional Integrations (N × M):
Agent 1 ──┬── Custom API ── Database
Agent 2 ──┼── Custom API ── GitHub
Agent 3 ──┴── Custom API ── Slack
MCP Architecture (N + M):
Agent 1 ──┐ ┌── MCP Server ── Database
Agent 2 ──┼── MCP Protocol ──┼── MCP Server ── GitHub
Agent 3 ──┘ └── MCP Server ── Slack
This transition mirrors the adoption of the Language Server Protocol (LSP) in software engineering. Before LSP, every code editor had to write custom syntax highlighters and autocomplete engines for every programming language. LSP standardized how editors talk to language analysis tools, allowing an editor like VS Code or Neovim to support dozens of languages instantly. In the same way, MCP allows an agent running in Claude Desktop, Cursor, or an internal microservice to interact with local files, cloud services, and production APIs without custom integration code.
The standard was donated to the Linux Foundation to guarantee neutral governance across vendors, drawing active support from OpenAI, Google Cloud, Microsoft, and Anthropic. It has quickly become the baseline standard for agentic systems that require live access to context outside model training weights.
The Architecture of MCP: Hosts, Clients, and Servers
The Model Context Protocol operates through a decoupled, three-tier architecture: the host, the client, and the server. The host application owns the conversation state and language model interactions, while embedded clients manage dedicated connections to independent upstream servers.
Understanding how these three entities interact is essential for designing resilient AI agent systems:
- Host: The user-facing AI application or agent runtime (such as Claude Desktop, Cursor, or an enterprise customer support agent). The host application manages the LLM context window, prompt construction, and user consent prompts.
- Client: An internal module created by the host application that establishes a 1:1 stateful or request-scoped connection with a specific server. The client translates protocol requests into JSON-RPC messages and relays returned context back to the host.
- Server: A lightweight, standalone service that exposes specific capabilities to clients. A server can run locally as a child process or remotely in the cloud, exposing internal data through standardized primitives.
By isolating external tools inside dedicated server processes, MCP prevents tool failures or unhandled exceptions from crashing the primary host application. If a third-party API server times out or crashes, the MCP client receives a structured protocol error, leaving the host application free to decide whether to retry or prompt the user.
Core Primitives: Resources, Prompts, and Tools
Servers offer capabilities to clients through three foundational primitives defined in the MCP specification: resources, prompts, and tools. Each primitive serves a distinct role in how context reaches the model.
Resources (Data Access)
Resources represent read-only context provided by the server to the model. Resources behave like files or data payloads; they are identified by standardized URIs and can contain either UTF-8 text or base64-encoded binary data. Examples include database schemas, server log streams, configuration files, and API documentation.
Clients can query available resources using the resources/list method and read specific payloads using resources/read. Servers can also notify clients when a resource updates, allowing agents to maintain live situational awareness of changing data.
Prompts (Workflows and Templates)
Prompts are reusable, parameterized templates designed to guide user interactions or model reasoning. Unlike static prompt strings hardcoded into an application, MCP prompts are defined server-side and fetched dynamically by the host using prompts/list and prompts/get.
A database MCP server, for instance, might provide an optimize-query prompt that accepts an SQL statement as an argument and outputs a structured prompt instructing the model to analyze query execution plans.
Tools (Action Execution)
Tools represent callable functions that allow language models to perform actions and mutate state in external systems. Each tool is defined with a unique name, a natural language description, and a JSON Schema validating its parameters.
When an agent decides to invoke an external action, the client sends a tools/call request to the target server. The server executes the function locally or over an API, returning a structured JSON response to the agent. Tools represent arbitrary code execution, requiring careful access controls and operational safeguards in enterprise deployments.
MCP Transports and JSON-RPC Communication Lifecycle
Communication between MCP clients and servers is standardized on JSON-RPC 2.0 messages. The transport layer abstracts the underlying connection mechanics, allowing the same protocol schema to function across local processes and network endpoints.
Host (Agent) Client Module MCP Server
│ │ │
│── Request Tool Discovery ──>│ │
│ │── tools/list (JSON-RPC) ──>│
│ │<── Tool Definitions ───────│
│<── Rendered Tool Catalog ───│ │
│ │ │
│── LLM Decides to Run Tool ─>│ │
│ │── tools/call (JSON-RPC) ──>│
│ │ (Execute Action) │
│ │<── Execution Result ───────│
│<── Tool Result in Context ──│ │
The protocol supports two primary transport types:
- Standard Input/Output (stdio): Used when the server runs on the same machine as the host application. The host launches the server as a child process and communicates via standard input and standard output using newline-delimited JSON-RPC messages. This transport provides low latency and is common in desktop tools like Claude Desktop or developer CLI environments.
- Streamable HTTP and Server-Sent Events (SSE): Used when the server resides on a remote host, in a container, or behind a cloud proxy. The client sends HTTP POST requests containing JSON-RPC payloads, while the server uses SSE to stream responses, progress updates, and notifications back to the client.
A standard tools/call JSON-RPC exchange demonstrates the simplicity of this wire format:
// Client Request
{
"jsonrpc": "2.0",
"id": 104,
"method": "tools/call",
"params": {
"name": "query_inventory",
"arguments": {
"sku": "WIDGET-99",
"warehouse_id": "us-east-1"
}
}
}
// Server Response
{
"jsonrpc": "2.0",
"id": 104,
"result": {
"content": [
{
"type": "text",
"text": "{\"available\": 42, \"reserved\": 8, \"backordered\": 0}"
}
],
"isError": false
}
}
The JSON-RPC 2.0 specification ensures that every call has an explicit request identifier, deterministic error objects, and structured payloads. This predictable message framing makes it straightforward to parse and route tool invocations across distributed microservices.
Tool Execution Mechanics and Context Window Overhead
While MCP simplifies connecting tools to models, real-world implementations encounter significant context window overhead as catalogs grow. In standard MCP implementations, host applications load every connected tool definition into the model prompt during initialization.
When an agent connects to multiple enterprise servers (such as GitHub, Jira, AWS, and a local database), dozens of tool schemas are injected into the system prompt. A comprehensive tool schema with extensive parameter definitions can consume between 400 and 1,200 tokens. Loading 50 tool schemas consumes up to 60,000 tokens before the conversation even begins, inflating inference costs and increasing time-to-first-token latency.
Furthermore, multi-step agent workflows create token bloat when intermediate data passes through the model. If an agent calls a database tool that returns a 5,000-line JSON payload, the entire payload enters the context window. If the agent then extracts three values from that payload and passes them to a second tool, the context window retains the unused data for all subsequent turns.
| Execution Approach | Tool Discovery Method | Token Consumption | Intermediate Data Handling |
|---|---|---|---|
| Classic MCP (Direct Calling) | All JSON Schemas loaded into prompt upfront | High; scales linearly with total tool count | Raw payloads accumulate in context window |
| Filtered MCP (Gateway-Enforced) | Only tools authorized for the active key are exposed | Moderate; limited to approved subset | Payloads enter prompt upon execution |
| Code Execution Mode (Sandboxed) | Tools exposed as Python libraries via stub generation | Low; up to 92.8% reduction in token usage | Intermediate data filtered inside execution sandbox |
To solve this overhead, advanced runtimes utilize code execution mode. Instead of relying on the model to emit tool-call syntax for each turn, the model writes short Python scripts that run inside an isolated sandbox. The sandbox interacts directly with the MCP servers, filtering and combining data locally before returning only the necessary summary to the language model. Bifrost includes native support for Code Mode tool execution, reducing token consumption by up to 92.8% and cutting tool orchestration latency by 40%.
Production Challenges: Governance, Security, and Enterprise Scale
Deploying MCP tools across an organization introduces operational risks that the base protocol specification does not address. The core MCP specification governs message formats and communication handshakes, but it deliberately leaves authorization, rate limiting, credential isolation, and audit logging to the implementing infrastructure.
Enterprise Gateway Security Perimeter
┌────────────────────────────────────────────────────────┐
│ Incoming Request ──> Virtual Key Check │
│ ├── Tool Allowlist Enforced │
│ ├── Guardrail & PII Inspection │
│ └── Budget & Rate Limit Verified │
│ │
│ Routing to Target Server │
│ ├── Authenticated Upstream Call │
│ └── Immutable Audit Log Recorded │
└────────────────────────────────────────────────────────┘
Without an intermediate management layer, teams encounter several common operational failure modes:
- Credential Sprawl: Local developer configuration files often store static API tokens, database passwords, and private service keys in plain text to allow local MCP tools to function.
- Unrestricted Tool Access: If an agent connects directly to an MCP server hosting destructive operations (such as dropping database tables or sending external emails), the model can trigger those operations without human-in-the-loop review or permission checks.
- Shadow AI on Endpoints: Employees frequently install ungoverned AI desktop tools and wire local MCP servers directly to company laptops, bypassing enterprise perimeter firewalls and compliance logging.
- Missing Audit Trails: Compliance frameworks like SOC 2, HIPAA, and GDPR require immutable records of data access. Direct agent-to-server connections leave no centralized audit trail of which user ran which tool.
Addressing these challenges requires a layered security model. Beyond routing, Bifrost applies governance and security controls (virtual keys, budgets, guardrails, audit logs) centrally, and Bifrost Edge extends that same governance and security to AI traffic on employee machines, with endpoint enforcement on each device. By governing MCP tools both at the cloud perimeter and on developer workstations, organizations eliminate blind spots without restricting legitimate development workflows.
| Challenge | Operational Risk | Production Requirement | Gateway Solution |
|---|---|---|---|
| Credential Management | Plaintext API keys on laptops | Centralized secret storage | OAuth 2.0 PKCE and federated authentication |
| Tool Scoping | Agents executing unintended actions | Least-privilege access per key | Virtual keys with granular tool allowlists |
| Data Exfiltration | Sensitive context leaked to models | PII and secrets redaction | Real-time guardrail inspection |
| Local Fleet Discovery | Unregulated desktop agent tools | Visibility into endpoint MCP configs | Centralized endpoint discovery and MDM rollout |
Centralizing MCP with an AI Gateway
To bridge the gap between individual agent scripts and enterprise requirements, engineering teams deploy an MCP gateway. An MCP gateway is a high-performance control plane that sits between downstream AI clients and upstream tool servers, managing connection lifecycles, authentication, access policies, and observability in one place.
Bifrost functions as a dual-role proxy: it acts as an MCP client to upstream tool servers while simultaneously acting as an MCP server to downstream AI clients. By sitting in the middle of tool traffic, Bifrost enforces operational policies transparently:
- Unified Endpoint Aggregation: Instead of configuring agents to maintain dozens of network connections, clients connect to Bifrost via a single endpoint using Streamable HTTP. Bifrost automatically handles discovery, health monitoring, and connection pooling across all upstream servers.
- Access Control via Virtual Keys: Using virtual keys, administrators assign specific tool permissions to different teams, projects, or users. A junior developer's virtual key can be restricted to read-only database tools, while production pipelines receive access to write operations.
- Enterprise Guardrails and Redaction: In-flight tool calls pass through guardrails that detect secrets, API keys, and PII before parameters reach the executing server or prompt context.
- Comprehensive Observability: Every tool discovery and execution request is recorded in immutable audit logs, capturing the caller's virtual key, input parameters, response payloads, and latency. Bifrost exports metrics natively to Prometheus and traces via OpenTelemetry for end-to-end distributed tracking.
- Endpoint Protection with Bifrost Edge: To protect developer machines from shadow AI, Bifrost Edge runs as an endpoint agent deployed via MDM platforms like Jamf and Microsoft Intune. Bifrost Edge discovers local MCP servers configured across apps like Claude Desktop, Cursor, and CLI agents, enforcing MCP governance and app governance policies directly on the machine.
Operating MCP through a dedicated gateway ensures that AI applications remain decoupled from the infrastructure they interact with, preserving security boundaries while enabling rapid tool iteration.
Frequently Asked Questions
What is the Model Context Protocol (MCP)?
The Model Context Protocol (MCP) is an open-source standard created to unify how artificial intelligence applications connect to external tools, databases, and context repositories. It provides a standardized JSON-RPC 2.0 communication format that eliminates the need for custom point-to-point connectors between different AI models and tools.
How does MCP differ from traditional function calling APIs?
Traditional function calling formats (such as OpenAI tool calling) define how a specific model provider accepts function schemas within an inference request. MCP defines the entire client-server protocol for discovering, authenticating, and executing those tools across different providers, runtimes, and host applications.
What transports does the Model Context Protocol support?
MCP supports standard input/output (stdio) for local process communication, alongside Streamable HTTP and Server-Sent Events (SSE) for networked or cloud-hosted servers. The protocol remains transport-agnostic, meaning the underlying JSON-RPC message schema remains identical regardless of the transport mechanism used.
What is an MCP gateway and why is it needed?
An MCP gateway is a centralized control plane that sits between AI applications and MCP servers. It aggregates multiple tool servers behind a single URL, enforces role-based access controls, authenticates requests, logs audit trails, and applies guardrails to prevent data leaks or unauthorized actions.
How does MCP manage token usage and context window limits?
By default, MCP loads all connected tool schemas into the model's prompt, which can exhaust token limits when many tools are connected. Advanced gateways mitigate this using dynamic tool filtering per virtual key or Code Execution Mode, where models orchestrate tools inside a sandboxed Python environment to reduce prompt overhead.
Can MCP run securely in enterprise environments?
Yes, but enterprise deployments require infrastructure safeguards like virtual keys, tool allowlists, and network segmentation. Gateways like Bifrost add OAuth 2.0 authentication, audit logging, and guardrails to meet SOC 2, HIPAA, and GDPR compliance standards.
Getting Started with MCP Infrastructure
Implementing the Model Context Protocol allows software teams to build modular, maintainable agent workflows that interact safely with the enterprise software stack. As organizations transition from prototyping local desktop agents to running multi-agent systems in production, separating tool execution from policy enforcement becomes essential. Deploying a dedicated MCP gateway ensures that every tool call remains observable, auditable, and cost-efficient.
Teams evaluating enterprise agent infrastructure can request a Bifrost demo, explore the open-source repository, or review architecture guides in the Bifrost resource library.
Top comments (0)