What is Model Context Protocol (MCP): Explained

Introduction

Anthropic released MCP (Model Context Protocol) in November 2024. The developer community initially responded positively, yet few realized its full potential.Fast-forward to 2026, and MCP has become the default way to connect AI applications to external tools and data.

This shift became clear when popular consumer IDEs like Cursor, Cline, and Goose officially supported MCP. As more client applications adopted it, server-side integration became increasingly important, amplifying its impact. OpenAI and Google both adopted MCP in 2025, and today thousands of MCP servers exist for everything from GitHub to Slack.

Yet, despite all the hype, many developers still wonder: "What exactly is MCP? Should I care? Is this really the next big thing or just another AI fad?" The confusion is accurate and understandable.

In this article, I'll demystify MCP, clarify its purpose, and unpack why it matters (or doesn’t).

TL;DR

• MCP (Model Context Protocol) is an open protocol that gives AI apps one standard way to connect to external tools and data. Think of it as a USB-C port for AI agents.

• Anthropic released MCP in November 2024. It is now supported by Cursor, Claude, OpenAI, and thousands of servers.

• MCP has three core parts: a host (the AI app), a client (the connector), and a server (the tool or data source).

• An MCP server exposes tools, resources, and prompts that an AI agent can discover and call.

• MCP is not revolutionary by itself. Its value is standardization: build an integration once and connect it anywhere.

Table of Contents

• So, what is MCP?

• Why should you care about MCP?

• Is it revolutionary?

• MCP Architecture

  • Host

  • Client

  • Server

• The "protocol" in MCP

• What MCP looks underneath

  • Messages

  • Transportation Mechanisms

  • Lifecycle Management

• Cursor x Linear lifecycle example

• Drawbacks of MCP

• ComposioMCP

• Frequently Asked Questions on MCP

So, what is MCP?

Model Context Protocol (MCP) is an open protocol that gives AI applications one standard way to connect to external tools and data sources. To make things clearer, it's neither a framework like LangChain nor a tool; it's a protocol similar to HTTP for the web or SMTP for messaging.

A more relevant example could be LSP (Language Server Protocol), which standardizes adding support for programming languages across an ecosystem of development tools. Similarly, MCP standardizes the integration of additional context and tools into the ecosystem of AI applications.

It provides the universal rules that allow any client to communicate with any server, regardless of who built either component, creating a foundation for a diverse and interoperable AI ecosystem. Anthropic defines it as the USB-C port equivalent for agentic systems. It standardizes the connection between AI applications, LLMs, and external data sources (Databases, Gmail, Slack, etc.).

The Machines are the clients, the peripheral devices are tools, and the MCP is the Type-C port. So, it doesn’t matter who makes the device or peripherals; they work together seamlessly.

Image Credit: Norah Sakal

MCP defines how clients should communicate with servers and how servers should handle tools (APIs, Functions, etc.) and resources (read-only files like logs, db records, etc.) More on this later.

Why should you care about MCP?

Benefits of Standardisation

1. Unified Integration: A single protocol for connecting any LLM to any tool

2. Reduced Development Time: Standard patterns for resource access and tool execution

3. Clear Separation of Concerns: Data access (resources) and computation (tools) are cleanly separated

4. Consistent Discovery: Uniform mechanisms for finding available capabilities (tools, resources, prompts, roots, sampling)

5. Cross-Platform Compatibility: Tools built for one system work with others

Is it revolutionary?

Short answer: No.

You can live without MCP. It is not revolutionary but brings standardization to the otherwise chaotic space of agentic development. If your application is MCP client-compliant, you can connect to any MCP client-compliant server. In an alternate world, as a client developer, you must tailor the servers to your needs, and others cannot build for your platform. The same is true for server developers.

For example, with Inside Cursor, you can connect to any MCP server that follows the protocols.

At this point, you will be more or less clear about the purpose of the MCP. Now, let’s clarify what MCP is.

MCP Architecture

The Model Context Protocol has several key components that work together. Here’s a high-level diagram from Matt Pocock on Twitter.

The complete MCP architecture consists of four parts

• Host: Coordinates the overall system and manages LLM interactions

• Clients: Connect hosts to servers with 1:1 relationships

• Servers: Provide specialized capabilities through tools, resources, and prompts

• Base Protocol: Defines how all these components communicate

In production systems with numerous agents and tools, managing these direct connections can introduce security and observability challenges. To address this, developers often use an MCP Gateway as a centralized proxy to enforce policies, monitor traffic, and simplify integration.

In the above chart, the Client and Host are merged; we will keep them separate to clarify things. So, let’s go through each component and understand MCP from within.

1. Host

Hosts are the LLM applications that expect data from servers. Hosts can be an IDE, Chatbot, or any LLM application. They are responsible for

• Initializing and managing multiple clients.

• Client-server lifecycle management

• Handles user authorization decisions

• Manages context aggregation across clients

Examples are Claude Desktop, Cursor IDE, Windsurf IDE, etc.

2. Client

Each client has these key responsibilities:

• Dedicated connections: Each client maintains a one-to-one stateful connection with a single server. This focused relationship ensures clear communication boundaries and security isolation.

• Message routing: Clients handle all bidirectional communication, efficiently routing requests, responses, and notifications between the host and their connected server.

• Capability management: Clients monitor what their connected server can do by maintaining information about available tools, resources (contextual data), and prompt templates.

• Protocol negotiation: During initialization, clients negotiate protocol versions and capabilities, ensuring compatibility between the host and server.

• Subscription management: Clients maintain subscriptions to server resources and handle notification events when those resources change.

3. Server

An MCP server is a program that exposes a set of tools, resources, and prompts to an AI client over MCP. It can run locally on your machine or be hosted remotely. Servers are the fundamental building block that enriches LLMs with external data and context. The key server primitives include:

• The tools are executable functions that allow LLM to interact with external apps. Tools function similarly to functions in traditional LLM calls. A tool can be a POST request to API endpoints; for example, a tool defined as LIST_FILES with a directory name as a parameter will fetch the files in the directory and send them back to the client. The tools can also be API calls to external services like Gmail, Slack, Notion, etc.

• Resources: Read-only data such as text files, log files, database schemas, file contents, and Git history. They provide additional context to the LLMs.

• Prompt Templates: Pre-defined templates or instructions that guide language model interactions.

Tools are model-controlled, while Reosuces and Prompts are user-controlled. The models can automatically discover and invoke tools based on a given context.

The “protocol” in Model Context Protocol

The Protocol forms the foundation of the Model Context Protocol (MCP) architecture. It defines how different components (hosts, clients, and servers) communicate. For more in-depth information, refer to the official MCP Specification.

What MCP looks like underneath

The protocol consists of several key layers

• Protocol Message: Core JSON-RPC message types

• Lifecycle Management: Client-server connection initialization, capability negotiation, and session control

• Transport Mechanisms: How client-servers exchange messages, usually two types, Stdio for local servers and SSE (Server Sent Events) for hosted servers.

• Server Features: Resources, prompts, and tools exposed by servers

• Client Features: Sampling and root directory lists provided by clients.

Out of the above five, the Base protocol, i.e. JSON-RPC message types and Lifecycle management, is crucial for every MCP implementation. Other components may be implemented as per the needs of the specific application.

Key parts of the protocol

1. Messages

At its core, MCP uses JSON-RPC 2.0 as its messaging format, providing a standardized way for clients and servers to communicate. The Base Protocol defines three fundamental message types:

1. Requests: Messages are sent to initiate an operation from client to server and vice versa. Example:

{
  jsonrpc: "2.0";
  id: string | number;
  method: string;
  params?: {
    [key: string]: unknown;
  };
}

1. Responses: Messages sent in reply to requests

{
  jsonrpc: "2.0";
  id: string | number;
  result?: {
    [key: string]: unknown;
  }
  error?: {
    code: number;
    message: string;
    data?: unknown;
  }
}

1. Notifications: One-way messages that don't require a response

{
  jsonrpc: "2.0";
  method: string;
  params?: {
    [key: string]: unknown;
  };
}

2. Transport Mechanisms

The protocol can be implemented over different transport layers depending on deployment needs:

• stdio: Communication over standard input/output streams

  • The client and server receive JSON messages via stdin and respond via stdout

  • Simplifies local process integration and debugging

  • Well-suited for local servers like File, Git server, etc.

• HTTP with Server-Sent Events (SSE):

  • Establishes a bidirectional communication pattern over HTTP

  • The server maintains an SSE connection for pushing messages to clients

  • Clients send commands via standard HTTP POST requests

  • Enables distributed architecture with multiple concurrent clients

  • Better suited for hosted servers.

• Custom transports: Implementations can create additional transport mechanisms as needed

3. Lifecycle Management

The Base Protocol implements a structured lifecycle for connections between clients and servers:

1. Initialization Phase:

   • Clients and servers negotiate protocol versions

   • They exchange capability information (Clients share tools and sampling with servers, and Servers share tools, resources, and prompts with clients).

   • They share implementation details.

2. Operation Phase:

   • Normal protocol communication occurs

   • Both parties respect the negotiated capabilities

3. Shutdown Phase:

   • Graceful termination of the connection

MCP Interaction Lifecycle: Cursor IDE to Linear/Slack Example

Let’s understand what we have learned so far through a simple example. Where

• The host is Cursor IDE

• The servers are Linear and Slack

Here's a detailed workflow of the MCP interaction lifecycle process:

Initialization Phase

1. Connection Establishment: When a user activates the Linear integration in the Cursor IDE, the IDE initiates a connection to the Linear MCP server, typically through stdio or WebSockets.

2. Capability Negotiation:

   • Cursor sends an initialize request containing its capabilities (what features it supports)

   • The Linear server responds with its capabilities (available resources, tools, protocol version)

   • Cursor evaluates compatibility, ensuring both sides support the necessary protocol features

3. Feature Discovery:

   • Cursor requests available tools (tools/list)

   • Linear responds with tools like create_ticket, assign_ticket, add_comment, etc.

4. Ready Notification: The cursor sends a initialized notification to indicate it's ready to begin regular operation.

Operation Phase

1. Tool Execution:

   • The user tells Cursor, "Create a bug ticket for the login page crash"

   • The LLM in Cursor determines it needs to use a tool

   • Cursor sends a tools/call request for create_ticket with appropriate parameters

   • The linear server creates the ticket and returns the result

   • The cursor displays the result to the user

2. Cross-Service Integration:

   • The user says, "Notify the team on Slack about this new ticket."

   • Cursor connects to the Slack MCP server (a separate connection with its own lifecycle)

   • Cursor sends a tools/call request to the Slack server

   • The Slack server posts the message and returns the success

   • Cursor confirms the notification was sent

Maintenance Phase

1. Health Checks:

   • The cursor periodically sends ping requests to ensure the connection is still alive

   • The linear server responds to confirm the availability

Termination Phase

1. Graceful Shutdown:

   • When the user closes the workspace or disables the integration

   • The cursor sends a shutdown Request to the Linear

   • Linear acknowledges with a response

   • The cursor sends an exit notification

   • The linear server releases resources associated with the session

2. Error Recovery:

   • If a connection fails unexpectedly

   • Cursor implements retry logic with exponential backoff

   • Upon successful reconnection, the initialization lifecycle begins again

This standardised lifecycle ensures reliable, predictable interactions between any MCP host and server, regardless of their specific implementations. Whether it's Cursor connecting to Linear for ticket management or Slack for messaging, the same protocol patterns apply, making integrations consistent and interoperable.

Limitations of MCP

1. Authentication and authorization

Early MCP shipped with no standard for auth, and that gap defined the first year of the ecosystem. It has since been addressed: the MCP specification now defines an authorization framework based on OAuth 2.1 for remote servers, covering how a client obtains and presents an access token. The standard is only part of the story, though. It applies mainly to HTTP transports, much of it is optional, and support across the thousands of community servers is uneven. In practice you still meet servers with hand-rolled auth, missing token refresh, and inconsistent scopes, which becomes a real security and reliability problem the moment agents act on production systems. That is why teams put a central control plane between their agents and tools to manage credentials, enforce policy, and audit every call, a role an MCP Gateway fills.

2. Server quality and reliability

MCP's ecosystem has grown fast, but quality is uneven. Many servers are community side-projects: some lag behind the API they wrap, some break on edge cases, and plenty of important applications still have no official server. For the ones worth your time, we keep a running list of MCP servers every developer should know, and if the one you need does not exist yet, here is how to build your own MCP server.

These production challenges are why an MCP Gateway is becoming essential infrastructure for managing security, observability, and governance between agents and tools. To learn how to evaluate different options, see our guide to the best MCP gateways for developers.

Composio MCP: Managed MCP servers with built-in Auth

Composio MCP solves both problems at once. Our managed servers give agents built-in authentication across 1,000+ applications, automatically handling OAuth 2.0, API keys, and JWT tokens, including the token refresh and scope handling that hand-rolled servers usually get wrong. Because Composio builds and maintains the underlying tools itself rather than proxying someone else's server, auth and permissions are enforced at the point the action executes, not bolted on afterwards. We ship pre-built, agent-ready servers for services like Linear, Slack, GitHub, Salesforce, and Google Workspace, so you focus on building the agent, not the plumbing.

This eliminates the challenge of maintaining your own MCP servers and handling complex authentication flows. It is suitable for integrating apps with gated resource access.

Frequently Asked Questions on MCP

1. How is MCP different from Langchain or any other framework?

   LangChain is a framework, while MCP is a protocol. With a framework you risk vendor lock-in; that is not the case with a protocol. As long as you follow the protocol guidelines, you will be fine. Even LangChain can adopt MCP as a standard for building stateful agents.

2. How are MCP servers different from tool calling?

   Isn’t it easier to call tools directly instead of jumping through hoops? Yes, but a protocol ensures that developers define and call tools uniformly, making it easier to develop both clients(host apps) and servers (integrations).

3. Managing LLM contexts is not that difficult, so why a protocol?

   Again, the goal is to reduce as much developmental overhead as possible. For example, Cursor developers will focus solely on client implementation, while Linear will concentrate on server implementation. As long as both comply with the base protocol standard (which we described in detail), both are good.

4. Is it necessary?

   Yes, to connect your AI assistants with third-party apps for real-world actions, MCP is the easiest and most convenient way to do it.

5. How is MCP different from an API?

   An API is how two pieces of software talk to each other. MCP is a standard layer on top that describes those APIs to an AI agent in a consistent way, so the agent can discover and call any tool without custom code per integration. You still use APIs underneath; MCP just makes them agent-readable.

   Is an MCP server a real server?

   It can be either. An MCP server is any program that exposes tools, resources, and prompts over MCP. It can run locally on your machine over stdio, or be hosted remotely over HTTP, so "server" describes the role it plays, not necessarily a remote machine.

   Does ChatGPT use MCP?

   Yes. OpenAI added MCP support in 2025, so ChatGPT and the OpenAI Agents SDK can connect to MCP servers. Anthropic's Claude, Cursor, and many other clients support it too, which is what makes MCP a shared standard rather than one vendor's feature.