How MCP Connects AI Agents — and What Production Adoption Requires

Within roughly a year of its release, the Model Context Protocol (MCP) had more than 10,000 active public servers and more than 97 million monthly downloads across its SDKs. The reason MCP usage spread so quickly is straightforward: AI applications, particularly agents, need access to data and tools outside the model. MCP provides a standard interface for discovering and invoking capabilities, while the MCP server manages the system-specific integrations behind them. A single server can support multiple compatible assistants, agents and applications.

This shared access layer also handles some of the most sensitive parts of an agent workflow. It may receive login credentials, process private data and carry requests into systems that update records, send messages or trigger other actions. Implementing MCP requires understanding both the protocol mechanics and the controls that must be in place once those connections move into production.

The Model Context Protocol is an open standard for connecting AI applications with external tools and data sources. Introduced by Anthropic in November 2024, it defines how AI applications discover external capabilities, exchange structured messages and invoke tools exposed by compatible servers.

MCP is often called “the USB-C for AI agents” because both provide a common interface between otherwise separate systems. The analogy explains portability: an AI application that supports MCP can connect with many compatible servers without requiring a unique protocol for each one.

But the comparison only goes so far. MCP standardizes the connection, but each organization remains responsible for approving servers, controlling user access and limiting what connected tools can reach. Those decisions are typically enforced by the broader agent system rather than by MCP. In many implementations, MCP sits within the agent harness — the orchestration layer that determines which external capabilities to expose, when to invoke them and what controls to apply.

Organizations must also account for the protocol’s continued evolution. MCP is an actively developed, versioned standard. The July 2026 release, for example, made substantial changes to transport, discovery and session handling, while introducing a formal lifecycle and deprecation policy for future changes. Clients and servers can support multiple versions of MCP. If a server doesn’t support the version used by a client, it identifies the versions it does support so the client can retry with a mutually supported version.

An MCP connection links an AI application to capabilities made available by one or more servers. The architecture defines the components involved and how they work together. It describes how tools, resources and prompts are presented and discovered, how requests reach the underlying system, and whether messages travel to a local process or a remote service. Together, these elements define the path a request takes from the host to the server and back.

Hosts, clients and servers

The host is the AI application that receives the user’s request and manages the model, user experience, orchestration logic and application-level policies. An integrated development environment, desktop assistant or enterprise agent application could serve as a host.

Inside the host, an MCP client communicates with a particular server. A host connecting to several servers generally creates a separate client for each one, allowing it to control which capabilities and context are available through each connection.

The MCP server provides access to capabilities that clients can discover and use, while handling the system-specific integration behind them. A server might connect to a database, repository or business application. It can run locally as a process on the same computer as the host or remotely as a service used by clients over a network.

Tools, resources and prompts

MCP defines several protocol primitives, or building blocks, that servers can provide to clients. Three of the most widely used are tools, resources and prompts, each supporting a different type of interaction.

• Tools are operations that a model or host can request, such as querying inventory, retrieving a customer record or creating an issue. Each definition describes the operation and the structured inputs it accepts.
• Resources provide contextual data, including files, database schemas and application records. The host decides when and how to include that information in the model’s context.
• Prompts are reusable templates supplied by the server and made available through the client experience. A repository server, for example, might provide a prompt for reviewing a proposed code change.

Together, these primitives give the host a structured description of the server’s available context and capabilities.

Discovery and invocation

Consider an analyst who asks an agent to explain a decline in subscription renewals. The host has an MCP client connected to an approved analytics server.

The client retrieves the server’s available tools, including one that queries a governed revenue semantic model. Its definition tells the application what the tool does and which inputs it requires. The agent selects that tool and supplies structured arguments based on the analyst’s question.

The client sends the request to the MCP server, which validates it and invokes the underlying analytics service. Access controls attached to the server or data system determine what data the request is permitted to reach. The result returns through the client to the host, where the model can use it to continue the analysis or prepare a response.

Tools can be added or revised on the server side and made available to compatible clients through the same interface. Chris Caudill, Snowflake Sr. AI/ML Architect, Applied Field Engineering, explains: “One of the most important problems that MCP solves is tool discoverability. With rigid integrations like traditional APIs, the toolset behind the API can’t evolve independently from the agent.” MCP changes that relationship by decoupling the components. “The MCP toolset can grow and evolve, and the agent will discover what’s available at runtime,” he says. The same standard can also make a common set of tools available across multiple agents.

Local and remote transport

MCP uses JSON-RPC, a structured format for exchanging requests, responses and notifications. Local connections commonly use standard input/output, or stdio, to communicate with a server process running on the same computer. Remote servers use Streamable HTTP to receive protocol requests over a network.

The transport affects where the work occurs and what needs to be protected. A local server may reach files, credentials or development tools on the user’s computer, while a remote server requires authentication, encrypted network connections and service monitoring. In both cases, operators need to know which system executes the request and which data passes through the connection.

MCP sits alongside several established mechanisms in AI application architecture. APIs, function calling and retrieval-augmented generation (RAG) each address a different part of the system.

MCP and APIs

An API defines how software interacts with a particular service. Its endpoints, data structures, authentication requirements and error behavior belong to that service.

An MCP server frequently uses those APIs underneath, translating one or more service-specific operations into tools or resources that MCP clients can discover through a common interface. The API continues to perform the service interaction, while MCP standardizes how the AI application finds and requests the capability.

Suppose an organization wants three agent applications to use the same customer support platform. With direct integrations, each application needs code that understands the platform’s API, authorization flow and response formats. An MCP server can hold that service-specific logic, then publish a smaller set of approved operations — perhaps searching tickets, adding an internal note and retrieving account history — for all three clients.

MCP often acts as an AI-facing integration layer over existing APIs, databases and application logic. It provides consistency for AI-facing discovery and invocation while preserving the underlying service contract.

MCP and function calling

Function calling refers to a model producing a structured request for a named operation. The application provides the model with function or tool definitions, including schemas for accepted arguments. When the model determines that an operation is useful, it returns a structured call. Application code validates the request, runs the function and sends the result back to the model.

MCP can supply the connection, tool definitions and invocation path used by that process. Through discovery, the client obtains schemas from an MCP server. The host may then give selected tool definitions to the model, which produces the structured arguments needed for the call.

An AI application can use function calling with locally implemented functions and no MCP connection. It can also use MCP while keeping tool selection outside the model, such as when a user selects a predefined operation through the interface.

MCP and RAG

RAG retrieves information from an external knowledge source and adds that material to the model’s context before generation. A RAG application might search product documentation, select relevant passages and ask the model to answer using the retrieved evidence.

MCP can provide a route to the retrieval system. A search server might expose a tool that accepts a query and returns matching passages, or publish resources that the host can read. After retrieval, the host decides how to construct the model context and generate the answer.

The protocol also supports work far beyond retrieval. Tools may update records, trigger workflows, perform calculations or communicate with business applications. Likewise, a RAG pipeline may connect directly to a search engine or database without using MCP.

Safe Software CEO Don Murray demonstrates how AI agents use Model Context Protocol with FME to connect complex enterprise and spatial data to Snowflake:

MCP gives clients and servers a common way to describe and request capabilities. A tool definition includes a name, a description and an input schema, while protocol methods let a client discover that tool and invoke it. JSON-RPC structures the messages, and standard transports carry them between local processes or over HTTP.

Because those elements are consistent, one MCP client can communicate with servers from different providers without learning a separate protocol for each one. Version negotiation and capability declarations help clients and servers account for differences among implementations as the standard evolves.

That interoperability has limits, however. MCP confirms that a client and server can exchange messages in an agreed format, but it doesn’t verify that the server is trustworthy, that a tool behaves as described or that its output is reliable. Decisions about ownership, approval, authorization and operational review remain with the organization using the server.

MCP standardizes how tools are described and invoked, but each server determines what those tools actually do. Similar names and input schemas don’t guarantee similar behavior, so reviewers need to evaluate both the tool information shown to clients and the underlying implementation.

A separate concern is how server capabilities change over time. Because clients discover those capabilities dynamically, a newly added tool, revised schema or expanded operation can become available across every connected application as soon as the server advertises it. Version controls, approval gates and change notifications let operators assess those changes before they reach production workflows.

As MCP spreads across an organization, the security problem extends beyond any one agent or server. Different teams may connect coding assistants, internal agents and third-party applications to separate MCP servers, each with its own credentials, permissions and logs. Without a shared control layer, the organization can lose track of which servers are in use, what tools they expose, which identities can access them and where data moves after an action.

Governance has to cover the MCP environment as a whole, then follow requests through it. Organizations need an inventory of approved servers and tools, policies that remain attached to the underlying data and systems, distinct user and agent identities, safeguards around untrusted content, approval for consequential actions and an end-to-end record of what occurred.

Preserve identity through the connection

A tool call may originate with a person, an application acting for that person or an agent working autonomously within a longer task. The receiving system needs enough identity context to evaluate the request correctly.

Caudill points to a fundamental risk in direct agent connections. “The biggest risk of allowing agents to connect directly is credential scope,” he says. “Agents are typically configured with a long-lived credential that has a broadly scoped service account.” The server may see the same powerful credential regardless of which user initiated the action, which agent selected the tool or what task is underway.

A better approach preserves the relevant identity through the connection and evaluates authorization when the action occurs. OAuth can support delegated access to remote servers, while role-based access control (RBAC) and service-specific policies restrict which resources and operations the authenticated identity may use. Credentials should remain scoped to the intended server and audience.

The agent should also remain identifiable as a distinct actor separate from the human user. This allows policies and audit records to show that an operation occurred during an agent session, even when the agent was acting on behalf of an authorized user.

Session scope adds another boundary. An agent performing a read-only variance analysis, for example, has no reason to inherit every available privilege. Restricting the session to the task reduces the set of actions exposed if the model selects the wrong tool, receives manipulated context or follows an ambiguous instruction.

Treat retrieved content as untrusted input

Agents routinely process text from documents, websites, messages and tool results. Some of that content may contain instructions written to influence the model. In an indirect prompt injection, malicious directions appear inside external data, and an agent may interpret those directions as trusted instructions.

MCP expands the number of sources and actions available to an application, so the consequences of poor content separation can extend far beyond an incorrect answer. A deceptive or compromised tool description could affect tool selection, while manipulated content returned by one server could induce a later call to another.

No single filter reliably resolves prompt injection. Practical defenses combine narrowly scoped permissions, separation between instructions and retrieved data, input and output validation, tool allowlists and approval requirements for consequential actions. The host should also limit which server outputs may influence later tool calls, particularly when several systems participate in the same task.

Avoid confused-deputy authorization flows

A confused deputy problem arises when an intermediary uses its legitimate authority on behalf of an unauthorized requester. Within MCP, a proxy server may connect clients to a third-party API using a shared OAuth client identity. Without per-client consent and careful validation of redirect URIs and authorization state, an attacker may exploit that intermediary relationship to obtain access that the user didn’t approve.

This consideration applies beyond OAuth. Every intermediary should preserve enough request context for the next system to make its own authorization decision. When a chain of servers collapses several identities into one privileged connection, downstream controls lose the information needed to enforce least privilege.

Match approval requirements to the action

Approval requirements should track the consequences of the action. Low-risk reads can typically proceed automatically, while consequential actions should require explicit approval or narrowly scoped preauthorization.

Reading a public knowledge article, for example, may require no interruption. But sending a customer message, changing a financial record or deleting a cloud resource typically warrants a review step or an equivalent policy control. The approval interface should identify the tool, proposed arguments, target system and likely effect, giving the user enough information to make a meaningful decision.

For multi-step workflows, one approval at the beginning may be too broad. The task can branch as the agent receives new information, so high-impact actions should require approval immediately before the tool call. Organizations can also require a second human reviewer for particularly sensitive operations.

Record the action sequence

Traditional application logs will typically show that an API received a request, but omit the agent context around it. Investigating an MCP workflow requires a wider trail: who initiated the task, which agent and client participated, what tools were available, which tool was selected, what arguments were sent and which systems the workflow touched afterward. Centralized tracing reduces the need to reconstruct that sequence from separate client, server and application logs. It also supports operational debugging.

Audit data must receive its own access and retention controls. Tool inputs and results may contain sensitive business information, so capturing every interaction without filtering can create another repository of high-value data.

A single local MCP server is relatively easy to manage: one host connects to one process, and the developer who configured it usually knows which files, credentials and tools it can reach. As adoption spreads across teams, several applications may connect to the same remote server, servers may expose tools owned by different departments, and clients may discover new capabilities without a corresponding change to the application itself.

For this reason, enterprise MCP operations begin with an approved server inventory. For each server, the inventory should identify its owner, source, version, authentication method, exposed tools and underlying systems. Local, remote, managed and self-hosted deployments create different infrastructure responsibilities, but each one still needs a named owner who can explain what the server does and who is accountable for its operation.

This ownership continues after deployment. Because clients discover capabilities dynamically, a newly added tool, revised schema or expanded operation can reach every connected application as soon as the server advertises it. Version controls, review gates and change notifications give operators a chance to assess those changes before they enter production workflows. The same lifecycle should cover credential rotation, vulnerability remediation and retirement when a server no longer supports an active use case.

Centralized authorization gives administrators one place to approve servers, restrict specific tools and revoke access across multiple clients. It also reduces the chance that one application retains broader permissions than another simply because its configuration was never updated.

Operational visibility completes the control path. Service metrics such as latency, availability and error rates show whether the connection is healthy, while agent-level traces show which tools were discovered, what arguments were sent and which systems the workflow reached next. Together, those records support both incident investigation and routine debugging.

MCP gives agents a standard route into databases, business applications and internal tools. That access also combines several forms of authority that security teams have historically governed separately: reading sensitive data, performing actions in operational systems and moving information across boundaries. As different business units add agents and MCP servers independently, organizations can lose track of which servers have been approved, what tools each agent can use and where the resulting data travels. Unvetted servers, tool hijacking and data exfiltration are all part of the MCP adoption problem, alongside the AI engineering work required to build the connections.

Snowflake’s approach treats MCP traffic as part of the enterprise security plane. Rather than relying on each coding assistant, agent framework or internal application to implement its own controls, Cortex AI Gateway places a shared governance layer between agents and the models, data, MCP servers and enterprise tools they access. This gateway enables identity, policy and audit controls to be applied at the level of an individual tool call.

As Caudill explains, “Consider MCP as a scoped collection of capabilities, whereas the AI gateway acts as the governance layer that standardizes controls and policies across all integrations.”

Administrators gain a central place to grant, restrict and review access across Snowflake agents and third-party environments, including external agent platforms, coding assistants and custom applications. This reduces the security drift that develops when every client maintains its own server configuration and authorization rules.

Identity requires particular care when an agent acts for a user with broad privileges. Snowflake Agent Identity records the agent as a distinct participant in the session, allowing access policies and account usage records to differentiate its activity from the person directing it. Restricted Session Scope (GA soon) is designed to narrow the agent’s authority to the current task, so a workflow created for read-only analysis cannot automatically inherit every action available through the user’s normal role.

Central governance also gives security teams visibility across the MCP environment. Teams can discover and monitor agent connections, including unsanctioned MCP servers, and use fine-grained authorization controls to restrict the tools an agent can invoke. Trace records support usage monitoring, troubleshooting, incident investigation and compliance review without requiring every agent application to build a separate audit layer (features in public preview soon).

MCP gives AI applications a common way to discover external capabilities and request their use. This shared interface reduces repeated integration work and allows tools to travel across hosts more readily, while APIs, function calling and RAG continue to perform their distinct roles within the wider AI infrastructure stack.

But production adoption requires an operating model around the protocol. Server ownership, identity propagation, scoped authorization, content validation, approval controls and end-to-end tracing determine how safely an organization can expand the number of connected agents and tools.

_{Forward-looking statements: This content contains forward-looking statements, including about our future product offerings, and are not commitments to deliver any product offerings. Actual results and offerings may differ and are subject to known and unknown risk and uncertainties. See our latest 10-Q for more information.}