MCP (Model Context Protocol) is the default method for agents to interact with tools. It provides the foundational infrastructure for human-assist surfaces (IDEs) and headless agents interacting with other systems, the same tool-use loop that underlies most production agents.
When creating an MCP server to expose an API or dataset at an enterprise level, several aspects, such as security, governance, reliability, and scalability, need to be considered.
Key components of an MCP server’s architecture
- Interface layer: Uses standard IO or Streamable HTTP for transporting JSON-RPC messages.
- Application layer: Routes to tools, prompt handlers, schema validators, auth checks, etc.
- Domain layer: Contains business logic.
- Infrastructure layer: Facilitates system integrations via drivers, adapters, and clients.
The technical layers on an MCP architecture give you the mechanics, and the rest of this article covers how to secure, scale, and run them in production.
What the architecture alone cannot supply is the organizational context your agents need to act accurately. That is why teams pair their MCP setup with Atlan’s context layer, which serves governed context to agents through its own MCP server.
MCP architecture deep dive: quick facts
Permalink to “MCP architecture deep dive: quick facts”MCP architecture follows a host, client, and server model built on JSON-RPC 2.0 messages, with a production-grade server split into four layers: interface, application, domain, and infrastructure. Enterprise deployments add scoped authorization, an MCP gateway, and asynchronous Tasks on top of that foundation, though MCP itself only handles tool-access mechanics, not organizational context.
| MCP Architecture: Quick Facts | |
|---|---|
| Core model | Host, client, and server; one dedicated MCP client per connected server |
| Message format | JSON-RPC 2.0 for every request, response, and notification |
| Server layers | Interface, application, domain, and infrastructure (4-layer separation) |
| Standard transports | Standard IO (local processes) and Streamable HTTP (remote/shared deployments) |
| Current spec version | 2026-07-28 |
| Async task handling | Tasks extension (io.modelcontextprotocol/tasks), opt-in since the 2026-07-28 spec |
| Enterprise access control | Enterprise-managed scoped authorization; per-user OAuth redirects discouraged |
| Multi-server routing | An MCP gateway provides one endpoint, discovery, and permission-scoped tool visibility |
What are the key components of the MCP architecture?
Permalink to “What are the key components of the MCP architecture?”The MCP (Model Context Protocol) follows a host, client, and server model, where the host application creates one dedicated MCP client for every server it connects. Every message exchanged over that connection is a JSON-RPC 2.0 payload, no matter which transport carries it. This is one layer of the broader AI agent architecture question of how a system perceives, decides, and acts, since MCP carries the “act” half of that loop.
Inside the server, an enterprise-grade implementation separates concerns into four layers. This mirrors the presentation, domain, and data access split that Martin Fowler documented for information-rich systems, adapted for agent-facing infrastructure:
-
Interface layer: Handles message transport between the MCP client and server. The MCP spec defines two standard transports, standard IO for local processes and Streamable HTTP for remote or shared deployments, both carrying JSON-RPC messages.
-
Application layer: Routes each incoming request to the right handler. This is where tool routing, prompt handlers, schema validators, and authorization checks live, so every call is validated and permission-checked before it touches business logic.
-
Domain layer: Contains the business logic itself. Keeping this layer free of protocol concerns means the same logic can serve MCP today and any future protocol without a rewrite.
-
Infrastructure layer: Connects the server to the systems it exposes. Drivers, adapters, and API clients sit here, translating domain requests into calls against databases, warehouses, and SaaS applications.
The payoff of this separation shows up in day-to-day operations. You can swap transports, tighten auth policies, or add new integrations without touching the layers around them. Atlan’s MCP server follows this pattern, with the open-source Agent Toolkit handling the tool definitions while the infrastructure layer connects into the context lakehouse underneath. Those tool definitions are also distinct from agent skills, which package a whole workflow rather than a single callable tool, and from the six AI agent primitives an agent combines to act reliably, where the interface and application layers cover tool access and the domain and infrastructure layers cover what that access reaches.
How do you enforce enterprise-grade security in context servers?
Permalink to “How do you enforce enterprise-grade security in context servers?”The MCP spec provides the key principles for user consent, data privacy, and tool safety, which narrow down to one overarching principle:
The agents must only be able to access the context they’re explicitly designated to access. They must only be able to use the context in the way that has been explicitly defined.
Enforcing the above principle translates to the implementation of the following:
-
Enterprise-managed scoped authorization for cross-application access: Only the enterprise IdP can issue tokens for MCP servers; don’t allow per-user OAuth redirects. So, you can have more security and governance controls at the top.
-
Minimal scope consent: Make sure that you design the agents to get the least number of privileges they need for tools. Build a workflow that allows for scope increase while the agent is in action.
-
Audit and log tool calls and activity: Capture all inputs, outputs, and policy decisions for MCP tool calls.
-
Have data security guardrails in place: Enforce granular security policies on APIs and datasets to add another layer of security in the data layer.
-
Design for failure/attacks: Consciously design the system to expect prompt injections and other types of attacks; treat tool outputs and context as untrusted input even if they are coming through an authorized agent.
None of this is optional once an agent can act on production data. Each layer above closes a specific failure mode: scoped authorization stops a compromised agent from reaching systems it was never meant to touch, and audit logging is what lets you reconstruct what happened when one does. The same discipline applies once more than one agent is involved: how to secure multi-agent systems at the enterprise level extends scoped authorization and audit logging to the coordination layer, and a broader AI agent risks and guardrails framework carries the same controls past the MCP boundary into policy and monitoring.
With hardened security, you also need to design your agents to handle complex tasks, make multiple tool calls, and wait for tool responses. Let’s look at the best practices for the same.
Build your AI context stack
Get the four-layer blueprint for turning MCP's mechanics into organization-wide context, from metadata foundation to agent orchestration, with practical implementation steps for 2026.
Get the Stack GuideHow do you work with long-running tasks asynchronously?
Permalink to “How do you work with long-running tasks asynchronously?”Whenever an agent calls a tool, it must wait for a response.
While many tools may run on the same virtual machine as the agent, others are remote, which means there are network, compute, rate limits, and other factors involved. This can cause the agent to wait a long time.
During that time, the agent must continue working on tasks that can be done while it waits for the server’s response. MCP has two constructs to handle this:
-
Tasks: MCP Tasks are durable state machines where each task has an ID, using which the agent can track progress and pull results asynchronously via
tasks/getwhile acting on other things in the meantime. -
Polling: Agents expecting a response from a tool can check the progress by polling or getting status notifications, based on which they can act.
Both Tasks and Polling should be used to make the agent-tool exchange more reliable while remaining fully asynchronous.
A quick caveat about Tasks: as of the 2026-07-28 spec, Tasks moved out of the core protocol into an official extension (io.modelcontextprotocol/tasks), which both client and server must explicitly support. That’s a maturity signal, not a downgrade: the redesign replaced the old blocking tasks/result call with polling via tasks/get and added tasks/update for sending input back mid-task. Still, extension features iterate faster than the core spec, so keep your retry and timeout logic decoupled from Tasks’ exact shape.
Tasks solve progress-tracking for a single long-running tool call. A related but separate problem is coordinating multiple agents working the same job, which is where agent-to-agent protocols like A2A come in. Teams standing up both protocols side by side can follow an A2A protocol implementation guide for the coordination layer that MCP itself does not cover.
How do you scale MCP servers with an MCP gateway?
Permalink to “How do you scale MCP servers with an MCP gateway?”An MCP server isn’t usually a single entity that exposes multiple tools to MCP clients. Rather, a collection of MCP servers works across internal and external systems to expose APIs, datasets, and documents.
Every connection has its own configurations and limitations. A single MCP server cannot possibly handle various configurations in a single layer, which is why a gateway is placed between MCP clients (agents, in this case) and MCP servers.
An MCP gateway provides the following:
-
A single endpoint that is accessible to MCP clients, including IDEs, chat interfaces, and agents, to handle MCP server discovery, connection, and logging.
-
Permission-based discovery is enforced at the gateway level to ensure that any given agent is only able to see the tools it is allowed to see and use.
Just as an LLM gateway centralizes model routing and rate limits for inference traffic, an MCP gateway centralizes routing and discovery for tool traffic, and Databricks’ Unity AI Gateway is a platform-native example of that same governance pattern applied to a single vendor’s stack. Deciding when MCP is the right fit over a bespoke REST API, or over raw function calling, usually comes down to whether more than one agent or client needs the same tool surface.
With a multi-tier MCP server that can handle asynchronous tasks, has enforced security, and can route every tool discovery request and call via a gateway, you get an enterprise-grade MCP setup.
This architecture gives you the mechanics but doesn’t really give you context. The context still needs to be accumulated and organized in an organization-wide enterprise context layer.
That’s where Atlan comes into the picture.
Get the CIO's guide to context graphs
See how enterprise teams structure the context graph underneath their MCP servers, so agents get more than tool access.
Download Context GuideHow does Atlan serve governed context to your agents?
Permalink to “How does Atlan serve governed context to your agents?”Context in any enterprise is spread across tens, sometimes hundreds, of systems, where teams and squads that work in isolation have their own unique sets of tools and ways of working.
MCP alone vs. MCP with an enterprise context layer
Permalink to “MCP alone vs. MCP with an enterprise context layer”| Aspect | MCP Alone | MCP + Atlan’s Context Layer |
|---|---|---|
| Context scope | Whatever that server’s infrastructure layer connects to | Cross-stack: warehouses, BI tools, orchestration, and every other MCP server in the estate |
| Business definitions | Re-implemented separately inside each server’s domain layer | Centralized, reusable Active Ontology served to every agent |
| Lineage | Limited to what that server’s own systems track | Cross-system lineage across the full data estate |
| Governance | Per-server auth, scopes, and audit logging | Unified policy and certification enforced across every connected server |
| Discovery at scale | Each client manages its own server list and permissions | A single MCP gateway handles discovery, routing, and permission-scoped visibility |
For a context layer to work, you need a platform with the ability to connect with all the context tools and add some semblance of structure to it. Atlan is the enterprise context layer for AI that structures and organizes context by unifying context from multiple systems and:
-
Populating the Context Lakehouse, which is the core storage and organization layer that combines a knowledge graph with Iceberg-native storage and vector-native search, the same structure examined in context layer vs. knowledge graph.
-
Integrating tools with the Atlan MCP server to expose search, lineage, and policy context as tools built on the open-source Agent Toolkit created by Atlan, backed by an Active Ontology rather than one BI tool’s private definitions.
-
Building, testing, and shipping context using Context Engineering Studio with the singular aim of providing refined and curated context for the agents to work efficiently and accurately, packaged into reusable Context Repos that Context Agents maintain at scale, rather than leaving a data catalog’s index to double as a context layer.
In an enterprise setting, MCP clients connect to Atlan’s MCP server and to a wide range of other MCP servers in the stack, whether that’s a Databricks server exposing Unity Catalog or a general-purpose MCP-connected data catalog. Here, Atlan supplies the organizational context the other servers lack, the same agent context layer pattern that scales from one agent to many on purpose, not by accident.
Real stories from real customers building enterprise context layers
Permalink to “Real stories from real customers building enterprise context layers”How Workday is building an AI-ready semantic layer
Permalink to “How Workday is building an AI-ready semantic layer”"Atlan captures Workday's shared language to be leveraged by AI via its MCP server. As part of Atlan's AI labs, we're co-building the semantic layer that AI needs."
Joe DosSantos, VP Enterprise Data & Analytics, Workday
How DigiKey built a unified, sovereign context layer for its data and AI estate
Permalink to “How DigiKey built a unified, sovereign context layer for its data and AI estate”"Atlan is much more than a catalog of catalogs. It's more of a context operating system…Atlan enabled us to easily activate metadata for everything from discovery in the marketplace to AI governance to data quality to an MCP server delivering context to AI models."
Sridher Arumugham, Chief Data & Analytics Officer, DigiKey
See Atlan's context layer live
Watch how Atlan serves governed context to agents across MCP servers, IDEs, and chat interfaces in a live walkthrough.
Watch the Live DemoMoving forward with MCP servers
Permalink to “Moving forward with MCP servers”Creating and deploying enterprise-grade MCP servers is easy if you follow a multi-tier architecture, tightly scope agent authorization, and handle multiple MCP servers, tools, and agents asynchronously.
Once you solve these, the foundational architecture is solid. What still requires attention is the context, since the architecture doesn’t handle it. Whether the server in question sits in front of Databricks or Snowflake, or you’re building one from scratch with a step-by-step MCP server implementation guide or a broader playbook for building MCP servers for enterprise data, the architecture in this guide holds.
You need Atlan’s context layer, spanning your enterprise, to get the context your agents need when they need it.
FAQs about MCP architecture deep dive
Permalink to “FAQs about MCP architecture deep dive”1. What is the difference between an MCP host, an MCP client, and an MCP server?
Permalink to “1. What is the difference between an MCP host, an MCP client, and an MCP server?”The MCP host is the application where the agent is running. Think of a VM with a hosted agent runtime. It can be an IDE, a chat interface, or an autonomous agent. The host spins up an MCP client to interact with an MCP server. The client has a direct and dedicated connection to the server. If the host connects to ten MCP servers, there’ll be ten client-server connections.
2. Is MCP the only protocol needed for context servers?
Permalink to “2. Is MCP the only protocol needed for context servers?”No. MCP facilitates agent-to-tool communication, while other protocols handle agent-to-agent communication, agent-to-user interfaces, and payments, among other things. A typical enterprise setup, especially with context servers, uses many of these protocols, not just one. Having said that, MCP does sit at the core of context exchange between agents and tools.
3. Do I need an MCP gateway?
Permalink to “3. Do I need an MCP gateway?”For enterprise-grade context servers, you do. In enterprise settings, there are hundreds of applications, and usually those applications expose data via different MCP servers. Because they have different settings, service-level agreements, rate limits, pricing, and overall configurations, handling them all in a single place won’t scale, which is why an MCP gateway is needed.
4. How does Atlan’s MCP server work with other MCP servers?
Permalink to “4. How does Atlan’s MCP server work with other MCP servers?”MCP clients from an MCP host connect to multiple MCP servers. Atlan’s MCP server is one of them. There are many other servers, but those MCP servers don’t have the broader organizational context to provide the client. That’s where Atlan’s enterprise context layer comes in, serving as the context source for the client while working with all the other MCP servers connected to it.
5. Which transport should be used for enterprise MCP servers?
Permalink to “5. Which transport should be used for enterprise MCP servers?”Streamable HTTP is the standard for anything remote or shared with the MCP servers in production. The official spec only defines support for two transports. The other one is standard IO, but that’s for local development, not for production use across the enterprise.
