Agentic Data Engineering Resources

Resource

How to Implement MCP in Your Agent Stack

Learn how to implement MCP in your agent stack, choose transports, wire clients, manage auth, and plan the data infrastructure beneath it.

Pedro Lopez

Jun 5, 2026

Updated Nov 5, 2026

Summarize with AI:

Most agent stacks break when tool access starts to scale, not because the model cannot reason, but because the surrounding system cannot reliably discover tools, manage sessions, enforce permissions, and keep data access governed.

MCP gives agents a standard way to discover and call external tools. But MCP works best as a protocol layer, not as the whole architecture. In production, successful MCP implementations depend on a separate infrastructure layer for authentication, schema normalization, freshness, permissions, and governance beneath the protocol itself. Without that lower layer, tool access becomes harder to scale, secure, and operate reliably across teams and systems.

TL;DR

MCP is the protocol layer between your agent framework and external tools and data sources. It defines tool discovery, invocation, and context delivery through a consistent interface.
For production deployments, Streamable HTTP is the transport to emphasize, while stdio fits local development and single-user desktop tooling.
MCP defines how agents discover and call tools, while authentication, schema normalization, permissions, and governance stay in the layers beneath it.
Migrate incrementally by wrapping existing integrations in lightweight MCP servers, and use progressive disclosure to control tool sprawl and token costs.

What Does MCP Look Like Inside an Agent Stack?

MCP sits between the agent's reasoning engine and the external tools and data sources that engine needs to act on. It is one layer in a larger stack.

Three Primitives Agents Interact With

MCP describes three core primitives:

Tools are functions the large language model (LLM) decides when to call
Resources are contextual data the host application controls: database schemas, configuration files, or reference documents the agent needs for reasoning
Prompts are templated messages and workflows exposed by MCP servers for client and user use

These primitives define the interface contract between your agent and the outside world, so every MCP server you build or adopt will expose some combination of them.

Where MCP Fits in the Four-Tier Agent Architecture

The following table maps each layer of a production agent stack to its core responsibility, showing where MCP sits relative to the reasoning engine above it and the data infrastructure below it.

Layer	Responsibility
LLM + agent framework	Reasoning, tool selection, orchestration
MCP protocol layer	Standardized discovery, invocation, session management
MCP servers	Tool execution, resource access, prompt delivery
Data infrastructure	Auth management, schema normalization, permissions, storage

The host creates MCP client instances, and each instance maintains a stateful session with a server. Servers do not communicate directly with the LLM. In production, many failures come from auth, schema handling, permissions, and storage below the protocol layer rather than from the model loop itself.

How Do You Implement MCP in Your Agent Stack?

Implement MCP by choosing a transport, scoping servers, wiring clients into your framework, adding auth controls, and testing the agent-to-tool loop.

Step 1: Choose Your Transport Layer

Choose Streamable HTTP for remote and multi-client deployments, and use stdio for local development and single-user desktop tools. MCP uses stdio and Streamable HTTP, and the older SSE transport is deprecated. The following table breaks down how each transport differs across deployment model, session handling, auth, and best-fit use case.

Criterion	stdio	Streamable HTTP
Architecture	Client spawns server as subprocess	Server runs as independent process
Client count	Single client only	Multiple simultaneous clients
Deployment model	Local/same-machine	Remote/network-accessible
Session management	Implicit (process lifecycle)	Explicit (Mcp-Session-Id header)
Auth model	Environment-variable credentials	OAuth 2.1 bearer tokens
Best for	Local development, single-user desktop tools	Production agent deployments, multi-agent architectures, team-shared servers
Latency	Lowest (no network hop)	HTTP overhead per request
Note	Logging must use stderr only; stdout breaks the protocol	Use Streamable HTTP for new remote deployments

This transport decision shapes session handling, auth, and deployment boundaries, so it is worth settling early.

Step 2: Configure MCP Servers for Your Data Sources

Configure MCP servers around narrow domains or operational boundaries. MCP servers work best when each server exposes focused functionality for a single domain or operational boundary. Implementation patterns for building servers vary by API complexity and auth model across common data sources, but the core rule is consistent: keep each server narrowly scoped.

The key architectural principle is one bounded context per MCP server. Split along business domains, compliance boundaries, and change cadence. That keeps tool catalogs manageable and reduces the chance that one server becomes a catch-all integration layer.

Step 3: Wire MCP Clients Into Your Agent Framework

Wire MCP clients into your framework with the client pattern that framework documents. In practice, frameworks tend to vary on three points: how they manage multi-server connections, how they keep sessions alive, and how they handle OAuth-aware clients.

A practical implementation usually needs support for multiple servers, a persistent session reference for tools that stay connected, and a clean way to mount those tools into the agent loop. The exact class names differ by framework, but the integration concerns are consistent.

Step 4: Add Authentication and Access Controls

Add authentication and access controls at the transport and gateway layers before you scale MCP across teams or servers. For Streamable HTTP transports, OAuth 2.1 is the standard production authentication approach. Authorization behavior depends on the protocol and deployment, and bearer tokens are commonly sent in an Authorization header when required.

MCP secures the client-to-server transport relationship, but it does not provide built-in governance for all downstream access patterns. In multi-server deployments, an MCP gateway can centralize auth by enforcing consistent OAuth policies, handling per-downstream token exchange, and capturing observability across MCP traffic.

Step 5: Test the Agent-to-Tool Loop

Test the agent-to-tool loop before connecting the system to an LLM. Verify that the agent discovers tools from all connected servers, invocations handle errors gracefully, and session lifecycle behaves as your framework expects.

This test-first step catches configuration mistakes before model behavior obscures them. It also gives teams a clean baseline when they later debug auth failures, missing permissions, or stale data.

How Does MCP Compare to Function Calling and Native Tool Use?

Function calling, native tool use, and MCP each solve different parts of the tool-access problem. Understanding the boundaries between them prevents teams from choosing the wrong pattern for a given workload:

Function calling is a vendor-specific model API feature. Each provider defines its own schema format, full tool definitions are re-sent with every API call, and the tool list is fixed at request time with no runtime discovery. You define the tools, and the model decides when to invoke them. The model provider handles none of the execution.
Native tool use refers to provider-managed built-in capabilities like code interpreters, file search, web browsing, and computer use. OpenAI's Agents SDK, for example, includes FileSearchTool for retrieving information from vector stores, CodeInterpreterTool for executing code in a sandboxed environment, HostedMCPTool for exposing remote MCP server tools to the model, and ImageGenerationTool for generating images from a prompt. These tools run on the provider's infrastructure and require no custom integration, but they are limited to what the provider offers and lock your agent to that provider's platform.
MCP is a model-agnostic infrastructure protocol. It supports runtime discovery and stays session-aware across interactions, and it works across model providers rather than binding you to one.

The following table compares how the three approaches differ across key architectural dimensions.

Dimension	Function Calling	Native Tool Use	MCP
Scope	Developer-defined tool schemas	Provider-managed built-in capabilities	Open protocol for external tool discovery and invocation
Portability	Vendor-specific schema format	Locked to one provider's platform	Model-agnostic, works across providers
Discovery	Static; tool list fixed at request time	Static; limited to provider's catalog	Dynamic; runtime tool discovery across servers
State	Stateless; full definitions re-sent per call	Provider-managed sessions	Session-aware via Mcp-Session-Id
Execution	Your infrastructure	Provider's infrastructure	MCP server infrastructure
Best for	Small, stable tool sets tightly coupled to one model	Sandboxed code execution, file search, and other provider-hosted capabilities	Growing tool catalogs, multi-provider stacks, dynamic discovery

In practice, these approaches coexist. An agent might use native code interpretation for computation, function calling for a handful of tightly coupled internal APIs, and MCP for dynamic access to a growing catalog of external data sources. The choice depends on who owns the tool, how often the tool set changes, and whether provider portability matters.

How Do I Migrate From Custom Integrations to MCP?

Migrate from custom integrations to MCP incrementally by wrapping existing code in lightweight MCP servers and keeping custom paths where they still fit better.

Prioritizing Which Integrations to Migrate First

Not all integrations benefit equally from an MCP migration. The following table ranks common integration types by how much they gain from the standardized discovery, auth, and session handling that MCP provides.

Integration Characteristic	Migration Priority
Read-only data retrieval from SaaS APIs (CRM, project tools)	High; migrate first
Authentication-heavy integrations (OAuth, token refresh)	High; migrate first
Write operations to production systems	Medium; migrate with caution
High-frequency, tight response-time requirements	Medium; evaluate tradeoffs
Integrations with complex join logic across sources	Low; keep custom or use infrastructure layer
Legacy systems with non-standard APIs	Low; migrate last

Running MCP Alongside Existing Integrations

Run MCP alongside existing integrations by wrapping current code in lightweight MCP servers that bridge to the standardized interface. Direct REST calls can continue to handle high-throughput paths, while MCP handles agent-driven dynamic access.

This side-by-side approach lowers migration risk. Teams can move read-heavy and auth-heavy paths first, then keep deterministic or performance-sensitive paths on custom code where that remains the better fit.

When MCP Is the Wrong Choice

MCP is the wrong choice when your workload depends on cross-source joins, transactional consistency, or deterministic audited execution.

Cross-source joins. MCP has no native join mechanism. If an LLM assembles results from sequential tool calls in the context window, the architecture is mismatched to the problem.
Transactional write conflicts. MCP provides no locking, no optimistic concurrency control, and no rollback. Write logic requiring consistency guarantees must remain in a purpose-built service.
Deterministic, auditable workflows. For compliance-critical workflows where operation sequences must be deterministic, explicit orchestration with code-defined call sequences is the right choice.

Recognizing these boundaries early prevents teams from forcing MCP into roles where a purpose-built service or explicit orchestration layer would be more reliable.

What Are MCP Implementation Best Practices?

The protocol itself is straightforward. The operational discipline around it is where most teams either succeed or stall. The following best practices address the areas that cause the most friction once MCP moves beyond a single-server proof of concept.

Set Explicit Request Timeouts

Some MCP SDKs enforce default request timeouts that are too short for slower tools or startup-heavy server processes. Configure timeouts explicitly for each server based on its expected response profile. Batch operations, database queries, and API calls to rate-limited services all need different ceilings.

Use Progressive Disclosure for Tool Definitions

Loading every tool definition from every connected server inflates prompt size and burns through token budgets. Expose a single discovery tool first, then load specific tool definitions only when the agent's current task requires them. This pattern conserves context window space and keeps the agent focused on relevant capabilities.

Plan for Connection Instability

Platform-specific orchestration quirks and network interruptions cause invocation failures in multi-agent MCP setups. Build retry logic and health checks into your client configuration rather than assuming persistent connections. Test across the environments where your agents will actually run, not just local dev.

Centralize Credential Governance Early

As agent and server counts grow, unmanaged credentials become impossible to track, rotate, or revoke. Establish a central credential store and rotation policy before scaling past a handful of servers. Retrofitting credential governance after a breach or audit finding is far more expensive than building it in from the start.

Scope Each Server to a Single Bounded Context

Split MCP servers along business domains, compliance boundaries, and change cadence. A server that tries to cover multiple domains becomes a catch-all integration layer, making tool catalogs unmanageable and increasing the blast radius of any single failure.

Build Governance Infrastructure Around the Protocol

The MCP spec does not provide built-in SSO integration, role-based access control (RBAC), audit trails, tenant isolation, or compliance mappings. Teams must build or integrate these controls in the surrounding infrastructure. When MCP touches enterprise data access and auditability, compliance requirements such as SOC 2, HIPAA, and PCI DSS apply to the systems around MCP, not to the protocol alone.

What Is the Fastest Path to Production MCP in Your Agent Stack?

The fastest path is to start with one data source, wire MCP into your existing agent framework, and add authentication and governance from day one rather than retrofitting them later.

MCP needs a separate data infrastructure layer for authentication, schema normalization, freshness, and permissions beneath the protocol. An MCP server wrapping a Salesforce API still needs reliable authentication, schema normalization, incremental sync for freshness, and row-level permissions. The protocol layer does not cover access control, audit trails, data lineage, or row-level permissions. Those responsibilities stay in the application layer, and skipping them is how teams end up with agents that work in demos but fail under production data access patterns. A salesforce agent connector supplies exactly that layer for the CRM, with managed auth, incremental sync, and row-level permissions beneath the protocol.

Airbyte's agentic platform fits into that lower layer as infrastructure beneath MCP. It offers 50+ agent connectors, Managed Auth for OAuth flows, API keys, and token refresh, plus a Context Store for fast search across connected sources, where agents reason across unified records. It also provides row-level and user-level access controls and audit logging.

Airbyte's agentic platform exposes those connected sources through Agent MCP, its hosted MCP server, so agents discover and invoke them and govern context delivery through the MCP interface.

Meet with an Airbyte expert to see how Airbyte's agentic platform powers production MCP deployments with governed, fresh data access, or try Airbyte's agentic platform today.

Frequently Asked Questions

Can I use MCP with OpenAI models?

MCP is an open protocol that works with model providers and clients that support the standard. In practice, that means MCP can sit below the model layer rather than locking the stack to one provider.

Does MCP replace RAG?

No. RAG, or retrieval-augmented generation, handles document retrieval and grounds agent responses in pre-indexed unstructured content like knowledge bases and documentation. MCP handles tool retrieval: how agents discover and call external tools and APIs for live data and actions. The two patterns solve different parts of the agent stack.

Is MCP production-ready?

MCP can be used in production as a protocol layer for tool discovery and invocation. Enterprise features like audit trails, multi-tenancy, and SSO integration are not built into MCP itself, so teams deploying MCP in enterprise settings must build governance infrastructure independently. Production readiness depends as much on the layers beneath MCP as on the protocol itself.

How do I handle auth across servers?

OAuth 2.1 is the production authentication approach described here, but the surrounding architecture still matters. For multi-server deployments, teams commonly use an API gateway to centralize authentication and handle per-downstream token exchange. That pattern also helps with observability and policy consistency.

What happens to token budget?

MCP servers expose tool definitions that clients discover and store for runtime use by the agent. Progressive disclosure, exposing a small set of meta-tools that retrieve specific tool definitions on demand, is one approach to managing tool context. This matters most when large servers would otherwise load too many schemas into the prompt at once.