MCP Architecture: Components, Layers, and Design Principles

What is Model Context Protocol (MCP) Architecture? 

The Model Context Protocol (MCP) is an open standard designed to bridge AI models with external data sources and tools. It uses a standardized client-server architecture to prevent bespoke integrations, enabling LLMs to dynamically retrieve context and execute actions in a secure, plug-and-play manner.

The architecture is divided into three core components and two communication layers:

Architectural components:

• Host: The primary AI-powered application the user interacts with (e.g., Claude Desktop or an IDE). It governs the overall AI workflow and decides when to fetch data or trigger tools.
• Client: The interface layer operating within the Host. It maintains the connection, handles capability negotiation, and translates LLM requests into the MCP format.
• Server: Lightweight, specialized programs that connect the AI to external systems like databases, file systems, or APIs. They expose three main capabilities to the Host:
• MCP Primitives: Resources (readable data streams or files), tools (actions the LLM can execute), and prompts (templates for organizing user input).

Communication layers:

• Data layer: Operates on the JSON-RPC 2.0 protocol, allowing clients and servers to exchange stateful, structured messages and manage tool lifecycles.
• Transport layer: The medium carrying the data. It utilizes two main implementations depending on the environment:
• Authorization and identity layer: Governs who or what is allowed to connect, what capabilities are available, and which actions can be performed.

Why MCP Architecture Matters 

As AI applications become more connected to external systems, they need a consistent way to access data and perform actions without requiring custom integrations for every service. MCP architecture addresses this challenge by defining a standard protocol that makes integrations more portable, secure, and easier to manage.

• Standardizes integrations: AI applications can communicate with different tools and services through a common protocol instead of using custom APIs for each integration.
• Reduces development effort: Developers can build an MCP server once and reuse it across multiple MCP-compatible hosts and AI applications.
• Simplifies maintenance: Changes to an external system are isolated within its MCP server, reducing the need to update every AI application that uses it.
• Supports modular architectures: New capabilities can be added by connecting additional MCP servers without redesigning the host application.
• Improves interoperability: Different vendors, frameworks, and AI platforms can work with the same MCP servers as long as they implement the protocol.
• Enables dynamic capability discovery: Hosts can discover available tools, resources, and prompts at runtime instead of relying on hardcoded integrations.
• Provides flexible deployment options: The same protocol supports both local integrations through standard input/output and remote services over HTTP-based transports.
• Creates a consistent developer experience: A shared protocol for communication, capability negotiation, and tool execution makes building AI-powered applications more predictable.

Core Components of MCP Architecture

MCP Host

An MCP host is the AI application or environment that coordinates the overall user experience. It manages the connection between the user, the language model, and any external context or capabilities made available through MCP. The host may be a desktop assistant, IDE, chatbot, coding tool, agent platform, or enterprise AI application.

In practice, the host does not usually connect directly to every external system. Instead, it creates and manages MCP clients, with each client maintaining a connection to a specific MCP server. This allows the host to work with multiple servers at once, combine their capabilities, and decide which tools, resources, or prompts should be available to the AI application during a given workflow.

MCP Client

An MCP client maintains a dedicated connection between the MCP host and an MCP server. Each client is typically responsible for one server connection, handling communication, capability negotiation, discovery, requests, responses, and updates between the host and that server.

The client acts as the host’s protocol-facing layer. It discovers what the server can provide, such as tools, resources, prompts, or notifications, and makes that information available to the host. When the AI application needs to retrieve context or invoke an action, the client sends the appropriate structured request to the server and returns the result to the host.

MCP Server

An MCP server is a program that exposes external context or functionality to AI applications through the MCP interface. A server may connect to a file system, database, SaaS platform, API, developer tool, internal business system, or another source of operational data. Its role is to package those capabilities in a standardized way so MCP clients can discover and use them.

MCP servers can run locally on the same machine as the host or remotely over a network. A local server might provide access to files or command-line tools, while a remote server might expose capabilities from a cloud service or enterprise application. Regardless of where it runs, the server defines what it offers and responds to client requests using the protocol’s structured message format.

MCP Primitives: Tools, Resources, and Prompts

MCP primitives are the core building blocks that define what a server can expose to an AI application. The three primary server-side primitives are tools, resources, and prompts. Together, they allow AI systems to take actions, retrieve context, and structure interactions in a consistent way.

Tools are executable functions that an AI application can call to perform an action, such as querying a database, creating a ticket, searching an API, reading a file, or triggering a workflow. Resources provide contextual data, such as file contents, records, documentation, logs, or API responses, that the model can use to answer questions or make decisions. Prompts are reusable templates that help guide interactions with the model, such as predefined workflows, task instructions, or few-shot examples.

These primitives are typically discoverable, meaning the client can ask the server what tools, resources, or prompts are available before using them. This makes MCP architecture dynamic. An AI application can adapt to different servers, changing capabilities, and user permissions without requiring every integration to be hardcoded into the host.

Related content: Read our guide to agentic AI architecture.

MCP Communication Layers 

Data Layer

The data layer defines the structure and meaning of communication between MCP clients and MCP servers. It is responsible for how requests, responses, errors, notifications, lifecycle events, and capability information are represented. This layer gives MCP its standardized interaction model, allowing different clients and servers to understand each other even when they are built by different teams or connected to different systems.

In practice, the data layer handles initialization, capability negotiation, primitive discovery, tool execution, resource retrieval, prompt access, notifications, and progress updates. For example, a client can ask a server which tools it supports, call one of those tools with structured arguments, and receive a structured response that the AI application can use as context. Because this layer is based on a consistent message format, MCP servers can expose capabilities dynamically instead of requiring every integration to be hardcoded into the AI application.

Transport Layer

The transport layer defines how MCP messages move between clients and servers. While the data layer focuses on what is being communicated, the transport layer focuses on how that communication is delivered. It manages the communication channel, message framing, connection establishment, and the practical details needed to exchange messages reliably.

MCP supports both local and remote communication patterns. Local transports are commonly used when a server runs on the same machine as the host, such as a filesystem or developer-tool integration. Remote transports are used when the MCP server runs over a network, such as a cloud service, SaaS platform, or enterprise system. This separation allows the same protocol-level messages to be used across different deployment models, whether the server is local, remote, or part of a larger distributed environment.

Authorization and Identity Layer

The authorization and identity layer governs who or what is allowed to connect, what capabilities are available, and which actions can be performed. In MCP architecture, this is especially important because servers may expose sensitive data, privileged tools, internal systems, or workflows that can change real-world state. Identity and authorization controls help ensure that the AI application can only access the context and actions appropriate for the user, role, environment, and policy.

This layer may include authentication tokens, API keys, OAuth-based flows, user identity propagation, permission checks, scoped access, audit logging, and policy enforcement. In enterprise environments, it should also account for nonhuman identities, delegated access, least privilege, and approval flows for sensitive tool calls. The goal is to make MCP integrations useful without turning every connected tool or data source into an unrestricted capability available to the model.

The MCP Workflow: Step by Step

1. The Host Starts or Connects to MCP Servers

The process begins when the MCP host starts an AI session and connects to one or more configured MCP servers. The host is the AI application that manages the overall experience, such as a chatbot, IDE, desktop assistant, or agent platform. Instead of integrating directly with every external system, the host creates an MCP client for each server it needs to use.

Each server exposes a specific set of capabilities, such as access to files, databases, APIs, developer tools, SaaS applications, or internal systems. Some servers may run locally on the same machine as the host, while others may run remotely over a network. This allows the host to assemble an environment where different sources of context and action can be added or removed without changing the core AI application.

2. The Client and Server Initialize a Session

After the host creates a client connection, the MCP client and server perform an initialization exchange. This step establishes the session, confirms compatible protocol versions, and allows both sides to declare the features they support. The server may indicate that it supports tools, resources, prompts, notifications, or other capabilities, while the client may declare the capabilities it can handle on behalf of the host.

This initialization step is important because MCP is designed to be stateful. The client needs to understand what the server can do before requesting context or invoking actions. If the client and server cannot agree on compatible protocol behavior, the connection does not proceed. When initialization succeeds, the host can register that server as available for future AI workflows.

3. The Client Discovers Available Capabilities

Once the session is initialized, the MCP client can discover the capabilities exposed by the server. For example, it may request a list of available tools, resources, or prompts. The server responds with structured metadata, such as tool names, descriptions, input schemas, available resource identifiers, or reusable prompt templates.

This discovery process allows the AI application to build a current view of what each connected server can provide. Instead of hardcoding every possible tool or data source, the host can register available capabilities from multiple servers. If a server’s capabilities change later, notifications can help the client refresh its view and keep the AI application aligned with the current server state.

4. The AI Application Uses External Context

During a user interaction, the AI application can use the discovered MCP capabilities to retrieve context or perform actions. For example, it might read a resource, apply a reusable prompt, or invoke a tool with structured arguments. The host routes the request through the relevant MCP client, which sends the appropriate message to the MCP server.

This step turns external systems into usable context for the model. A server might provide current data from a database, documentation from a repository, issue details from a ticketing system, or the ability to perform a task through an API. The model does not need direct access to every external system; it relies on the host and MCP clients to mediate requests through the protocol.

5. The Server Returns Results to the Host

After receiving a request, the MCP server processes it and returns a structured response to the client. The response may include text, resource data, tool output, status information, errors, or other content that the host can pass back into the AI workflow. The host can then make the result available to the language model so it can continue the conversation, explain the result, or decide on the next action.

This request-response cycle can repeat throughout the session. The AI application may call multiple tools, retrieve several resources, or combine information from several MCP servers. Because the server responses are structured, the host can manage them consistently, audit activity more easily, and control how external context is introduced into the model’s interaction flow.

MCP Design Best Practices 

Start with a Clear MCP Server Inventory

Organizations should maintain a clear inventory of every MCP server connected to their AI environment. The inventory should document what each server does, which host applications can access it, whether it runs locally or remotely, what data sources it connects to, and which tools, resources, or prompts it exposes.

A strong inventory should also include ownership, environment, authentication method, permission model, data sensitivity, and operational status. Teams should know which servers are experimental, production-ready, internet-facing, internally hosted, or connected to regulated systems.

Use Least-Privilege Access for Every Server

Each MCP server should be granted only the access it needs to perform its intended function. Since MCP servers may expose sensitive resources or executable tools, broad permissions can create unnecessary risk. A server that only needs to retrieve documentation should not have write access to repositories, administrative APIs, customer records, or production systems.

Least privilege should apply at multiple levels: the server’s credentials, the user’s delegated permissions, the tools exposed to the host, and the actions allowed during a specific session. For remote MCP servers, authorization controls can limit access to sensitive resources and operations, while local servers should avoid relying on overly powerful environment credentials.

Separate Read-Only and Write-Capable Tools

Read-only and write-capable capabilities should be separated wherever possible. Read-only tools and resources provide context, such as files, documentation, logs, database records, or application metadata. Write-capable tools perform actions, such as creating tickets, updating records, sending messages, deploying code, changing configurations, or triggering workflows.

For sensitive write actions, organizations should require stronger controls, such as user confirmation, role-based permissions, scoped credentials, approval workflows, and detailed audit logs. A read-only server can often be made broadly available with lower risk, while a write-capable server should be limited to specific users, environments, and approved use cases.

Route Enterprise Traffic Through an MCP Gateway

In enterprise environments, MCP traffic should be routed through a controlled gateway or similar governance layer where possible. An MCP gateway can centralize security, visibility, authentication, authorization, policy enforcement, rate limits, logging, and routing across many hosts and servers.

A gateway can also help standardize how servers are registered, exposed, approved, and monitored. It can enforce which hosts may connect to which servers, which users may invoke specific tools, and which actions require additional approval.

Monitor Tool Calls and Server Responses

Organizations should continuously monitor MCP activity, especially tool calls and server responses. Monitoring should capture which host initiated the request, which server handled it, which tool or resource was used, what parameters were passed, what result came back, whether the action succeeded, and whether any sensitive data was involved.

Monitoring should also look for unusual patterns, such as unexpected tool invocation, repeated failed calls, access to sensitive resources, high-volume requests, abnormal outputs, or write actions outside normal workflows. Server responses should be reviewed for data leakage, unsafe content, errors, and unexpected behavior.

Monitoring MCP and OpenAI Agent Activity with Exabeam

As organizations connect OpenAI models to MCP servers, AI agents become a new class of non-human identity operating inside business systems at machine speed and scale. Exabeam delivers advanced user and entity behavior analytics (UEBA) that uses AI and automation to help security operations teams detect, investigate, and respond to threats involving users, entities, and AI agents through Agent Behavior Analytics (ABA). By baselining what normal behavior looks like and surfacing risky deviations, Exabeam gives teams the visibility needed to govern MCP-enabled OpenAI agents and the workflows they touch.

Key capabilities of Exabeam UEBA:

• AI agent behavior analytics: ABA extends UEBA to AI agents and other non-human identities, adding behavioral visibility, centralized monitoring, and investigation support so analysts can identify suspicious agent activity and respond with better context.
• Risk-based anomaly detection: New-Scale Analytics builds behavioral baselines and uses business context to refine risk scores, identifying subtle changes across users, entities, and non-human identities; when risk meets a set threshold, a case is opened for investigation.
• Entity context: Attack Surface Insights identifies entities in parsed logs and connects attributes and contextual data to build profiles that strengthen behavioral detections across on-premises and cloud environments.
• Automated investigation timelines: Automated timelines organize related detections chronologically to visualize the full scope of a threat, while activity summaries for anomalies and prebuilt playbooks reduce manual routines so teams respond faster.
• Flexible SIEM augmentation or replacement: New-Scale Analytics runs on top of an existing SIEM to add advanced behavioral analytics, while New-Scale Fusion provides a full-featured platform for a new deployment or a SIEM replacement.

Integrating ABA with Praxen and Observra

To secure AI agents, Exabeam combines runtime analytics with open-source frameworks for telemetry and verification. Integrating Agent Behavior Analytics (ABA) with Praxen and Observra creates a comprehensive security lifecycle for autonomous machine identities.

• Standardizing Agent Telemetry with Observra: Active AI agents generate complex, unstructured activity logs. Observra acts as an open-source SDK and logging library that captures runtime agent operations, including model calls, prompt details, tool usage, system costs, and errors. It normalizes this data into a structured event format, providing the consistent telemetry stream required for advanced threat detection.
• Verifying Agent Policies with Praxen: Before an agent is deployed, Praxen serves as an open-source reference implementation for Agent Behavior Verification (ABV). It compares the declared security policy of an AI agent against its actual underlying code, deployment state, and initial behavioral logs. This ensures that discrepancies, logic flaws, or unauthorized capabilities are flagged before the agent enters production.
• Continuous Behavioral Analysis with ABA: During active operations, the ABA engine ingests normalized telemetry from Observra and leverages the policy baselines established by Praxen. The engine applies machine learning models to build behavioral baselines for each agent, scoring risks and flagging real-time anomalies. If an agent drifts from its intended role, calls unapproved tools, or accesses unauthorized data, ABA immediately raises risk scores and triggers alerts.

This combined approach allows security teams to verify AI agent behavior prior to deployment and maintain continuous, baseline-driven visibility throughout active operations.

Exabeam offers a Model Context Protocol (MCP) server for developers that connects AI assistants directly to public API documentation, enabling teams to explore endpoints, analyze request and response schemas, and generate custom integration code through natural language conversation. In parallel, LogRhythm delivers a community-released SIEM MCP server that runs locally in on-premises environments to bridge security telemetry directly with chosen large language models, allowing analysts to run automated threat-hunting queries, triage active incidents, and summarize security alarms while keeping sensitive security logs inside the private.

To see how Exabeam helps security teams monitor and secure human and AI agent activity across the agentic enterprise, explore Exabeam’s UEBA capabilities. Read our MCP for Developers page to learn more on MCP as well.