← Back to Nevo Journal
mcps pillar
|Nevo
What Is MCP? The Model Context Protocol Explained

What Is MCP? The Model Context Protocol Explained

Every AI model has the same fundamental limitation: it can only work with the information you put in front of it. Brilliant at reasoning, writing, and analysis -- but if it cannot read your files, query your database, or call your APIs, that brilliance is theoretical.

The Model Context Protocol fixes this.

MCP is an open protocol, created by Anthropic and now governed by the Linux Foundation, that provides a universal standard for connecting AI models to external tools, data sources, and services. It turns a language model from a text generator into an agent that can actually interact with the world.

This guide covers how the protocol works, its architecture, transport layers, real-world use cases, how it compares to previous approaches, and what it means for the future of AI systems.

MCP in One Sentence

The Model Context Protocol (MCP) is a standardized, open protocol that enables AI applications to connect with external data sources, tools, and services through a universal client-server interface built on JSON-RPC 2.0.

Think of it as a USB-C port for AI. Before USB-C, every device had its own proprietary connector. You needed a different cable for every phone, every camera, every peripheral. MCP does for AI integrations what USB-C did for hardware: one standard interface that works everywhere, built by everyone, owned by no one.

Why MCP Exists

Before MCP, connecting an AI model to external tools meant building custom integrations for every combination of model and service. Want Claude to access your GitHub repos? Build a custom integration. Want GPT to query your Postgres database? Build another one. Want Gemini to read your Slack messages? Another integration, another API surface, another maintenance burden.

This created three problems that held back the entire AI agent ecosystem:

The N-times-M Problem

If you have N AI models and M external services, you needed N x M individual integrations. Every model vendor implemented tool calling differently. Every service exposed its API differently. The integration matrix grew quadratically, and maintaining it was a nightmare.

Fragile, Proprietary Connectors

Most integrations were tightly coupled to specific model providers. A tool built for Claude's function calling would not work with GPT's tool use API, even though they accomplished the same thing. Developers were locked into ecosystems, and switching costs were prohibitive.

No Security Standard

Every integration invented its own approach to authentication, authorization, and data access control. There was no shared model for user consent, no standard for capability negotiation, no protocol-level mechanism for limiting what a tool could do. Security was an afterthought bolted on differently each time.

MCP was Anthropic's answer to all three problems. Released in November 2024 as an open specification, it provided a single protocol that any AI application could use to connect with any external service. Within twelve months, it had been adopted by OpenAI, Google, Microsoft, and hundreds of other companies -- a rare instance of competing AI labs agreeing on a shared standard.

How MCP Works: The Architecture

MCP follows a client-host-server architecture with three distinct components.

Hosts

A host is the AI application that the user interacts with -- Claude Desktop, VS Code with Copilot, Cursor, ChatGPT, or any other LLM-powered interface. The host creates and manages client instances, enforces security policies, handles user authorization, and coordinates the AI model's interactions with the outside world. The host is where the conversation lives.

Clients

Each client maintains an isolated connection to exactly one MCP server. A single host runs multiple clients simultaneously -- one connected to a filesystem server, another to a database server, a third to a GitHub server. Each connection is a separate session with its own capability negotiation and security boundaries. Clients cannot see into each other's connections. The host orchestrates across all clients, but each individual connection is sandboxed.

Servers

An MCP server is a lightweight program that exposes specific capabilities -- tools, resources, or prompts -- to the AI model through a client connection. Servers can be local processes or remote services. They are designed to be easy to build: the protocol pushes complexity toward the host, keeping servers simple and focused. A basic MCP server can be built in under fifty lines of code.

The Connection Lifecycle

  1. The host creates a client for each server it wants to connect to.
  2. Each client initiates a session, exchanging capability declarations.
  3. The server announces what it offers (tools, resources, prompts); the client confirms what it supports (sampling, notifications, roots).
  4. During the active session, the model can invoke tools, read resources, and use prompt templates.
  5. Servers can also initiate requests back to the client -- for example, asking the model to generate text as part of a larger workflow.

This bidirectional communication is what makes MCP more powerful than simple function calling.

The Three Primitives: Tools, Resources, and Prompts

MCP servers expose their capabilities through three core primitives. Each serves a different purpose, and understanding the distinction is key to building effective MCP integrations.

Tools

An MCP tool is a function that the AI model can execute. Tools are the action layer -- they let the model do things. Examples: github_create_issue, slack_send_message, database_query, filesystem_write. Tools have typed input schemas (JSON Schema or Zod) and return structured results. The model decides when to invoke them, though the host can require user confirmation for sensitive operations.

Resources

An MCP resource is data that the server makes available for the model to read. Resources are the context layer -- file contents, database schemas, Git repository state, API documentation. They have URIs and MIME types, can be static or dynamic, and support subscriptions so the server can notify the client when data changes. Resources are typically user-controlled or application-controlled.

Prompts

An MCP prompt is a templated message or workflow -- a code review template that includes the diff and guidelines, a bug report template that pulls in logs and error context. Prompts are always user-controlled: the user explicitly selects them.

Why Three Primitives?

Separating tools, resources, and prompts gives fine-grained control over security and authorization. Tools require explicit invocation and can be gated by consent. Resources are passive data. Prompts are user-initiated workflows. This maps cleanly onto different trust levels in production deployments.

Transport Layers: How Clients and Servers Communicate

MCP supports multiple transport mechanisms, each suited to different deployment scenarios.

stdio (Standard Input/Output)

The simplest transport. The client launches the server as a child process and communicates through stdin and stdout. Each JSON-RPC message is a single line of text.

Best for: Local tools running on the same machine. File system access, local database queries, git operations. This is the most common transport for development tools like Claude Code, Cursor, and VS Code extensions.

Advantages: Zero network configuration, instant startup, no authentication needed (the process inherits the user's permissions).

HTTP with Server-Sent Events (SSE)

An HTTP-based transport where the client sends requests via HTTP POST and receives streaming responses through Server-Sent Events. This was the original network transport for MCP.

Note: As of the November 2025 specification update, HTTP+SSE is considered a legacy transport. It still works, but new implementations should prefer Streamable HTTP.

Streamable HTTP

The current recommended transport for remote servers. It uses standard HTTP POST for requests and supports optional streaming via SSE for long-running operations. It can operate statelessly (each request is independent) or maintain sessions through a session ID header.

Best for: Remote MCP servers deployed as web services, multi-client scenarios, and enterprise deployments where servers need to handle many concurrent connections.

Advantages: Works through standard HTTP infrastructure (load balancers, proxies, CDNs), can be deployed as serverless functions, supports horizontal scaling.

Choosing a Transport

The decision is usually straightforward:

  • Building a local tool for developers? Use stdio.
  • Building a remote service that multiple clients will connect to? Use Streamable HTTP.
  • Maintaining an existing HTTP+SSE server? It works, but plan to migrate.

Capability Negotiation and Security

When a client connects to a server, the first exchange is capability negotiation. The server declares what it offers (tools, resources, prompts, subscriptions). The client declares what it supports (sampling, notifications, roots). Both sides respect this contract for the duration of the session -- no surprise capabilities, no runtime failures from mismatched expectations.

MCP's security model rests on four principles:

  1. User consent and control. Users must explicitly approve all data access and tool invocations. The host presents authorization interfaces; the user retains control.
  2. Data privacy. Hosts must obtain consent before exposing data to servers. Resource data is not transmitted elsewhere without approval.
  3. Tool safety. Tools represent arbitrary code execution. Hosts require user confirmation for destructive operations. Tool annotations (readOnlyHint, destructiveHint) inform authorization decisions.
  4. Server isolation. Each server connection is sandboxed. Server A cannot see what Server B is doing. The host aggregates across servers but enforces boundaries between them.

MCP vs. Previous Approaches

MCP built on and improved several earlier approaches:

Function calling (OpenAI, 2023) let developers describe functions in JSON Schema and have the model decide when to call them. Groundbreaking, but limited: definitions consumed prompt tokens, execution happened client-side with no standard protocol, and there was no concept of resources or capability negotiation.

Tool use (Anthropic, 2024) added streaming results and better error handling but remained model-specific without a protocol layer.

Framework tools (LangChain, CrewAI) provided developer convenience but created lock-in. A LangChain tool could not be used in CrewAI without rewriting it.

To understand how MCP differs from traditional APIs, read MCP vs API vs function calling. MCP shifted the question from "how do I connect this model to this tool" to "how do I build a tool that any model can use." The protocol delivers four things previous approaches lacked:

  • Build once, use everywhere. An MCP server works with Claude, GPT, Gemini, Copilot, and any future client.
  • Discovery is built in. Servers announce capabilities. Clients do not need pre-configured definitions.
  • Security is structural. Consent, isolation, and negotiation are protocol-level, not afterthoughts.
  • Composability is the default. Multiple servers connect to one host and work together without modification.

Real-World MCP Examples

Thousands of MCP servers are already in production. For a full comparison of the top-rated servers, see the best MCP servers in 2026. The most impactful categories:

  • Filesystem access. Read, write, search, and navigate local files. Foundational for coding agents.
  • Database queries. Expose schemas, execute SQL, analyze results. A Postgres MCP server turns the model into a database analyst.
  • Version control. GitHub and Git servers expose issue creation, PR review, code search, and branch management -- turning models into development collaborators.
  • Communication platforms. Slack, Discord, and email servers let agents read messages, send responses, and participate in workflows. This is how AI agent systems bridge automated work and human communication.
  • Document search and retrieval. Search engines as MCP servers let models find relevant documents on demand instead of pre-loading everything into context.
  • Browser automation. Playwright and Puppeteer servers let agents navigate websites, fill forms, take screenshots, and interact with web applications.

How Nevo Uses MCP

Nevo is a self-improving AI agent system that coordinates 14 specialized agents. MCP is the connective tissue between those agents and the outside world.

QMD: Local document retrieval. Nevo's most heavily used MCP server is QMD -- a local search engine combining BM25 keyword search with GGUF neural embeddings. Instead of injecting all project documentation into context (100,000+ tokens), agents search QMD on demand and retrieve only what they need. The result: 92-96% token savings with no loss in retrieval quality.

Memory server. An MCP-based memory server provides persistent knowledge storage across sessions -- facts, preferences, and learned patterns accessible through standard tool calls.

In practice, when Nevo receives a task like "build a new API endpoint," the flow is MCP at every stage: the orchestrator searches QMD for existing patterns, retrieves relevant documentation, coding agents write files through filesystem access, quality agents check against codebase context from QMD, and results are stored in the memory server. Without MCP, each interaction would require custom code. With it, they are all standard tool calls through a universal protocol.

Who Should Care About MCP

Developers building agent systems. MCP is the integration layer to standardize on. Build your tools as MCP servers once, and they work with every major AI agent platform.

Teams evaluating AI tools. When comparing types of AI agents, MCP support signals ecosystem maturity. A system that supports MCP can leverage thousands of existing servers. One that does not is locked into its own integration ecosystem.

Enterprise architects. MCP's security model maps well onto enterprise requirements. The protocol's governance under the Linux Foundation through the Agentic AI Foundation (co-founded by Anthropic, Block, and OpenAI, with support from Google, Microsoft, and AWS) provides institutional stability.

Open source contributors. The specification, TypeScript SDK, and Python SDK are all open source. The ecosystem of community-built servers numbers in the thousands. This is the infrastructure layer that AI agents will run on for the next decade.

The MCP Ecosystem in 2026

The adoption numbers tell the story. In November 2024, MCP was an internal Anthropic experiment. By early 2026:

  • OpenAI adopted MCP across its products, including ChatGPT Desktop.
  • Google DeepMind confirmed MCP support in Gemini models.
  • Microsoft announced MCP integration in Windows 11 and across its Copilot products.
  • The Linux Foundation now governs the protocol through the Agentic AI Foundation.
  • Thousands of MCP servers are available, with major deployments at Block, Bloomberg, Amazon, and hundreds of other organizations.

This is not a single company's standard. It is an industry protocol with governance, competing implementations, and a thriving ecosystem. The question is no longer whether to adopt MCP -- it is how to build on it effectively.

Getting Started with MCP

Using Existing MCP Servers

Most AI applications that support MCP let you configure servers in a JSON file:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/directory"]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "your-token" }
    }
  }
}

Each entry specifies the command to launch the server and any environment variables it needs. The host handles the rest.

Building an MCP Server

The TypeScript SDK makes it straightforward:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({ name: "my-mcp-server", version: "1.0.0" });

server.registerTool(
  "greet_user",
  {
    title: "Greet User",
    description: "Returns a personalized greeting",
    inputSchema: { name: z.string().describe("The user's name") }
  },
  async ({ name }) => ({
    content: [{ type: "text", text: `Hello, ${name}!` }]
  })
);

const transport = new StdioServerTransport();
await server.connect(transport);

That is a complete, working MCP server. Launch it, point your AI application at it, and the model can invoke the tool. Replace the example with whatever capability you need -- database queries, API calls, file operations. If you want to build your own server, the step-by-step MCP server tutorial covers everything from project setup to deployment.

Frequently Asked Questions

What does MCP stand for?

MCP stands for Model Context Protocol. It is an open protocol created by Anthropic that standardizes how AI applications connect to external tools, data sources, and services.

Is MCP only for Anthropic's Claude?

No. MCP is an open, vendor-neutral protocol now governed by the Agentic AI Foundation under the Linux Foundation. It is supported by Claude, ChatGPT, Gemini, Microsoft Copilot, Cursor, VS Code, and many other AI applications. Any AI system can implement the MCP client specification to connect with MCP servers.

How is MCP different from function calling?

Function calling lets a model request that a specific function be executed, but it lacks a standard protocol for discovery, transport, security, and capability negotiation. MCP wraps the concept of tool invocation in a full protocol layer -- servers announce their capabilities, clients negotiate what they support, communication happens over standard transports (stdio or HTTP), and security is built into the design. Function calling is an API feature. MCP is an interoperability protocol.

What programming languages can I use to build MCP servers?

The official SDKs support TypeScript/Node.js and Python. Community implementations exist for Go, Rust, Java, C#, Ruby, and other languages. The protocol itself is language-agnostic -- any language that can read and write JSON-RPC messages over stdio or HTTP can implement an MCP server.

Is MCP secure enough for enterprise use?

MCP's security model includes user consent requirements, data privacy controls, tool safety annotations, and server-to-server isolation. The protocol specification mandates that hosts obtain explicit user consent before data access or tool invocation. Enterprise deployments can layer additional authentication, authorization, and audit controls on top of the protocol's built-in security model. The Linux Foundation governance provides the institutional backing that enterprise compliance teams typically require.

How many MCP servers are available?

The ecosystem has grown rapidly since MCP's launch in November 2024. As of early 2026, thousands of MCP servers are available, covering categories including filesystem access, databases, version control, communication platforms, cloud services, monitoring tools, and specialized domain APIs. The official MCP server registry and community repositories like GitHub are the best places to discover available servers.

What Comes Next

MCP has accomplished something rare: getting every major AI company to agree on a shared standard. The protocol is stable, the governance is established, the ecosystem is thriving.

As AI agent systems become more sophisticated -- coordinating multiple types of agents across complex workflows -- MCP provides the integration layer that makes that coordination possible. Every new MCP server makes every agent system that supports the protocol more capable.

The age of isolated AI models generating text into a void is ending. The age of connected agents that perceive, reason, act, and learn through standardized protocols is here. MCP is the protocol that made the transition possible.
mcps pillar