​
Introduction

The Model Context Protocol (MCP) is an open protocol that standardizes how AI applications (especially those using large language models) connect to external data sources and tools (Model Context Protocol Specification). In simpler terms, think of MCP as a sort of “USB-C port” for AI applications – just as USB-C provides a universal way to plug in peripherals, MCP provides a universal way for AI models to plug into different data sources, tools, and contexts (Introduction - Model Context Protocol). This protocol aims to cut through the fragmentation and ad-hoc solutions in the AI industry by offering a common language for integration between AI systems and the rich context they often need.

Why is this needed? Today’s AI models often require access to external information (like documents, databases, or web APIs) and the ability to perform actions (like running computations or calling services). Without a standard, each AI application or vendor creates its own custom integrations – leading to duplicated effort and inconsistent security. MCP addresses this by defining a consistent, interoperable interface.

For AI developers, MCP offers a detailed specification (with JSON-based APIs and message flows) to integrate tools and data seamlessly into LLM apps. For technology leaders (CXOs), MCP promises greater flexibility (plug-and-play components), reduced vendor lock-in, and improved governance over how AI systems access sensitive data and operations. This article provides a comprehensive breakdown of the MCP 2025-03-26 specification – explaining its architecture, key features (with example JSON snippets), and the real-world significance of this emerging standard.

​
Why MCP Matters

Modern AI applications—whether an AI coding assistant, a customer support chatbot, or a business analytics agent—frequently need to incorporate external context or perform actions. MCP is designed to make these integrations easier, safer, and more standardized. Some key benefits of MCP include:

  • Plug-and-Play Integrations: MCP defines a growing list of standardized capabilities (for example, file access, web search, code execution as “tools,” etc.) that an AI application can support. This means AI apps can “plug in” pre-built integrations for common needs instead of reinventing them (Introduction - Model Context Protocol). If an MCP-compliant server provides access to, say, a Git repository or a database, any MCP-enabled AI client can use it out of the box.

  • Model-Agnostic and Flexible: MCP is model-neutral – it doesn’t depend on any specific AI model or vendor. The protocol sits above the AI model, so you can swap out the underlying LLM (OpenAI, Anthropic, Google, local models, etc.) without breaking the integrations (Introduction - Model Context Protocol). This gives organizations flexibility to switch model providers or use multiple models, since MCP handles context injection in a consistent way regardless of how the model is implemented.

  • Security and Data Control: With MCP, data stays within your control. The protocol emphasizes that users must consent to any data access or tool usage (Model Context Protocol specification – Model Context Protocol Specification) (Model Context Protocol specification – Model Context Protocol Specification). An MCP host (the AI application) can enforce strict boundaries on what an AI assistant can see or do. For example, the host can limit file access to specific directories and require user approval before any tool (function) is executed. This means AI features can be integrated in enterprise settings without compromising compliance, since data never leaves the approved scope and all actions can be logged and gated.

  • Ecosystem and Interoperability: MCP took inspiration from the success of the Language Server Protocol (LSP) in developer tools (Model Context Protocol specification – Model Context Protocol Specification). Before LSP, each IDE had to implement each programming language support separately; with LSP, a language server can work with any LSP-compliant editor. Similarly, MCP promises an ecosystem where “MCP servers” (services providing data or tools) can work with any “MCP client” (AI application). This interoperability could accelerate innovation: for instance, third parties might develop MCP servers for common tasks (search, calendars, CRM data, etc.), which any AI app could easily adopt.

In short, MCP is poised to standardize AI integrations much like USB standardized device connections or LSP standardized language tooling. Now let’s dive into how MCP actually works, from the high-level architecture down to the message formats and features.

​
MCP Architecture and Core Concepts

(image) High-level architecture of the Model Context Protocol. An AI Host application contains multiple Clients, each maintaining a connection to an external Server that provides specific context or capabilities. Servers may run locally (accessing local resources like files or databases) or remotely (accessing cloud services or APIs), but the Host orchestrates all interactions.

At a high level, MCP follows a client-server architecture with three main roles (Model Context Protocol specification – Model Context Protocol Specification):

  • Host: The host is the AI application or platform that is using the language model. For example, this could be a desktop IDE with an AI assistant, a chat application, or a web-based AI platform. The host process contains the AI model and the user interface, and it is responsible for overall coordination. The host acts as a container and orchestrator for MCP connections (Architecture – Model Context Protocol Specification):

    • It spawns and manages one or more Clients (one per external integration).
    • It controls the lifecycle of those connections (start/stop).
    • It enforces security policies and obtains user consent when needed.
    • It often is the component that actually invokes the LLM and may combine responses from multiple sources.

  • Server: A server is an external service or module providing some context or capability. Servers are typically lightweight programs (which could be local processes or remote web services) that expose certain functionality via MCP. Examples of servers: a “filesystem” server that exposes files and folders, a “database” server that can run queries, or a “tools” server that provides functions like calculators or API calls (Architecture – Model Context Protocol Specification). Each server focuses on a specific domain or capability. Key traits of servers:

    • They expose data or actions via the MCP protocol (for instance, serving up documents, or executing a tool).
    • They operate independently – you can have one server for files, another for web APIs, etc., each running in isolation for modularity (Architecture – Model Context Protocol Specification).
    • They never get full access to the entire conversation or application state – they only see what the host sends them. This isolation is intentional: an MCP server does not automatically see the user’s whole prompt or other servers’ data (Architecture – Model Context Protocol Specification).
    • A server can be local (running on the user’s machine, perhaps packaged with the app) or remote (a cloud service). Either way, it communicates with the client over a channel (e.g., IPC, WebSocket, HTTP).

  • Client: In MCP terminology, the client is a component that lives inside the host process and acts as a bridge between the host and a server (Model Context Protocol specification – Model Context Protocol Specification) (Architecture – Model Context Protocol Specification). If the host connects to three servers, it will create three client instances (as illustrated in the diagram). Each client is responsible for one server connection. Responsibilities of a client include:

    • Maintaining a persistent, stateful session with its server (often over JSON-RPC). This includes performing the initial handshake and keeping the connection alive.
    • Protocol translation and routing: The client sends requests from the host to the server and vice versa, essentially relaying messages. It ensures messages conform to MCP and routes responses back.
    • Isolating servers from each other: Because each client-server pair is separate, a bug or malicious behavior in one server can be sandboxed (it can’t directly affect other connections or read their data) (Architecture – Model Context Protocol Specification).
    • Capability negotiation: During initialization, the client helps negotiate what features the server and host will use (more on this soon).
    • The client is akin to a driver or connector inside the host that knows how to speak MCP with the server.

Interaction model: The host spawns clients, each client connects to a server. The host (and ultimately the user/AI model) can then send requests to servers via clients, and servers can respond or send their own requests back if appropriate. All communication is done through a well-defined protocol (JSON-RPC in this case) which we’ll detail next. This decoupled design means you can add or remove integrations simply by starting or stopping clients/servers, and the host doesn’t need to hardcode knowledge of how each integration works internally – it just adheres to the MCP spec.

​
Design Principles of MCP

The MCP architecture was guided by a few key design principles (Architecture – Model Context Protocol Specification) (Architecture – Model Context Protocol Specification) worth noting, as they clarify why things are structured this way:

  • Ease of implementation: Servers should be simple to build and focused. The heavy lifting (orchestration, combining model responses, complex UI, etc.) is done by the host. A server can be a small script or microservice that just exposes, say, a set of files or a particular API. This lowers the barrier to create new integrations.

  • Composability: Because each server provides a focused capability and communicates via a shared protocol, you can mix and match servers in one application. For example, an AI IDE could run a Files server, a Git server, and a StackOverflow Q&A server simultaneously, and the host can incorporate all their capabilities. The protocol makes sure these work in concert without conflict (Architecture – Model Context Protocol Specification).

  • Isolation and security: MCP explicitly prevents servers from snooping on each other or on information they shouldn’t have. A server sees only the data relevant to its function. For instance, a “Weather API” tool server doesn’t automatically get to read your files, and a “Files” server doesn’t see what web APIs you’re calling. The host mediates all data flow. This principle of least privilege is important for security – it limits the impact if one component is compromised and ensures a malicious or buggy server can’t read arbitrary user data (Architecture – Model Context Protocol Specification). Also, the LLM does not directly see or talk to the servers; it must go through the host, which can filter and control what’s happening.

  • Negotiable and Extensible: MCP is built to be extensible. Not every server or client will support every feature in the spec – they only declare what they support. New features can be added in future versions, and if both sides support them, they can use them; if not, they fall back gracefully. This negotiation (done during initialization) allows MCP to evolve over time without breaking older implementations (Architecture – Model Context Protocol Specification). The 2025-03-26 spec is backward-compatible with earlier revisions, and the protocol version negotiation ensures a client/server can agree on using the latest version both understand (Lifecycle – Model Context Protocol Specification).

Now that we have the high-level picture, let’s look at how MCP communication works in practice: the base protocol mechanics, message format, and lifecycle (connection handshake and teardown).

​
Base Protocol and Communication (JSON-RPC 2.0)

At its core, MCP communication adheres to the JSON-RPC 2.0 standard (Model Context Protocol specification – Model Context Protocol Specification). JSON-RPC is a lightweight remote procedure call protocol using JSON messages. MCP essentially defines a specific set of JSON-RPC methods and usage patterns for our context integration needs. This choice means we get a well-understood, language-agnostic message format with support for requests, responses, errors, and notifications.

​
Message Types

All MCP messages are JSON objects following JSON-RPC 2.0. The three fundamental message types are:

  • Request: A call to perform an operation (e.g., “list resources”, “execute this tool”). A request has a method name and optional parameters. Either side (client or server) can send requests to the other. Every request has an id (unique per sender) so that replies can be matched to the request. MCP follows JSON-RPC’s rule that an id can be a string or number, but it must not be null (Base Protocol – Model Context Protocol Specification). Example request format:

    {
  "jsonrpc": "2.0",
  "id": 42,
  "method": "some/operation",
  "params": { /* ... */ }
}

    Here id: 42 could be any unique identifier for this message. MCP requires that IDs are unique per session and not re-used.

  • Response: A reply to a request. It carries the same id as the request and either a result (on success) or an error (if the operation failed) (Base Protocol – Model Context Protocol Specification). The structure looks like:

    {
  "jsonrpc": "2.0",
  "id": 42,
  "result": { /* ... result data ... */ }
}

    or in case of an error:

    {
  "jsonrpc": "2.0",
  "id": 42,
  "error": {
    "code": 123,
    "message": "Error description",
    "data": { /* optional additional info */ }
  }
}

    MCP uses standard JSON-RPC error codes where possible (e.g., -32601 for “method not found”) but also allows domain-specific errors via the code and message. Either a result or an error must be present, never both (Base Protocol – Model Context Protocol Specification).

  • Notification: A one-way message that does not expect a response (Base Protocol – Model Context Protocol Specification). In JSON-RPC this is just like a request but without an id. Notifications are useful for events or updates – for example, a server might notify the client that a data source changed. Format:

    {
  "jsonrpc": "2.0",
  "method": "event/name",
  "params": { /* ... */ }
}

    The lack of an id signals that no reply is needed (and none should be sent).

MCP supports batching of multiple messages in a single payload (JSON-RPC allows sending an array of messages in one go). MCP implementations may send batches, but at minimum they must handle receiving batches (Base Protocol – Model Context Protocol Specification). In practice, batching might be used for efficiency if, say, a client needs to request a bunch of things at once at startup.

​
Connection and Transports

MCP is transport-agnostic. What this means is the JSON-RPC messages can be sent over different underlying channels depending on the scenario. Common transports include:

  • In-Process (function calls or pipes): If the server is launched as a subprocess of the host (for example, a local binary implementing MCP), they might communicate via standard I/O streams (stdin/stdout) or an in-memory pipe. This is similar to how Language Server Protocol often uses stdio for local language servers.

  • WebSocket or TCP Socket: For scenarios where client and server are separate processes (local or remote) that can maintain a persistent socket connection. MCP’s stateful request/response fits well with WebSockets.

  • HTTP: JSON-RPC can also be used over HTTP(S) as a series of POST requests. The MCP spec provides an authorization scheme specifically for HTTP transports (e.g., using headers for API keys or tokens) (Base Protocol – Model Context Protocol Specification). In an HTTP setup, the client might POST requests to a server’s endpoint and the server responds synchronously, or they may use long-polling/webhooks for server-initiated calls.

MCP doesn’t mandate a specific transport, but it defines how to use each one for consistency (What are MCP Servers And Why It Changes Everything). For example, STDIO transport should not use the HTTP auth scheme (since there’s no HTTP headers) (Base Protocol – Model Context Protocol Specification). The flexibility in transport means MCP servers can run in various environments – a server could be packaged inside an app for offline use or hosted as a cloud service – as long as both sides agree on how to talk.

Connections are stateful and long-lived. A client typically establishes a connection to the server and keeps it open as long as needed (which could be the entire app session). This allows ongoing back-and-forth (like receiving notifications at any time, or streaming results, etc., though streaming is handled via incremental notifications or chunks in this protocol).

​
Initialization Handshake (Capability Negotiation)

Before any meaningful work happens, client and server perform an initial handshake to ensure they speak the same protocol version and to negotiate features. This is done with a special initialize request at the start of a session (Lifecycle – Model Context Protocol Specification) (Lifecycle – Model Context Protocol Specification).

Client Initialization: The client initiates by sending method: "initialize" with a payload that includes:

For example, an initialize request from client might look like:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-03-26",
    "capabilities": {
      "roots": { "listChanged": true },
      "sampling": {}
    },
    "clientInfo": { "name": "ExampleClient", "version": "1.0.0" }
  }
}

Here the client says: “I speak protocol version 2025-03-26 (which is the date of this spec version). I support the roots feature (and I will send notifications if my root list changes), and I support the sampling feature. My application name is ExampleClient 1.0.0.” Notice each capability can have its own object value – for roots it specified a sub-feature listChanged: true (meaning it can notify on changes), whereas sampling has no sub-options so it’s just {}.

Note: The protocol version is given as a date string. MCP uses date-based versioning for the spec. If the server doesn’t support the client’s version, it can respond with an older/newer version it does support. Both sides will try to pick the latest common version (Lifecycle – Model Context Protocol Specification). This ensures forward/backward compatibility as the protocol evolves.

Server Response: The server must respond to initialize with its own capabilities and info, or an error if it cannot proceed. A successful response might be:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-03-26",
    "capabilities": {
      "logging": {},
      "prompts": { "listChanged": true },
      "resources": { "subscribe": true, "listChanged": true },
      "tools": { "listChanged": true }
    },
    "serverInfo": { "name": "ExampleServer", "version": "1.0.0" }
  }
}

In this example, the server agrees on version 2025-03-26 and declares that it supports several Server Features: it has logging capabilities (meaning it can send log messages), it supports prompts (with dynamic prompt list change notifications), resources (with support for subscription and change notifications), and tools. We’ll explain those features in a moment – importantly, the server is telling the client which categories of functionality it provides. The client can now know, for instance, that this server can provide contextual Resources, so the client may later invoke resource-related methods. Conversely, if a capability is not listed, the client should not try to use those methods. MCP stipulates that both sides should only use features that were advertised and agreed upon during init (Lifecycle – Model Context Protocol Specification).

After this exchange, the client sends a quick confirmation (notifications/initialized) to signal it’s ready (Lifecycle – Model Context Protocol Specification). At this point, the session is fully set up with a known set of capabilities. The stage is set to start actually using the features – e.g., listing available resources, calling tools, etc., depending on what was negotiated.

​
Lifecycle and Session Management

Beyond initialization, the MCP spec covers other lifecycle aspects:

  • Regular operation: After init, either side can send requests/notifications as needed, within the scope of the negotiated features. The connection is considered “running”. The host’s LLM can now interact with the server through the client by generating requests or responding to server requests.

  • Ping/Pong: MCP defines a simple heartbeat mechanism (ping request) that either side can use to check liveness (Architecture – Model Context Protocol Specification) (Architecture – Model Context Protocol Specification). The other side responds with a basic acknowledgment (often just the same message ID back or a simple “pong”). This helps to keep connections alive or detect dropped connections in long-lived sessions.

  • Progress Updates: If the server is doing a lengthy operation (say, reading a huge file or performing a long query), it can send progress notifications to update the client on how far along it is (Architecture – Model Context Protocol Specification) (for example 50% done). This is an optional utility, but it improves the user experience by allowing the host to show a progress bar or spinner.

  • Cancellation: MCP allows requests to be canceled. If a user decides to abort an operation, the client can send a cancellation notification referencing the request ID to tell the server to stop processing if possible (Architecture – Model Context Protocol Specification). Not every operation can be canceled cleanly, but for those that can (like a search query), this prevents wasted effort.

  • Shutdown: Either side can terminate the session when done. Usually the client (host) will send a shutdown or simply close the connection when the user is done or the app is closing. The spec outlines that servers should release resources on shutdown and clients should handle unexpected disconnects gracefully (e.g., if a server crashes, the client should catch the socket closure). There’s also an exit notification in some cases to acknowledge a graceful termination.

In summary, the base protocol defines how the two sides talk (JSON-RPC structure, connection start/stop, keep-alives, error handling). On top of this foundation, MCP defines a set of features – specific categories of functionality that can be used once the connection is established. We saw a hint of those in the capabilities (prompts, resources, tools, etc.). Next, we’ll go through each major feature, explaining what it does and using examples to illustrate how a client and server actually use them.

​
Server Features: Providing Data and Capabilities to the AI

Server features are the heart of MCP’s usefulness – they define what a server can do for the AI host. The MCP spec groups core server-provided functionality into three main categories (Model Context Protocol specification – Model Context Protocol Specification):

  • Resources: Supplying data (documents, files, database info, etc.) as context.
  • Prompts: Supplying prompt templates or predefined conversational workflows.
  • Tools: Supplying executable actions/functions the AI can invoke (often called “tools” or “skills” or “plugins” in other contexts).

A single MCP server may implement one or more of these feature sets. For example, a “documentation server” might implement the Resources feature to let the AI browse documents, whereas an “API server” might implement Tools for the AI to call external APIs. Each feature comes with its own set of JSON-RPC methods and expected behaviors, which are standardized by the spec.

Let’s go through them one by one, with examples.

​
Resources: External Data as Context

The Resources feature is how an MCP server can expose raw data or documents that an AI might use as context (Resources – Model Context Protocol Specification). Think of resources as pieces of information (like files, knowledge base articles, database entries, etc.) that the AI could read or reference when formulating its response.

Use cases: An AI coding assistant might use resources to fetch the content of source code files. A customer support bot might use resources to retrieve relevant FAQ answers or policy documents. Resources are read-only from the AI’s perspective (at least in the current spec) – they’re about providing context, not necessarily editing data.

Key points about resources in MCP:

  • Each resource has a URI to identify it (Resources – Model Context Protocol Specification). Commonly these are file URIs (file://path/to/file) for filesystem resources. But a resource could also be something like db://customers/123 for a database record, etc., depending on the server. The spec doesn’t hardcode the URI schemes beyond recommending use of standard URI formats and providing some guidelines for typical ones (file, http, etc.) (Resources – Model Context Protocol Specification) (Resources – Model Context Protocol Specification).

  • Discoverability: The client (AI host) can ask the server, “What resources do you have?” via resources/list. The server then returns a list of resources with metadata. This might include name, description, MIME type, etc. Optionally results can be paginated if there are many resources.

  • Retrieval: The client can request the content of a specific resource via resources/read, providing the URI. The server will respond with the content (could be text, maybe binary data encoded in base64 if needed, plus a MIME type). Large content might be chunked or paginated, but typically read returns the whole content if feasible.

  • Dynamic updates: Some servers might have resources that appear or disappear or change (for example, a new file is added, or a record is updated externally). MCP allows servers to notify the client of such changes with a resources/list_changed notification (Resources – Model Context Protocol Specification). Also, a client can subscribe to a particular resource to be actively notified if that resource’s content updates (Resources – Model Context Protocol Specification) (Resources – Model Context Protocol Specification). For instance, an AI IDE could subscribe to a file so that if the user edits it, the server sends a notification and the AI knows to reload that context.

Now let’s see a concrete example of using the Resources API. Suppose the server indicated it supports resources in the handshake. The client (host) might do the following:

1. Listing available resources (e.g., show me what files or data you have):

Client sends:

{
  "jsonrpc": "2.0",
  "id": 101,
  "method": "resources/list",
  "params": {
    "cursor": null
  }
}

Here cursor is used for pagination – on first request it’s null or not provided to get the first page (Resources – Model Context Protocol Specification). The server responds with something like:

{
  "jsonrpc": "2.0",
  "id": 101,
  "result": {
    "resources": [
      {
        "uri": "file:///project/src/main.rs",
        "name": "main.rs",
        "description": "Primary application entry point",
        "mimeType": "text/x-rust"
      }
    ],
    "nextCursor": null
  }
}

In this example, the server listed one resource – a Rust source file main.rs – with a URI pointing to it and some metadata (a human-friendly name and a MIME type). If nextCursor was non-null, it would indicate there are more resources and the client could call resources/list again with that cursor to get the next page (Resources – Model Context Protocol Specification) (Resources – Model Context Protocol Specification). Here nextCursor is null meaning that was the only result or the end of the list.

2. Reading a resource’s content: Now the client (or the AI, via the client) wants to actually get the content of main.rs:

Client sends:

{
  "jsonrpc": "2.0",
  "id": 102,
  "method": "resources/read",
  "params": { "uri": "file:///project/src/main.rs" }
}

Server responds:

{
  "jsonrpc": "2.0",
  "id": 102,
  "result": {
    "contents": [
      {
        "uri": "file:///project/src/main.rs",
        "mimeType": "text/x-rust",
        "text": "fn main() {\n    println!(\"Hello world!\");\n}"
      }
    ]
  }
}

The server returned the file content (in this case as a text string in Rust code). The contents array is used presumably in case multiple related resources were fetched (for example, if the URI was a folder? But in this spec, likely read returns an array to allow returning multiple parts if needed). The important part is the text field containing the actual file text. An AI code assistant could now feed this into the LLM’s context so the model can analyze or reference it.

3. Handling updates: If the user edits that file on disk (outside the AI perhaps), the server could inform the client:

{
  "jsonrpc": "2.0",
  "method": "notifications/resources/updated",
  "params": {
    "uri": "file:///project/src/main.rs"
  }
}

This is a notification (no id) telling that main.rs changed (Resources – Model Context Protocol Specification). The host might then, if it cares, call resources/read again to get the new content, or if it was subscribed, it might automatically get new content through a subscription mechanism. MCP supports a resources/subscribe request to start getting such updated notifications for a particular URI (Resources – Model Context Protocol Specification).

Resource Templates: As an advanced feature, MCP allows servers to define resource templates – essentially parameterized resource URIs. For example, a server might not list every file in a large filesystem (which could be thousands), but it could declare a template like file:///{path} meaning “I can serve any file if you provide the path.” The client can then use the completion API (see Utilities) to auto-complete available paths. The resources/templates/list method lets the client retrieve such templates (Resources – Model Context Protocol Specification) (Resources – Model Context Protocol Specification). This is a more advanced detail; the main idea is that resources can either be explicitly listed or implicitly defined via patterns.

To summarize Resources: it’s a standardized way for the AI to browse and fetch data from the server. MCP ensures the interface is uniform – listing and reading are done with the same JSON structure whether the resource is a file, a database entry, or something else. The host application can present these resources in a UI (e.g., a file explorer or search interface) for the user to pick from, or automatically include certain resources (like “open the current document”). The spec leaves the UI aspect flexible (Resources – Model Context Protocol Specification) – some apps might expose resources via a tree view, others via search, etc., but MCP will support them under the hood.

​
Prompts: Predefined Prompt Templates and Workflows

The Prompts feature allows a server to offer pre-made prompt templates or conversational flows that the user (or AI) can invoke as needed (Prompts – Model Context Protocol Specification). Essentially, these are like canned prompts or commands that can help users interact with the AI more effectively.

Think of prompts feature as a way to encapsulate “prompt engineering” on the server side and make it reusable. For example, a server might have a prompt called "code_review" that, when invoked, will instruct the AI to review a piece of code. Or a prompt "daily_summary" that triggers a workflow to summarize daily updates.

Key aspects of the Prompts feature:

  • Prompts are user-triggered in concept. The spec emphasizes that prompts are meant to be explicitly selected by the user (like picking a command from a menu or typing a slash-command) (Prompts – Model Context Protocol Specification). This is in contrast to tools (next section) which are usually AI-triggered. So prompts are typically surfaced in the UI for the user to choose when they want a certain action from the AI.

  • Each prompt has a name, a description (for the user to understand what it does), and an optional list of arguments it accepts (Prompts – Model Context Protocol Specification). Arguments are like parameters the user can fill in. For example, a "code_review" prompt might take an argument "code" which is the code snippet to review. Arguments can be required or optional and have descriptions of their own.

  • The client can list available prompts via prompts/list, similar to resources/tools listing. The server returns a list of prompt definitions (name, description, argument schema) (Prompts – Model Context Protocol Specification) (Prompts – Model Context Protocol Specification).

  • The client can retrieve the full content of a prompt (essentially the actual message template) via prompts/get, providing the prompt name and any arguments. The server then responds with the actual messages that should be inserted into the conversation (Prompts – Model Context Protocol Specification) (Prompts – Model Context Protocol Specification). Typically, the result might include one or more message objects, for example a user message that contains a formatted prompt incorporating the arguments.

  • Prompts can change over time (maybe the server fetches new ones from somewhere or has context-dependent prompts), so there is an optional prompts/list_changed notification like with resources/tools to let the client know the set of available prompts was updated (Prompts – Model Context Protocol Specification).

Example: Let’s use the "code_review" idea.

Server’s capability (advertised in init) for prompts might be:

"prompts": { "listChanged": true }

meaning it supports prompts and will notify if new prompts come in (Prompts – Model Context Protocol Specification) (Prompts – Model Context Protocol Specification).

1. Listing prompts:

Client sends:

{
  "jsonrpc": "2.0",
  "id": 201,
  "method": "prompts/list",
  "params": {}
}

Server responds:

{
  "jsonrpc": "2.0",
  "id": 201,
  "result": {
    "prompts": [
      {
        "name": "code_review",
        "description": "Asks the LLM to analyze code quality and suggest improvements",
        "arguments": [
          {
            "name": "code",
            "description": "The code to review",
            "required": true
          }
        ]
      }
    ]
  }
}

Here we see one prompt listed: code_review. It expects one argument "code". The description tells the user what it does. The client (host) might use this to populate a UI, such as enabling a /code_review slash command that the user can invoke and paste code into.

2. Getting/executing a prompt:

When the user decides to use this prompt (e.g., they type /code_review and provide the code), the host will call prompts/get to fetch the actual prompt content. It passes the prompt name and the arguments filled in:

Client sends:

{
  "jsonrpc": "2.0",
  "id": 202,
  "method": "prompts/get",
  "params": {
    "name": "code_review",
    "arguments": {
      "code": "def hello():\n    print('world')"
    }
  }
}

Server responds with something like:

{
  "jsonrpc": "2.0",
  "id": 202,
  "result": {
    "description": "Code review prompt",
    "messages": [
      {
        "role": "user",
        "content": {
          "type": "text",
          "text": "Please review this Python code:\n```python\ndef hello():\n    print('world')\n```"
        }
      }
    ]
  }
}

This indicates that to fulfill the code_review request, the server is providing a user message that says: “Please review this Python code:” followed by the code block. The host would take this messages array and inject those into the conversation with the AI model (most likely right before calling the LLM for a completion). In this case, it’s a single user message. Some prompts might include multiple messages – e.g., a system message with certain instructions plus a user message – to set up a particular conversational context. The role field (user/assistant/system) aligns with typical chat model roles.

The host can then display the AI’s output as the result of that prompt invocation. Essentially, the prompt server has packaged a complex instruction so the user doesn’t have to write it from scratch each time.

Where do prompts come from? That depends on the server implementation. A server could have static prompt templates defined, or it could generate them dynamically (even via another LLM), or fetch from a database. From the protocol perspective, it doesn’t matter – the server just serves them on request.

This feature is very useful for creating guided user experiences and ensuring consistent phrasing for common tasks. It also allows non-developers (prompt designers) to update how an AI performs tasks by editing the prompt templates on the server side, without changing the host application.

​
Tools: Letting the AI Take Actions

Perhaps the most powerful feature of MCP is Tools – this is how a server can expose actions or functions that the AI can invoke autonomously (with user oversight) (Tools – Model Context Protocol Specification). If you’ve heard of AI “plugins” or “function calling” in some LLM APIs, Tools in MCP serve a similar purpose: they allow the AI to go beyond text and actually perform operations like querying a database, calling an API, doing math, or any custom function, in a controlled way.

Key characteristics of Tools:

  • Tools are defined by a name and a JSON schema for inputs (and implicitly outputs) (Tools – Model Context Protocol Specification) (Tools – Model Context Protocol Specification). The server advertises what tools it has, each with what input arguments it expects (using JSON Schema format for structure and types). The description of the tool explains to the human (and perhaps to the AI) what the tool does.

  • Tools are generally meant to be invoked by the AI model as needed. The spec calls this “model-controlled” (Tools – Model Context Protocol Specification). In practice, this means the AI (host) will decide during a conversation if a tool should be used to fulfill the user’s request. For instance, if the user asks “What’s the weather in New York?”, the AI might decide to call a get_weather tool rather than guessing. The host then actually calls the tool via MCP and returns the result to the model to continue the conversation.

  • User consent & safety: Since tools can do arbitrary things (including potentially destructive actions or data-sensitive queries), MCP strongly advises that a human user should be in the loop to approve tool usage (Tools – Model Context Protocol Specification) (Tools – Model Context Protocol Specification). The UI should make it clear when the AI is attempting to use a tool and allow the user to confirm or deny it. For example, the AI might say (internally) “I need to use the delete_file tool on X”, and the application would prompt the user “Allow AI to delete file X using tool Y?” before proceeding. This prevents misuse or mistakes, and keeps the user aware of what the AI is doing.

  • Tools can change availability, so as with others, a tools/list_changed notification exists if the server’s tool set updates (imagine plugging in a new plugin at runtime) (Tools – Model Context Protocol Specification).

Tool invocation flow: There is an important interplay between the AI model and the MCP messages. A typical flow in an AI agent scenario would be:

  1. The server provides a list of tools (with names, descriptions, schemas) to the client.
  2. The host somehow conveys these tool possibilities to the AI model. (This might be done by formatting the system prompt to list available tools and how to call them, or using a specialized model feature like OpenAI’s function calling interface to inject tool definitions.)
  3. During the conversation, the model decides to use a tool – it produces an output (could be a special token sequence or a JSON indicating tool name and arguments).
  4. The host receives that and translates it into an MCP tools/call request to the server.
  5. The server executes the tool and returns the result.
  6. The host feeds the result back to the model, which then continues and eventually responds to the user.

MCP itself defines step 4 and 5 clearly (the JSON-RPC calls); steps 2 and 6 (how the AI is prompted and how results are inserted) are left to the host’s integration logic, since different LLMs have different ways to handle function calling.

Let’s see a concrete example with a simple tool:

Suppose a server offers a tool to get weather info. It might declare a tool like:

  • name: "get_weather"
  • description: "Get current weather information for a location"
  • inputSchema: a JSON Schema requiring a location string.

1. Listing tools:

Client asks:

{
  "jsonrpc": "2.0",
  "id": 301,
  "method": "tools/list",
  "params": {}
}

Server replies:

{
  "jsonrpc": "2.0",
  "id": 301,
  "result": {
    "tools": [
      {
        "name": "get_weather",
        "description": "Get current weather information for a location",
        "inputSchema": {
          "type": "object",
          "properties": {
            "location": {
              "type": "string",
              "description": "City name or zip code"
            }
          },
          "required": ["location"]
        }
      }
    ]
  }
}

This tells the client (and the host AI) that there is a tool called get_weather which expects one argument "location" (string). The host would make sure the model knows this tool is available. For instance, the host might inject into the system prompt: “You have access to a tool get_weather(location: string) which $.”

2. AI chooses to call the tool: Say the user asks: “What’s the weather in New York today?” The AI model decides it should use get_weather. The host interprets the model’s output and then performs the actual call:

Client sends:

{
  "jsonrpc": "2.0",
  "id": 302,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "location": "New York" }
  }
}

On receiving this, the server will execute the get_weather function (perhaps it calls an external weather API or database) and return the result. Let’s say the result is a piece of text or data:

Server responds:

{
  "jsonrpc": "2.0",
  "id": 302,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Current weather in New York:\nTemperature: 72°F\nConditions: Partly cloudy"
      }
    ],
    "isError": false
  }
}

The result contains a content array – here just one item of type text with the weather info. MCP allows tool results to include not just text but also binary data (images, audio) or even Deep Research to resources (Tools – Model Context Protocol Specification) (Tools – Model Context Protocol Specification). For example, a tool could return an image by including { "type": "image", "data": "<base64>", "mimeType": "image/png" } in the content array (Tools – Model Context Protocol Specification). Or it could return a reference to a resource (like a URI to some file it generated) using type "resource" (Tools – Model Context Protocol Specification). In our case, the weather info is just text, marked with isError: false to indicate the tool succeeded.

The host would take this content and present it to the user or feed it back into the AI. Likely, the AI’s response to the user would now incorporate “It’s partly cloudy and 72°F in New York.” If the AI had a multi-step reasoning, it might first call the tool, get this, then continue generating an answer.

Error handling in tools: If the tool failed (maybe the city was not found, or an API error), the server can respond with isError: true in the result (and possibly include an error message as content) (Tools – Model Context Protocol Specification). Additionally, if the client calls a tool that doesn’t exist or passes invalid args, the server could return a JSON-RPC error (like code -32602 for invalid params).

Security with tools: The host should verify that any tool call is allowed. For instance, if the AI somehow tries to call a tool that was not declared (shouldn’t happen if the model is only told about available ones) or tries something off-policy, the host can refuse. The server side might also have its own restrictions (maybe not executing certain dangerous actions depending on context). The MCP spec notes that clients must treat tool metadata (like the descriptions) as untrusted unless the server is trusted (Tools – Model Context Protocol Specification) – meaning a malicious server could claim a tool is harmless in its description but do something else, so if you’re using community-provided servers, the host app should ideally have a trust system.

Human in the loop: As mentioned, even though the AI initiates tool calls, the user interface should confirm. So in our weather example, the app might have auto-approved because getting weather is benign, or perhaps it popped up “The AI wants to use Get Weather tool with location ‘New York’. Allow?” If user denies, the host could send an error back to the AI or pretend the tool returned no result.

In essence, Tools turn the AI from just a text predictor into an agent that can act – but within boundaries set by the available tools and the user’s permission. This feature dramatically extends what AI assistants can do (e.g., book appointments, control smart devices, retrieve real-time info), all through a standardized interface. MCP provides the plumbing for this in a way that’s model-agnostic and secure.

​
Recap of Server Features

To recap the server-driven features:

  • Resources – provide data context (files, docs, etc.) that the AI can read. The AI/host explicitly pulls these in as needed. Good for background info or knowledge base retrieval.

  • Prompts – provide templates and workflows that users can trigger for common tasks. These help standardize interactions and save time by injecting pre-written prompt content.

  • Tools – provide actions/functions that the AI can invoke (with permission) to perform tasks or fetch dynamic information. These empower the AI to influence the world or query complex systems.

A single MCP server could implement just one or multiple of these features. For example, a complex server might have both resources and tools (maybe a Git server that both provides repository files as resources and also a tool to run Git commands). The MCP protocol is modular: the client will only use the methods for whichever features were negotiated.

Now, aside from server features, MCP also defines some client-side features and general utilities that complement the above. We’ll touch on those next.

​
Client Features: Exposing Client Capabilities to Servers

While servers mostly provide data and actions to the host, there are a couple of things that flow in the opposite direction – features that clients (hosts) can provide to servers. In the 2025 spec, the key client-driven features are Roots and Sampling (Model Context Protocol specification – Model Context Protocol Specification).

These allow servers to query some information or service from the client side. Let’s see what each does.

​
Roots: Defining Allowed Filesystem Scope

“Roots” refers to filesystem root directories that the host is willing to expose to the server (Roots – Model Context Protocol Specification). This feature exists mainly for security and organization. Essentially, the client can tell the server: “Here are the directories you are allowed to know about and access.” The server can then request the list of roots and adjust its behavior accordingly.

In practice, Roots are used to define the workspace or project folder the user is working with. For example, in an IDE, the root might be the project directory. In a multi-root workspace, there could be several root folders. By communicating this, the server (say a resource server) knows where in the filesystem it should operate (and not wander outside).

How it works:

  • If a client supports roots, it will list a roots capability in the init. (Servers can check for it.)
  • The server can call roots/list at any time to get the current set of root directories the host has configured (Roots – Model Context Protocol Specification).
  • The client responds with an array of root entries, each with a URI (likely file:///...) and an optional name (Roots – Model Context Protocol Specification).
  • If the user changes the roots (e.g., opens a different folder, or adds another workspace folder), the client will send notifications/roots/list_changed to the server (Roots – Model Context Protocol Specification), and the server can call list again to get the new set.

Example:

Client advertises roots in capabilities:

"roots": { "listChanged": true }

Meaning it will notify on changes (Roots – Model Context Protocol Specification).

Server (or even client, but typically server-driven) requests roots:

{
  "jsonrpc": "2.0",
  "id": 401,
  "method": "roots/list"
}

Client responds:

{
  "jsonrpc": "2.0",
  "id": 401,
  "result": {
    "roots": [
      {
        "uri": "file:///home/user/projects/MyApp",
        "name": "MyApp"
      }
    ]
  }
}

So, the root directory is /home/user/projects/MyApp. The server now knows it should, for example, only serve files from under this directory. If the user later changes to a different project, the client would send:

{ "jsonrpc": "2.0", "method": "notifications/roots/list_changed" }

and then the server can call roots/list again to get the new root(s) (Roots – Model Context Protocol Specification).

From a security perspective, roots are important. They prevent a naive server (especially one that accesses a filesystem) from going out of bounds. The client must ensure that it only reports directories that the user approves. The spec emphasizes validation (no .. path traversal etc.) (Roots – Model Context Protocol Specification). If a server tries to read a file outside the provided roots, the client or server should error out.

For an enterprise CXO, this feature is a reassurance: if you deploy an AI with access to company files, you can confine it to specific shares or folders, and not worry that it will randomly access the whole disk.

For completeness: The spec defines the Root data type as just a URI and optional name (Roots – Model Context Protocol Specification). The current spec restricts URI to file:// scheme for roots, since it’s about filesystem directories (Roots – Model Context Protocol Specification).

​
Sampling: Server-Initiated LLM Requests (Agentic AI)

Sampling is a fascinating feature: it lets the server ask the client to invoke the language model. In other words, the usual flow is user -> AI -> possibly calls to server. But with sampling, the server can turn around and ask the AI a question (via the client). This enables recursive or agentic behaviors where a tool or resource server can utilize the AI model to accomplish its own sub-tasks (Sampling – Model Context Protocol Specification) (Sampling – Model Context Protocol Specification).

Why would we want this? Imagine a scenario where a tool server is doing something complex and might benefit from the AI’s reasoning or language understanding mid-process. For example, a database tool might retrieve some data but want the AI to summarize it or extract insights. Or a multi-step workflow might involve the AI making a decision, then continuing. Sampling allows the server to essentially “call the model” via the host, treating the AI as another resource.

However, since the server is external, this raises trust concerns. The server shouldn’t just be allowed to query the AI arbitrarily (it could spam the model or extract info). Therefore, sampling is designed with strict controls:

This way, a malicious or overly inquisitive server can’t stealthily use the AI to get data it shouldn’t see – the user will know exactly what question is being asked and what answer was given.

From an API standpoint, the server calls sampling/createMessage to request the host generate a new AI message (Sampling – Model Context Protocol Specification) (Sampling – Model Context Protocol Specification). The parameters include:

  • A set of messages (like a conversation context that the server wants the model to consider). For example, the server might provide a user query or some system instruction here.
  • modelPDeep Research: The server can suggest what kind of model or what priorities to use (more on that in a second).
  • Optionally a systemPrompt to use, and maxTokens, etc., similar to typical AI generation parameters (Sampling – Model Context Protocol Specification) (Sampling – Model Context Protocol Specification).

The client (host) will then do the actual call to the model. It might use its own API (OpenAI, Anthropic, local model, etc.) to generate a completion given those messages. The result is sent back in the response as a message (role: assistant or system depending on what was asked for).

Let’s illustrate with an example: Suppose we have a tool server that can do web searches. The server might want to use the LLM to summarize search results for the user. The flow could be:

  • User asks a question.
  • AI (in host) decides to use the search tool (calls tools/call).
  • The search tool server gets some results from the web (text).
  • Now the server wants to summarize those results. Instead of implementing a summarization algorithm itself, it can ask the AI to do it by calling sampling/createMessage with the search results as context.
  • The host asks user “Allow the Search server to query the model with this prompt to summarize results?” User says yes.
  • Host runs the model, gets summary, returns it to server.
  • Server then gives that summary back to the AI as the tool’s output (or maybe directly to user).

In JSON terms, a sampling request might look like:

Server sends:

{
  "jsonrpc": "2.0",
  "id": 501,
  "method": "sampling/createMessage",
  "params": {
    "messages": [
      {
        "role": "user",
        "content": { "type": "text", "text": "What is the capital of France?" }
      }
    ],
    "modelPDeep Research": {
      "hints": [ { "name": "claude" } ],
      "speedPriority": 0.5,
      "intelligencePriority": 0.8
    },
    "systemPrompt": "You are a helpful assistant.",
    "maxTokens": 100
  }
}

This is a simple case: the server basically asks the AI “What is the capital of France?” (Maybe trivial, but imagine it’s part of a bigger flow). It also provides some model pDeep Research: in this case a hint suggesting it would like a Claude model and indicating it values intelligence 0.8 vs speed 0.5 (so lean towards accuracy over speed, for example). The modelPDeep Research is MCP’s way of letting the server express if it wants a fast answer, a cheap answer, or a high-quality answer, without assuming a specific model name (Sampling – Model Context Protocol Specification). The host will map these to an actual model it has. The hint "claude" might match to Claude v2 if available, or it might map to some equivalent if not. (The example in the spec shows how hints and priorities can be combined to guide model selection (Sampling – Model Context Protocol Specification).)

Now, when the client receives this request:

  • It likely shows the user a prompt: “Server X wants the model to respond to: ‘What is the capital of France?’. Approve?” If the user approves, the host calls its model.
  • The host uses the provided system prompt and messages to get a result, up to 100 tokens.

Say the host’s model (indeed using Claude or whatever) returns: “The capital of France is Paris.” The client then replies to the server:

{
  "jsonrpc": "2.0",
  "id": 501,
  "result": {
    "role": "assistant",
    "content": { "type": "text", "text": "The capital of France is Paris." },
    "model": "claude-3.0", 
    "stopReason": "stop"
  }
}

It includes the content, and possibly which model was ultimately used and why it stopped (finished naturally or was cut off) (Sampling – Model Context Protocol Specification).

The server now got an answer using the AI, without the server itself having an API key or direct access to an AI model. This is powerful: it means even a third-party server could leverage the user’s own AI model through MCP. For example, an open-source community might provide an MCP server for some domain logic and rely on the user’s AI setup to do the heavy AI work, thus not incurring their own AI compute costs or needing keys. From a security perspective, note how the user had to approve the prompt and response (Sampling – Model Context Protocol Specification) (Sampling – Model Context Protocol Specification), ensuring nothing sneaky happened. The spec strongly recommends all sampling requests be user-approved and that users can even edit the prompt if needed (Sampling – Model Context Protocol Specification) (Sampling – Model Context Protocol Specification).

Model pDeep Research mechanism: A quick elaboration: MCP’s model preference system acknowledges that a server might not know what models the client has. Instead of just asking “use GPT-4”, it provides hints and priority sliders (Sampling – Model Context Protocol Specification) (Sampling – Model Context Protocol Specification):

  • The intelligencePriority, speedPriority, and costPriority are values 0.0–1.0 indicating what the server cares about. For instance, a value of 0.9 for speed and 0.1 for intelligence would mean “I prefer a fast result even if it’s not the most intelligent”. The client can map that to choosing a smaller model or shorter context.
  • hints are substrings of model names; e.g. hint “gpt-4” or “claude” or “llama2”. The client will try to use a model that matches these if possible, or an equivalent one. Multiple hints in order allow fallback choices (Sampling – Model Context Protocol Specification).
  • The final decision is the client’s: it will pick a model it has access to that best fits these criteria (Sampling – Model Context Protocol Specification) (Sampling – Model Context Protocol Specification). The server does not get to demand a specific provider – this maintains the host’s control (important for cost management and policy).

Sampling essentially turns the tables in a controlled way: the server becomes the “user” asking the AI something, and the real user gets to oversee this. This feature is crucial for implementing complex agent systems or when a tool action inherently requires language processing (e.g., summarizing something, composing text, reasoning about data).

​
Cross-Cutting Utilities and Other Features

Beyond the major features above, MCP includes some additional utilities and conventions to smooth out the integration experience:

  • Logging: MCP servers can send log messages to the client using a standardized logging interface. If a server has the logging capability, it might emit logs (info, warnings, errors) via notifications. This helps the host or the end-user see what the server is doing behind the scenes (useful for debugging or audit trails). For example, after performing a tool action, a server might log “Called external API X, got result Y”. The host could display this in a debug console.

  • Pagination: We’ve touched on this – any list operation (resources, prompts, tools, etc.) can support pagination. The use of cursor and nextCursor in list requests/responses (Resources – Model Context Protocol Specification) (Resources – Model Context Protocol Specification) is the standard way MCP handles large sets. Servers that have potentially many items implement a scheme where the client sends back the last cursor it got to get the next chunk. This avoids overwhelming the client or network with huge lists.

  • Completion (Argument Auto-Completion): The Completion utility (not to be confused with text completion of the LLM) refers to assisting the user in filling out arguments or inputs for other features. For instance, if a prompt has an argument “database_table”, a server might support suggesting possible table names as the user types. MCP’s completion API allows the client to ask the server for suggestions for a given partial input. This is analogous to IDEs auto-completing code or command-line tools auto-completing file paths. In MCP, completion is used for things like completing resource template parameters or prompt arguments (Resources – Model Context Protocol Specification) (Prompts – Model Context Protocol Specification). If a server supports it, the host can make the UI more user-friendly by offering drop-down suggestions coming from the server’s knowledge. (The specification has an entire section on Completion under Server Utilities, where it likens it to IDE code completion (Completion – Model Context Protocol Specification).)

  • Cancellation & Timeouts: We mentioned cancellation. The protocol defines a cancel notification referencing a request ID. If a user cancels an operation or closes a dialog, the client will send cancel to the server so it can stop processing. Both sides should also implement timeouts – e.g., if no response in X seconds, consider the request failed (the spec likely gives guidance on default timeouts for various operations to ensure snappiness).

  • Error Codes and Handling: MCP mostly uses JSON-RPC’s error structure. It defines some common codes (like -32601 for method not found if a feature isn’t supported (Roots – Model Context Protocol Specification), or -32603 for internal errors, etc.). Servers and clients are expected to handle errors gracefully and surface them meaningfully (e.g., if a resource read fails because file not found, server might return an error with code and message, and the host should show the user something like “File not found”).

  • Versioning: The spec version is included in the initialize exchange. The presence of protocolVersion in both request and response ensures both sides agree on the same spec revision (Lifecycle – Model Context Protocol Specification). If not, they attempt to negotiate or fail fast. This mechanism allows MCP to improve over time. For example, the next version might add a new feature, but older clients/servers will simply not advertise it or not agree to a higher version, and thus not use that feature.

  • Extensibility and Experimental Features: MCP has a provision for custom or experimental extensions. The client capabilities include an experimental field where non-standard features can be declared (Lifecycle – Model Context Protocol Specification). This is like a vendor-specific extension mechanism. It helps early adopters to try out new ideas without conflicting with the official spec. Typically such features would be namespaced or clearly documented to avoid collisions. (For a production environment, experimental features might be turned off unless both sides know what they’re doing.)

In summary, MCP doesn’t just define the big ticket features; it also covers all the little things that make an integration robust: how to keep the connection alive, how to paginate data, how to abort if needed, logging for transparency, etc. This reflects that it’s a fairly mature and thought-out spec, despite being new – a lot of lessons from protocols like LSP or from real-world plugin systems have been incorporated.

​
Security and Trust Considerations

Because MCP can provide an AI application with powerful abilities – read arbitrary data, execute code/tools, etc. – security is of paramount importance. The specification dedicates a section to Trust & Safety principles (Model Context Protocol specification – Model Context Protocol Specification). While the protocol itself is just the mechanism, it’s crucial that implementers enforce certain rules to keep users safe and in control.

The key security principles include (Model Context Protocol specification – Model Context Protocol Specification) (Model Context Protocol specification – Model Context Protocol Specification):

  1. User Consent and Control: The user should always be in the driver’s seat. MCP is designed such that any potentially sensitive action (accessing private data, invoking a potentially dangerous tool, the server requesting a new LLM query via sampling, etc.) can and should be confirmed by the user (Model Context Protocol specification – Model Context Protocol Specification). The host application should provide clear UI prompts for the user to authorize actions. For example, before a server reads a file, maybe the user had to select that file (implicit consent). Before a tool executes, the user should click “Allow”. This ensures nothing covert happens.

  2. Least Privilege (Data Privacy): Servers should not get data they don’t need. The host should only expose the necessary data to each server (Model Context Protocol specification – Model Context Protocol Specification). For instance, if a server is meant to work only within a specific folder (Roots help enforce this), it shouldn’t be given access to anything else. If a server doesn’t need the conversation history, don’t send it. In fact, MCP’s design that servers don’t see the whole chat history by default is deliberate (Architecture – Model Context Protocol Specification) – they only see what the host explicitly sends (like a piece of user query if needed for a tool, or a file path to read). This mitigates the risk of a malicious server siphoning info or a bug leaking info across integrations.

  3. Tool Safety: Tools essentially run code or make external changes, so they are high risk. The spec suggests that tool descriptions (the metadata from server about what a tool does) should be treated as untrusted unless the server is known to be trustworthy (Tools – Model Context Protocol Specification). This is because you don’t want to blindly trust a tool that says “deletes a file” actually does only that – a malicious server could label something innocuous but do something else. Therefore, hosts might have allow-lists of servers or manual code review for servers installed. Also, as mentioned, explicit user approval before any tool execution is a must (Tools – Model Context Protocol Specification) (Tools – Model Context Protocol Specification). An AI should not silently execute a tool without user knowing.

  4. LLM Request Mediation: In the sampling feature, the protocol intentionally limits what the server can see and do. The server doesn’t get direct access to call the model – it has to request through the client, and the client can veto or modify the prompt (Sampling – Model Context Protocol Specification) (Sampling – Model Context Protocol Specification). The server also does not automatically see what the user originally asked the AI (unless the host decides to include that in the sampling messages). This is to prevent a situation where a server could abuse sampling to spy on the conversation or ask the AI for something the user didn’t intend.

  5. Auditing and Logging: While not explicitly a protocol requirement, the ecosystem encourages logging every action (the logging feature can help with this). This means keeping an audit trail of what was accessed and what tools were run (AI Model Context Protocol (MCP) and Security - Cisco Community). If something does go wrong, developers or IT admins can trace back through logs of MCP communications to see what happened.

  6. Authentication & Authorization of Servers: If a server is remote (HTTP transport), it may require authentication (API keys, OAuth tokens, etc.) which MCP can carry via its HTTP Authorization framework (Base Protocol – Model Context Protocol Specification). Hosts should securely manage these credentials (never hard-code, allow user to revoke, etc.). Also, not every server should necessarily be allowed to connect – a host might have a list of approved servers it will launch or connect to. Conversely, a server might restrict which clients can connect (though more likely the client initiates, so client-side control is more relevant).

In implementation guidelines, the spec basically urges developers to bake in security from day one (Model Context Protocol specification – Model Context Protocol Specification) (Model Context Protocol specification – Model Context Protocol Specification). Provide settings for what a user consents to. Document what an integration will do. Follow best practices like principle of least privilege, sanitizing any data (for example, if a server returns text that will be shown to user, ensure it’s escaped properly to avoid UI injection issues).

One nice thing about MCP’s design is that it centralizes integration through the host, which becomes a chokepoint for security enforcement (AI Model Context Protocol (MCP) and Security - Cisco Community). An organization can focus on hardening the host application since that’s where decisions are made (which servers to allow, what data to share, etc.). If the host is well-behaved, it can compensate even if a server is not fully trusted by simply not giving it opportunities to misbehave.

Real-world security example: Suppose an enterprise uses an MCP server that connects to an internal HR database (as resources). The host (AI app) would ensure:

  • The server only sees the HR data it’s supposed to (perhaps by running it with certain credentials).
  • The user explicitly requests any HR info (no server just pushing data to AI).
  • All queries are logged (“User X requested resource Y at time Z”).
  • If the AI tries to call a tool like “email this data to someone”, the user must confirm.
  • If the server tries sampling (maybe it wants the AI to summarize a long HR report), the user again confirms the prompt and the summary.

By following these, even sensitive data can be handled more safely.

​
Real-World Applications and Impact

MCP’s standardized approach unlocks a variety of compelling use cases and simplifies the architecture of AI-augmented applications. Let’s explore a few concrete scenarios to understand how MCP might be applied:

  • AI-Powered IDE (Coding Assistant): Imagine an integrated development environment (IDE) with an AI assistant (like GitHub Copilot or Replit Ghostwriter, etc.). Using MCP, the IDE can spin up:

    • a Files server (Resources feature) that exposes the project’s source code files and maybe documentation to the AI,
    • a Git server (could provide Tools like run_git_commit or resources like commit history),
    • perhaps a StackOverflow Q&A server that has prompt templates for common coding questions. The AI assistant (host) can then, within the same conversation with the developer, fetch relevant file contents (resources/read the code file in question), run git operations (through a tool call), or insert a predefined prompt like a code refactor suggestion. All of this without hardcoding those capabilities into the AI plugin – they come from modular MCP servers. As the IDE developer, you can enable/disable certain servers based on user preference (e.g., turn off internet-accessing ones for offline work or for policy reasons). The result is a highly extensible AI assistant that could support new languages or tools simply by adding new MCP servers, rather than retraining the AI or writing new custom integration code.

  • Enterprise Knowledge Assistant: Consider an enterprise chatbot that can answer questions for employees by pulling from internal documents (wikis, PDFs, SharePoint, etc.) and also performing tasks like creating support tickets. MCP would allow a combination of:

    • a Document Retrieval server (Resources) connected to an indexed repository of company documents,
    • a Prompt server with templates like “Give me a summary of X” or “Steps to file an IT ticket” to guide the AI’s interactions,
    • a Tools server integrated with internal APIs (for example, a tool create_ticket(title, description) to open a support ticket in the internal system). When an employee asks a question, the AI can search for relevant docs via the resource server (with the user’s permission), perhaps use a prompt template to format the answer, and if asked, even execute actions like creating a ticket via the tool server. Crucially, because it’s all standard, the company could choose the AI model provider separately (maybe use an on-prem LLM for confidentiality) and switch it later if needed, without changing how these integrations work.

  • Multi-Agent Systems: MCP could facilitate complex workflows where multiple AI agents or systems collaborate. For example, one could design a system where:

    • One server provides a scheduling tool,
    • Another server provides an email-sending tool,
    • Another provides access to a CRM database,
    • They all connect to a central AI orchestrator (the host). The AI agent might use the scheduling tool to find a meeting time, then use the email tool to send out invites, then log it in the CRM – a chain of actions. Each tool is an independent server module that could be reused in other contexts too. MCP ensures that as long as the host knows about these tools, the AI can leverage them sequentially in one unified conversation/plan. It’s very much like how human assistants use multiple apps to get a job done, but here the AI uses multiple MCP servers.

  • End-user Customization and Ecosystem: In the long run, if MCP gains adoption, we might see a marketplace or library of MCP servers. Users could download or enable servers for specific needs. For example, a finance analyst could add an “Excel Server” that allows the AI to read data from spreadsheets (resource) or run financial models (tools). A doctor could have a “Medical Knowledge Server” for accessing medical texts, and a “Patient Records Server” for their clinic’s database (ensuring privacy and logging via MCP’s controls), enabling an AI assistant to help with patient questions or even draft reports. The AI application doesn’t need to natively know anything about medicine or Excel – it just knows how to communicate via MCP, and those servers encapsulate the domain logic.

From a strategic perspective (for CXOs and decision-makers):

  • MCP can reduce development costs for AI features. Instead of building one-off integrations for each project, teams can build or obtain MCP-compliant servers and reuse them across applications. It fosters a plug-in architecture for AI.
  • It can also accelerate time-to-market. Want your chatbot to have web browsing? If there’s an MCP server for web search, just plug it in. Without MCP, you’d integrate an API, write custom code to parse results, figure out how to feed to the model, etc. With MCP, much of that is standardized.
  • Vendor neutrality and future-proofing: Because MCP is open and model-agnostic, adopting it means you’re not locked into a single AI vendor’s way of doing plugins. For example, OpenAI has their plugins and tools system, Microsoft has the Semantic Kernel, etc., but MCP could act as a lingua franca. If the industry coalesces around MCP, you could switch your backend from one LLM to another, or run multiple, and all your context connections still work. This decoupling is attractive for avoiding being beholden to a single provider’s ecosystem.
  • Community and innovation: By lowering the barrier to create integrations (just implement a JSON API according to spec), more players can contribute. Perhaps domain experts who aren’t AI experts can offer an MCP server with their data/service, and AI developers worldwide can consume it. This sharing can lead to a rich ecosystem more rapidly, similar to how the browser extension or VSCode extension ecosystems grew once a stable API was defined.

It’s worth noting that as of the spec date (March 2025), MCP is a new and evolving standard. It has drawn parallels to LSP, and we’ve seen interest from various AI framework developers (the presence of official SDKs in Python, TypeScript, Java, etc., indicates momentum). If it succeeds, MCP could become the de-facto way AI systems interface with external knowledge and tools, much like how HTTP became the standard for web communication.

​
Conclusion

The Model Context Protocol (MCP) specification from March 26, 2025 represents a significant step toward standardizing AI integrations. By providing a clear, interoperable protocol for connecting language models with the world around them, MCP tackles both the developer experience (with well-defined APIs and schemas) and executive concerns (with security, compliance, and flexibility built in).

In this deep dive, we covered how MCP’s architecture separates concerns between host, clients, and servers, enabling modular and secure design. We explored the core features – Resources, Prompts, Tools, Roots, and Sampling – with examples that demonstrate how an AI might list files, retrieve a prompt template, call an external function, restrict file system access, or even delegate a task back to the model itself. We also highlighted the safeguards like user consent workflows and capability negotiation that ensure these powerful features remain under control.

For AI developers, MCP offers a robust framework to build upon – instead of writing bespoke code for each data source or function, you can rely on MCP’s consistent JSON-RPC interface, focus on the unique logic of your service, and immediately make it available to any MCP-compatible app. The inclusion of things like progress updates, cancellations, and logging means the protocol is ready for real-world, user-facing application demands (like showing a loading indicator or debugging issues).

For organizations and decision-makers, adopting an MCP-based approach means interchangeability and future-ready architecture. You can maintain your own secure data stores and let AI apps tap into them through MCP without constantly worrying about how each new AI tool will integrate. It also creates a layer where you can enforce policies (the host as gatekeeper) consistently across all AI interactions with your systems.

MCP is still fresh, and like any standard, its success will depend on adoption. But the problems it addresses are very real in 2025’s AI landscape – where every week brings new tools and plugins in proprietary flavors. A common protocol could align the community and reduce duplication. The spec will likely continue to evolve (version negotiation is built-in), potentially adding more features (e.g., more complex multi-turn interactions, richer media handling, etc.). Yet, its core principles of simplicity, composability, and safety will remain its foundation.

In conclusion, the Model Context Protocol is an ambitious and promising initiative. It bridges the gap between AI models and the rich ecosystem of data and functionality they need to truly be intelligent assistants. By learning from prior art and prioritizing an open, secure approach, MCP could very well become the “universal adapter” that enables AI systems to safely and seamlessly connect to everything – from your local files to the entire internet – in service of helping users. As AI developers and tech leaders, it’s an exciting space to watch (and contribute to, as the spec is open!). By embracing standards like MCP, we can collectively accelerate the development of more powerful, reliable, and trustworthy AI applications.

​
Get Connected, Share, and Other Socials

Share on LinkedIn

Share on X/Twitter

Have thoughts? I'd love to chat!

More about Rahul and Elevate.do

Follow Rahul on LinkedIn

Follow Rahul on Twitter/X