AI models are increasingly expected to do more than generate text. They query databases, read files, call APIs, search the web, and execute code. Each of these capabilities requires the model to interact with an external system -- and until recently, every integration was custom.

An AI coding assistant that needs to read your project files requires one integration. If it also needs to search Jira tickets, that's a second integration with completely different authentication, error handling, and response formatting. Adding GitHub, Slack, or a database means building and maintaining yet more custom code.

The Model Context Protocol (MCP) standardizes this. MCP defines a universal interface between AI applications and the external tools and data sources they need. Instead of building custom integrations for each service, developers implement the MCP server specification once, and any MCP-compatible AI client can discover and use those tools.

MCP Architecture

MCP follows a client-server architecture with three core concepts: servers, clients, and transports.

MCP Servers

An MCP server is a process that exposes capabilities to AI models through a standardized interface. A server can expose three types of capabilities:

Tools are functions that an AI model can invoke. A database query tool accepts a SQL string and returns results. A file system tool reads or writes files. A Slack tool sends messages to channels. Each tool has a defined name, description, and parameter schema that the AI model uses to understand what the tool does and how to call it.

Resources are data that a model can read. A project's file tree, a database schema, or a configuration file can be exposed as MCP resources. Unlike tools, resources are read-only -- the model accesses them for context but doesn't invoke them to perform actions.

Prompts are reusable templates that structure how a model interacts with the server. A code review prompt might define how the model should analyze a pull request; a data analysis prompt might structure how the model should query and interpret results.

MCP Clients

AI applications act as MCP clients. The client discovers available servers, reads their capability manifests (what tools, resources, and prompts they expose), and orchestrates interactions between the AI model and servers.

When the model decides to use a tool, the client handles:

1. Discovery: Querying available servers to find a tool that matches the model's intent
2. Parameter construction: Formatting the model's requested parameters according to the tool's schema
3. Invocation: Sending the request to the correct server over the configured transport
4. Response handling: Parsing the result and feeding it back to the model for further reasoning

Transport Layer

MCP supports two transport mechanisms that determine how clients and servers communicate:

stdio (Standard I/O) is for local execution. The MCP server runs as a subprocess of the client application, and they communicate over stdin/stdout. This is the simplest setup -- no networking, no authentication, minimal latency. Most development tools and IDE integrations use stdio transport.

SSE (Server-Sent Events) over HTTP is for remote execution. The MCP server runs on separate infrastructure and the client connects over HTTP. SSE enables distributed architectures where MCP servers are hosted centrally and shared across multiple clients, teams, or applications.

The transport choice determines the deployment model: stdio for local, single-user tools; SSE for shared, enterprise-grade infrastructure.

Why MCP Matters

Before MCP: Custom Integrations Everywhere

Before MCP, connecting an AI model to a new data source or tool required custom code for each combination of AI application and external service. A team using Claude, ChatGPT, and a custom AI agent would need three separate integrations for the same database -- each with its own authentication, error handling, and response parsing logic.

This approach doesn't scale. Every new AI application or tool requires O(N x M) integrations (N applications x M tools) rather than O(N + M) with a shared standard.

After MCP: Build Once, Use Everywhere

With MCP, a tool integration is built once as an MCP server and works with any MCP-compatible client. A PostgreSQL MCP server works with Claude, GitHub Copilot, Cursor, and custom AI agents -- no modification needed for each client.

This changes the economics of AI tool integration. Instead of every team building its own connectors, a shared ecosystem of MCP servers emerges. Open-source MCP servers already exist for dozens of common services: databases, file systems, GitHub, Slack, Jira, Google Drive, and more.

Agentic AI Workflows

AI agents -- models that plan and execute multi-step tasks autonomously -- need reliable, discoverable access to tools. An agent that's asked to "analyze our sales pipeline and email a summary to the VP" needs to:

1. Query the CRM database for pipeline data
2. Run analytical queries across historical data
3. Generate a formatted summary
4. Send an email through the organization's email system

MCP provides the standardized discovery and invocation layer that makes this possible. The agent discovers available tools, reads their schemas to understand parameters, invokes them in sequence, and handles results -- all through a uniform protocol.

Security and Governance

In enterprise environments, giving AI models unrestricted access to tools and data creates security and compliance risks. MCP enables centralized governance:

• Access control: Define which models can invoke which tools, with what parameters, under what conditions
• Audit logging: Record every tool invocation for compliance and debugging
• Rate limiting: Prevent AI models from overwhelming external services
• Data masking: Filter sensitive information from tool responses before they reach the model

These controls are especially important in regulated industries like financial services and cybersecurity where AI access to data must be governed and auditable.

MCP Servers in Practice

Database Access

An MCP server wrapping a database (PostgreSQL, MySQL, Snowflake) exposes tools for executing queries and resources for reading schema information. The AI model can discover the database schema, write SQL queries, and execute them -- all through the MCP interface.

With SQL federation, a single MCP server can provide access to multiple databases simultaneously, so the AI model queries any connected source through one interface.

Developer Tools

IDE integrations (VS Code, JetBrains, Cursor) use MCP to give AI coding assistants access to:

• Project files: Reading and writing source code
• Build systems: Running tests, compiling code, checking linting
• Version control: Viewing diffs, creating branches, committing changes
• Documentation: Searching API docs, reading README files, accessing style guides

The AI assistant discovers these capabilities through MCP and uses them as needed during coding tasks.

Enterprise MCP Gateways

As organizations deploy more MCP servers, managing them individually becomes unwieldy. An MCP gateway sits between clients and servers, providing:

• Federation: Multiple MCP servers behind a single endpoint
• Centralized auth: One authentication point for all tool access
• Observability: Distributed tracing across all MCP interactions
• Load balancing: Routing requests across server replicas

This gateway pattern is how MCP scales from individual developer tools to enterprise-wide AI infrastructure.

MCP vs. Function Calling

Function calling is a model-level capability where the AI generates structured arguments for predefined functions. MCP is a protocol that standardizes how models discover, connect to, and invoke those functions across distributed servers.

Think of it this way: function calling defines the "what" (the model wants to call a function with these arguments), and MCP defines the "how" (discovering the function, routing the request to the right server, handling authentication, and returning results).

They're complementary layers. Function calling without MCP means custom integration code for every tool. MCP without function calling means the model can't express tool-use intent. Together, they create a complete system for AI-tool interaction.

MCP with Spice

Spice functions as an enterprise MCP gateway, federating distributed MCP servers with:

• Internal and remote hosting: Run stdio-based tools locally for low-latency or federate to remote servers over SSE
• Governed tool routing: Dynamically assign tools to specific models with fine-grained access controls
• Hybrid data access: Combine MCP tool results with federated SQL queries, embeddings, and hybrid search in a single runtime
• Distributed tracing: Full visibility into execution paths across MCP servers, models, and data sources

This means AI applications get tool access, data access, and query capabilities through a single, governed infrastructure layer.

Advanced Topics

MCP Transport Protocols in Depth

The choice of transport protocol determines how MCP clients and servers communicate, and each transport has implications for latency, scalability, and security.

stdio runs the MCP server as a child process of the client. Communication happens over stdin and stdout using JSON-RPC 2.0 messages. This transport has near-zero latency (no network overhead), strong process isolation, and simple lifecycle management -- the server starts and stops with the client. The limitation is that stdio servers cannot be shared across multiple clients or machines. Each client spawns its own server instance.

Streamable HTTP (which supersedes the earlier SSE-only transport) uses HTTP POST for client-to-server messages and Server-Sent Events for server-to-client streaming. This enables remote deployment where MCP servers run on dedicated infrastructure and clients connect over the network. Streamable HTTP supports standard HTTP infrastructure: load balancers, TLS termination, API gateways, and authentication middleware. The tradeoff is network latency (typically 1-50ms per round trip) and the need for explicit authentication and authorization.

For enterprise deployments, the Streamable HTTP transport is necessary. Multiple AI applications across an organization can connect to centrally managed MCP servers. When combined with a gateway, this creates a hub-and-spoke architecture where tool governance is centralized regardless of which client initiates the request.

Capability Negotiation

When an MCP client connects to a server, the first exchange is a capability negotiation. The client sends an initialize request declaring its protocol version and supported features. The server responds with its own capabilities -- which of the three primitives (tools, resources, prompts) it supports, whether it supports change notifications, and any server-specific metadata.

This negotiation serves two purposes. First, it ensures version compatibility -- a client can detect if a server uses an unsupported protocol version and fail gracefully. Second, it enables feature discovery. A client connecting to an unknown server learns exactly what the server offers without hardcoded assumptions. If a server only exposes resources (no tools), the client knows not to send tool invocation requests.

Capability negotiation also supports change notifications. A server that declares support for tools/listChanged can notify the client when its tool set changes at runtime -- for example, when a new database table is added or a new API endpoint becomes available. The client refreshes its tool manifest without requiring a restart or reconnection. This dynamic discovery is critical for long-running agent systems that need to adapt to evolving tool landscapes.

Gateway Patterns

As organizations deploy dozens of MCP servers, managing direct client-to-server connections becomes impractical. An MCP gateway sits between clients and servers, aggregating tools from multiple servers behind a single endpoint.

The gateway pattern provides several architectural benefits. Tool aggregation combines tools from all downstream servers into a unified manifest. A client sees one tool list regardless of how many servers provide those tools. Centralized authentication means each client authenticates once with the gateway rather than managing credentials for every downstream server. Access control policies are enforced at the gateway level -- an AI model used for customer support gets access to knowledge base tools but not to deployment or financial tools, regardless of what the underlying servers expose.

Observability is another key benefit. The gateway is the single point through which all tool calls pass, making it the natural place to implement distributed tracing, latency monitoring, and usage metrics. When a multi-step agent workflow spans five tool calls across three servers, the gateway can trace the entire execution path and measure end-to-end performance.

Gateway architectures also enable tool versioning and migration. When a tool's implementation changes -- for example, migrating a database query tool from one backend to another -- the gateway can route requests to the new implementation without any client changes. This decouples tool consumers (AI applications) from tool providers (MCP servers), enabling independent evolution of both sides.