What Is MCP in AI?

Understanding the Model Context Protocol (MCP)

In artificial intelligence, MCP stands for the Model Context Protocol. Introduced as an open-source standard by Anthropic in November 2024, MCP establishes a universal, standardized communication layer between AI models (such as large language models, or LLMs) and external systems. These external systems include local file systems, databases, software development environments, enterprise business tools, and web APIs.

Before MCP, connecting an AI model to an external data source or execution tool required building custom integration pipelines, writing bespoke API wrappers, or relying on proprietary connector ecosystems. This dynamic created an $M \times N$ complexity problem: every AI assistant or client application ($M$) had to build separate custom integrations for every data source or service ($N$).

MCP solves this fragmentation by functioning as a universal standard—frequently described as the "USB-C port" or the "Language Server Protocol (LSP) for AI." By decoupling the AI client from the underlying data source, any MCP-compliant AI application can seamlessly interact with any MCP-compliant server without requiring custom connector code.

Without MCP (M × N Integrations):
[AI Client A] ─── Custom API ───> [PostgreSQL]
[AI Client A] ─── Custom API ───> [GitHub]
[AI Client B] ─── Custom API ───> [PostgreSQL]
[AI Client B] ─── Custom API ───> [GitHub]

With MCP (M + N Architecture):
[AI Client A] ──┐
                ├─── Standard MCP Protocol ───> [PostgreSQL MCP Server]
[AI Client B] ──┘                             > [GitHub MCP Server]
                                              > [Local File MCP Server]

Architectural Foundations: How MCP Works

The Model Context Protocol relies on a client-server architecture designed around modern web and software integration patterns. It is modeled closely after the Language Server Protocol (LSP), which Microsoft developed to standardize how code editors communicate with programming language compilers and linters.

Core Components of an MCP Ecosystem

An operational MCP environment consists of three primary entities:

1. MCP Host (AI Client Application): The primary user-facing application or agentic runtime that coordinates model interactions. Examples include desktop applications (such as Claude for Desktop), integrated development environments (IDEs like Cursor or VS Code extensions), or custom enterprise AI orchestration frameworks.
2. MCP Client: A protocol-specific adapter embedded inside the host application. The client maintains direct, 1:1 connections with one or more MCP servers, translates model intentions into standard protocol messages, and handles security boundaries.
3. MCP Server: A lightweight, standalone program or service that exposes specific capabilities, data, or tools. A server interfaces directly with an underlying service (such as a SQLite database, a Slack workspace, or an AWS environment) and exposes standard endpoints for the client to discover and invoke.

┌─────────────────────────────────────────────────────────────┐
│                         MCP HOST                            │
│                                                             │
│   ┌──────────────────┐               ┌──────────────────┐   │
│   │   User / UI      │               │ Large Language   │   │
│   │   Interface      │               │ Model (LLM)      │   │
│   └─────────┬────────┘               └─────────▲────────┘   │
│             │                                  │            │
│             ▼                                  │ Context    │
│   ┌────────────────────────────────────────────┴────────┐   │
│   │                     MCP CLIENT                      │   │
│   └───────┬──────────────────────┬──────────────────────┘   │
└───────────┼──────────────────────┼──────────────────────────┘
            │ JSON-RPC             │ JSON-RPC
            ▼ (stdio / SSE)        ▼ (stdio / SSE)
   ┌─────────────────┐    ┌─────────────────┐
   │ MCP SERVER A    │    │ MCP SERVER B    │
   │ (e.g., GitHub)  │    │ (e.g., Postgres)│
   └────────┬────────┘    └────────┬────────┘
            ▼                      ▼
     External System        External Database

Transport Mechanisms

MCP communication is built on the JSON-RPC 2.0 message format, ensuring that messages are lightweight, structured, and language-agnostic. The protocol defines two standard transport mechanisms:

• Standard Input/Output (stdio): Primarily used for local communication. The host application spawns the MCP server as a local child process and exchanges JSON-RPC messages across standard input and output streams. This method is common in desktop setups and developer tools.
• Server-Sent Events (SSE) over HTTP: Used for remote server communication. The client sends commands via standard HTTP POST requests and receives continuous, asynchronous streams of responses and event updates over an SSE connection.

The Three Core Primitives of MCP

To accommodate different types of interaction between models and external environments, the Model Context Protocol formalizes three discrete functional primitives: Resources, Tools, and Prompts.

1. Resources (Data and Read-Only Context)

Resources represent data sources that provide contextual information to the model without causing side effects.

• They are identified using uniform resource identifiers (URIs), such as file:///workspace/project/config.json or postgres://prod-db/schema/users.
• Resources can provide text content (plain text, JSON, code, markdown) or binary content (images, PDFs, documents) encoded in base64.
• Servers can notify clients when a resource changes, enabling real-time context synchronization without polling.

2. Tools (Executable Actions)

Tools allow the model to interact actively with external systems by invoking executable functions.

• Every tool provides an explicit JSON schema defining its name, a natural language description of what it does, and the parameters it requires.
• Tools are designed to be model-controlled: the model decides which tool to call based on the user's prompt, outputs structured JSON arguments, and waits for the MCP server to return the execution result.
• Tools can carry side effects (such as creating records, modifying code, or calling external APIs), making human-in-the-loop permissioning an essential architectural consideration.

3. Prompts (Predefined Interaction Patterns)

Prompts expose pre-configured templates that help users navigate complex tasks.

• An MCP server can publish standardized prompt templates that combine static guidance with dynamic resource injection.
• For example, a Git MCP server might expose a prompt called analyze-commit-history, which accepts a branch name, automatically pulls the relevant git logs via resources, and presents a structured prompt to the model.

JSON-RPC Interaction Lifecycle

To see how an MCP client and server interact, consider a scenario where an AI assistant queries a PostgreSQL database to inspect a table schema.

// 1. Client discovers available tools on startup
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list"
}

// 2. Server responds with tool definitions and argument schemas
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "query_database",
        "description": "Executes a read-only SQL query against the connected database.",
        "inputSchema": {
          "type": "object",
          "properties": {
            "query": {
              "type": "string",
              "description": "The SQL query to execute"
            }
          },
          "required": ["query"]
        }
      }
    ]
  }
}

// 3. Model decides to call the tool; Client issues execution request
{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "query_database",
    "arguments": {
      "query": "SELECT column_name, data_type FROM information_schema.columns WHERE table_name = 'orders';"
    }
  }
}

// 4. Server executes the query and returns structured text
{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "[{\"column_name\": \"order_id\", \"data_type\": \"integer\"}, {\"column_name\": \"total_amount\", \"data_type\": \"numeric\"}]"
      }
    ]
  }
}

This interaction occurs through a standard schema, meaning the client application does not need custom logic specific to PostgreSQL, MySQL, or Snowflake; it handles all tool invocations through the identical tools/call contract.

Technical and Architectural Advantages

The adoption of MCP provides several distinct structural benefits over legacy integration patterns:

1. Decoupling and Modularity

In traditional AI development, connecting an LLM to internal systems meant hardcoding custom tool definitions directly into the application's prompt-engineering or orchestration layer (e.g., via LangChain, LlamaIndex, or proprietary SDKs). If an enterprise wanted to switch from one LLM provider to another, or from a desktop client to a web platform, integrations had to be rebuilt. MCP decouples tool development entirely: developers build and maintain the server once, and any client runtime can consume it.

2. Standardized Security and Isolation

Because local MCP servers typically run as standalone processes via stdio, they execute in an isolated environment outside the AI host application's memory space.

• Granular Access Control: MCP hosts can enforce permission models, requiring explicit human approval before a destructive tool (e.g., delete_file or drop_table) is executed.
• Credential Isolation: API tokens, database passwords, and SSH keys stay inside the specific MCP server process and do not need to be passed directly to the LLM context or the client application runtime.

3. Dynamic Context Management and Context Window Efficiency

Feeding entire codebases or databases directly into an LLM context window is inefficient and expensive. MCP allows applications to dynamically discover and retrieve only the necessary sub-resources and metadata on demand, optimizing token usage and reducing context pollution.

Implementation Example: Building a Basic MCP Server

MCP servers can be implemented in any language that supports standard I/O and JSON serialization. Anthropic maintains official software development kits (SDKs) in TypeScript and Python.

Below is an implementation of a basic MCP server in Python using the official mcp SDK, exposing a custom mathematical calculation tool:

from mcp.server.fastmcp import FastMCP

# Initialize a FastMCP application server
mcp = FastMCP("CalculationEngine")

@mcp.tool()
def compute_compound_interest(principal: float, rate: float, periods: int) -> float:
    """
    Calculates future compound value given principal, interest rate, and periods.
    
    Args:
        principal: The starting monetary amount.
        rate: The interest rate per period (as a decimal, e.g., 0.05 for 5%).
        periods: Number of compounding periods.
    """
    # Formula: A = P * (1 + r)^n
    total_value = principal * ((1 + rate) ** periods)
    return round(total_value, 2)

if __name__ == "__main__":
    # Runs the server using standard input/output transport
    mcp.run(transport="stdio")

When an MCP host launches this server process, the host automatically reads the function signature, docstring, and type hints, converting them into an MCP-compliant JSON schema without requiring manual boilerplate definitions.

Comparison: MCP vs. Related AI Integration Concepts

Understanding where MCP fits within the modern AI software stack requires distinguishing it from other common architectural patterns:

Limitations and Security Considerations

While MCP significantly simplifies AI system integration, deploying it in production and enterprise environments presents several practical challenges:

• Prompt Injection and Tool Misuse: If an MCP server connects an LLM to write-capable tools (e.g., shell command execution or write access to production databases), indirect prompt injection attacks pose a severe risk. Untrusted input ingested via resources could trick the model into issuing unauthorized tool calls.
• Human-in-the-Loop Latency: To mitigate security risks, critical tool invocations typically require manual user confirmation. In highly autonomous agentic workflows, this creates latency bottlenecks and requires careful UI/UX design.
• Network and Process Overhead: Running dozens of independent local MCP servers can consume substantial system resources, as each server operates as an individual runtime process (e.g., Node.js or Python instances).
• Ecosystem Maturity: As an emerging standard, specifications for federated authentication, remote server discovery, and multi-tenant authorization models continue to evolve across open-source working groups. Organizations deploying remote MCP servers over SSE must implement robust reverse proxies, mutual TLS, and OAuth layers to ensure secure transport.

MCP in AI: the Model Context Protocol

In an artificial-intelligence context, MCP almost always stands for Model Context Protocol — an open standard, first published by Anthropic in November 2024, that defines how AI applications (especially those built on large language models) connect to external tools, data sources, and services. Instead of every AI product inventing its own way to reach a database, a file system, a ticketing system, or a SaaS API, MCP specifies a common client–server protocol so that any compliant AI host can talk to any compliant integration.

The frequently used shorthand is that MCP is "a USB-C port for AI applications": one standardized connector on the model side, many interchangeable peripherals on the other. The analogy is imperfect but captures the intent — the protocol is about plumbing and interoperability, not about model intelligence.

A brief note on ambiguity: outside AI, "MCP" also means Microsoft Certified Professional, multi-chip package in semiconductor manufacturing, Master Control Program (the antagonist in Tron, occasionally invoked as a metaphor for a controlling AI), and managed care plan in healthcare. If a document about agents, LLM tooling, or Claude/ChatGPT integrations says MCP, it means the Model Context Protocol.

The problem MCP was designed to solve

Language models are useful mainly when they can see relevant context and act on real systems. Before MCP, connecting a model to the outside world usually meant writing a bespoke integration for each pairing of AI application and external system:

• Each vendor defined its own plugin format, tool schema, and authentication flow.
• A connector written for one chat product could not be reused in an IDE assistant or a custom agent.
• Adding a new data source meant new glue code, new prompt scaffolding, and new maintenance burden.

This is the classic N×M integration problem: with $N$ AI clients and $M$ systems, you risk needing $N \times M$ custom integrations. A shared protocol reduces it toward $N + M$ — each client implements MCP once, each system exposes an MCP server once, and the combinations come for free.

MCP does not replace the model's underlying ability to call functions. It standardizes the layer around that ability: discovery of what is available, description of parameters and results, session management, permissions, and transport.

Architecture: hosts, clients, and servers

MCP uses a deliberately small vocabulary of participants.

A host can hold many client connections at once, each to a different server, and the host is responsible for deciding what the model may see and do. Servers are intentionally narrow: a good MCP server wraps one domain and does not need to know anything about which model or vendor is on the other side.

Communication uses JSON-RPC 2.0 messages over a stateful session. Two standard transports are defined:

• stdio — the server runs as a local subprocess and exchanges messages over standard input/output. Simple, fast, and natural for local tools and developer machines.
• Streamable HTTP — for remote servers reachable over the network, with support for server-initiated messages via server-sent events. This replaced an earlier HTTP + SSE transport, so older documentation and libraries may describe a somewhat different remote setup.

Every session begins with an initialize handshake in which both sides declare a protocol version and negotiate capabilities. That negotiation matters in practice: it is why a server built against one revision of the spec can still work with a client that supports a different feature set, and why hosts can safely ignore features they do not implement.

What an MCP server actually exposes

The protocol organizes functionality into a handful of primitives. Understanding the split between server-side and client-side primitives is the single most useful thing to learn about MCP.

Server-side primitives (what the server offers to the AI application):

• Tools — executable functions the model may call, each with a name, description, and JSON Schema for arguments (and, in later spec revisions, for structured output). Tools are model-controlled: the model decides when to invoke them, subject to host approval. Examples: create_issue, run_query, send_email.
• Resources — readable context identified by URI: files, database rows, log excerpts, documentation. Resources are typically application-controlled; the host or user chooses what to attach, which keeps the model from indiscriminately pulling data.
• Prompts — reusable, parameterized templates or workflows that a user can invoke deliberately, such as a "summarize this pull request" command. These are user-controlled.

Client-side primitives (what the host can offer back to the server):

• Sampling — a server can ask the host to run an LLM completion on its behalf, so servers can use model reasoning without shipping their own API keys or model choice.
• Roots — the client tells the server which directories or URIs are in scope, bounding where a filesystem-style server may operate.
• Elicitation — introduced in a 2025 revision, this lets a server pause and request additional information or confirmation from the user mid-task, rather than guessing or failing.

Supporting mechanics include notifications when a tool or resource list changes, progress reporting for long operations, cancellation, logging, pagination, and completion hints for arguments.

A tool call, stripped to its essentials, looks like ordinary JSON-RPC:

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "search_orders",
    "arguments": { "customer_id": "C-8842", "status": "open" }
  }
}

And a local server is typically registered in a host's configuration file with nothing more than a command and arguments:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/projects"]
    }
  }
}

Official SDKs exist for a range of languages — Python, TypeScript, Java, Kotlin, C#, and Go among them — which handle message framing, schema validation, and transport so that authors mostly write ordinary functions with typed signatures and docstrings.

How MCP relates to neighbouring ideas

MCP is easy to confuse with several adjacent concepts, and precision helps.

• Function/tool calling is a model capability: the ability to emit a structured request to invoke a named function. MCP is the transport and discovery layer that supplies those function definitions dynamically and executes them. You can use tool calling without MCP, and MCP servers ultimately surface as tool calls to the model.
• A plain REST API is designed for programmers, with documentation for humans. An MCP server is designed for a model: self-describing, discoverable at runtime, and packaged with natural-language descriptions of when to use each operation. Many MCP servers are thin wrappers over existing APIs.
• RAG (retrieval-augmented generation) is a pattern for injecting retrieved text into a prompt. MCP can serve retrieval as resources or a search tool, but it is not itself a retrieval method.
• Agent-to-agent protocols (such as Google's A2A) address how autonomous agents delegate to and coordinate with each other. MCP addresses how one agent reaches tools and data. The two are usually described as complementary rather than competing.
• Vendor plugin systems solve a similar problem within one product. MCP's differentiator is that it is not tied to a single model provider.

Governance, adoption, and versioning

Anthropic released MCP as an open specification with open-source SDKs and reference servers. Through 2025 it was adopted well beyond its origin: OpenAI publicly embraced it across developer tooling and desktop products in early 2025, Google indicated support for MCP in its Gemini-related tooling, and Microsoft integrated it into agent and Copilot tooling while co-maintaining an SDK. Large numbers of community and vendor-built servers appeared for databases, browsers, code hosts, observability platforms, and internal enterprise systems.

In late 2025 Anthropic announced it was donating MCP to the Agentic AI Foundation, a new directed fund under the Linux Foundation established with participation from multiple industry players, moving stewardship to a vendor-neutral home. That shift matters for organizations evaluating long-term dependencies, since neutral governance reduces the risk that a single company's commercial interests determine the protocol's direction.

The specification is versioned by date (for example 2024-11-05, 2025-03-26, 2025-06-18, and later revisions), and features have been added and occasionally deprecated between versions. When reading tutorials or debugging incompatibilities, check which spec revision the client and server each target — much of the confusion around remote servers and authorization stems from mixing revisions. Because the protocol is evolving, treat any specific feature list, including the one above, as a snapshot rather than a permanent definition.

Security, trust, and practical limits

MCP's convenience is also its risk surface, and this deserves blunt treatment. Connecting a model to real systems means an untrusted text channel now borders privileged actions.

Widely discussed concerns include:

• Prompt injection and tool poisoning. Instructions hidden in a tool's description, in returned data, or in a fetched document can steer the model into unintended actions. Because tool descriptions are consumed by the model, a malicious server can attempt to manipulate behaviour before any user notices.
• Over-broad permissions. A server given a long-lived token with wide scope effectively grants the model that scope. Least privilege, scoped credentials, and read-only defaults are the standard mitigations.
• Confused-deputy problems. A privileged server that does not properly validate which user or audience a token belongs to can be induced to act on the wrong principal's behalf. Later spec revisions tightened authorization guidance, including treating servers as OAuth resource servers and validating token audience.
• Supply chain and server provenance. Installing a community MCP server is installing and running code. Unmaintained or typosquatted packages are a real hazard.
• Context bloat and tool confusion. Attaching many servers floods the model's context with tool definitions, which can degrade accuracy and raise cost. Curating a small, relevant set usually works better than connecting everything.

The protocol's design places consent and mediation in the host: users are expected to approve tool invocations, review arguments, and control which resources are shared. Whether a given product implements those safeguards well varies considerably, so evaluate the host application, not just the protocol. For deployments touching regulated data, credentials, or customer records, treat MCP integrations as production software subject to normal security review, and involve qualified security and compliance staff rather than relying on general guidance.

Used with those caveats in mind, MCP's practical value is straightforward: it turns integrations into reusable, portable components. An internal server that exposes a company's inventory system can be consumed by a chat assistant today, an IDE plugin next month, and a custom agent after that — without rewriting the connection each time.