The one-line definition
Model Context Protocol (MCP) is an open standard for connecting AI agents to the systems where your data and actions live. Instead of writing custom tool wrappers for every LLM and every product, MCP defines one server-side protocol that any MCP-compatible client can talk to.
Shipped by Anthropic in November 2024. Adopted across the agent ecosystem through 2025. By mid-2026 it is the default way AI agents access external tools.
Why MCP matters
Before MCP, every AI product that wanted to give an agent real capabilities had to solve the same problem five times:
- Write a LangChain tool definition for the Python agent builders
- Write a TypeScript tool wrapper for the JavaScript agent builders
- Write a Claude Desktop plugin for users who work inside Claude
- Write a Cursor extension for users who work inside Cursor
- Hand-document the REST API for everyone else
Each wrapper was slightly different. Each broke when the underlying product changed. Every framework had to re-implement the same logic against each SaaS.
MCP collapses that. Write one MCP server. Every MCP-compatible client can talk to it. The server exposes a typed catalog of tools; the client's LLM picks which ones to call; tool calls flow through the protocol. New agent frameworks ship MCP adapters and inherit the entire tool ecosystem for free.
The practical effect: when FoxReach shipped its MCP server in 2026, builders using Claude Desktop, Cursor, Claude Code, OpenClaw, LangChain, CrewAI, OpenAI Agents SDK, and Claude Agent SDK could all register FoxReach in under 10 minutes - no custom code, no tool wrapper libraries to maintain.
How MCP works
Three pieces: client, server, transport.
Client runs inside the AI product - Claude Desktop, Cursor, Claude Code, an agent framework. The client speaks MCP to one or more servers. When a user asks the agent to do something, the client's LLM looks at the tools all connected servers expose and picks which to call.
Server is what an SaaS or data source ships. FoxReach's server runs at api.foxreach.io/mcp. A server exposes a catalog of tools with typed arguments, handles incoming tool calls from clients, and returns results. The server is where the real work happens.
Transport is the wire protocol. Most MCP deployments use streamable HTTP today (a simple HTTPS endpoint that handles SSE for long-running tool calls). There is also a stdio transport for locally-running servers and a WebSocket transport in the spec. Clients typically support all three; servers pick one.
The flow:
- Client connects to the server (TLS, authenticates with a Bearer token).
- Server responds with a catalog: "here are the 23 tools I expose, here are their schemas."
- The LLM inside the client decides to call a tool based on user intent.
- Client sends a tool-call message through the transport.
- Server executes, returns the result.
- LLM reads the result, decides whether to call another tool or produce a final answer.
That is the whole protocol at the level most builders need to understand. The spec has more - prompts, sampling, resources - but tools carry most of the weight for product integrations.
What changed with MCP adoption
2024 was the experimentation phase. Anthropic shipped the spec; Claude Desktop shipped the reference client; early adopters wrote MCP servers for GitHub, Postgres, Slack, Puppeteer.
2025 was the framework-integration phase. LangChain and CrewAI released adapter libraries. The OpenAI Agents SDK added native MCP support. Cursor, Zed, and Continue shipped built-in MCP clients. The community repo of MCP servers crossed 300 entries by year-end.
2026 is the product-integration phase. Every serious SaaS that sells to builders is either shipping an MCP server or being asked why they haven't. Cold email platforms, CRMs, data tools, observability platforms - the question has flipped from "do you have an API?" to "do you have an MCP server?"
MCP and cold email
Cold email is an obvious fit for MCP. The category has clear, well-bounded tools - create campaign, add lead, start sequence, read reply - and the agent consumer mapping is natural. "Send a cold email to this list" is an intent that decomposes into 5-10 discrete tool calls, each well-suited to an MCP server's tool interface.
FoxReach's MCP server exposes 23 tools covering leads, campaigns, sequences, templates, email accounts, and inbox operations. The catalog mirrors the REST API but is shaped for agent consumption: typed arguments, idempotent where it matters, descriptive names. An agent that knows how to use create_campaign does not need to know what endpoint it hits or how to build the JSON body.
Instantly shipped an MCP wrapper in February 2026 - thinner coverage, REST-behind-the-scenes, but real. Smartlead has published extensively about MCP without shipping a first-party server. Lemlist has no MCP support as of 2026-Q1. The cold email category is bifurcating into MCP-first products (FoxReach) and REST-first products that are bolting MCP on top (everyone else).
For builders: this matters because the MCP-first products have agent-shaped tool catalogs from day one. REST-with-MCP-wrapper products often have tool catalogs that mirror dashboard actions rather than agent intentions - subtle but real ergonomic cost.
Clients and frameworks that ship MCP today
AI desktop clients:
- Claude Desktop - the reference client, native MCP
- Claude Code - terminal-native, MCP servers via config
- Cursor - Pro tier, MCP as an "Integrations" concept
- Zed - built-in
- Continue - VS Code / JetBrains extension with MCP support
- OpenClaw - open-source Claude Desktop alternative
- Paperclip - multi-agent workspace
Agent frameworks:
- Claude Agent SDK - native, via anthropic SDK
mcp_serversparam - OpenAI Agents SDK - native, via
MCPServerStreamableHttp - LangChain - via
langchain-mcp-adapters - LangGraph - same adapter as LangChain, graph nodes call MCP tools
- CrewAI - via
crewai-tools MCPServerAdapter - Vercel AI SDK -
experimental_createMCPClient - Pydantic AI -
pydantic-ai-mcp - Mastra - MCP as a tool provider
Community servers:
- GitHub, Postgres, SQLite, Slack, Google Drive, Brave Search, Puppeteer, filesystem - the canonical MCP server list maintained in the MCP community repo
- FoxReach for cold email
What MCP does not do
Common misconceptions:
MCP is not a model. MCP does not run inference. It is a transport between a client (which uses an LLM) and a server (which executes tools). The LLM sits inside the client and decides which tools to call.
MCP is not a framework. MCP does not coordinate multi-agent workflows, manage state, or handle retries. Those sit above the protocol in agent frameworks (LangGraph, CrewAI) or in the client's agent loop.
MCP is not Anthropic-locked. The spec is open. OpenAI, Cursor, Continue, open-source clients all implement MCP. Any server can serve any compliant client.
MCP is not a replacement for REST APIs. Most MCP servers wrap REST APIs - the protocol is agent-shaped access on top of the HTTP product you already have. You still need the REST API for non-agent integrations (webhooks, Zapier, manual curl).
When to ship your own MCP server
If you sell a product that developers integrate with, ship an MCP server. The work is small - a few hundred lines of code - and the payoff is every MCP-compatible client and framework gets access to your product automatically.
Three signals that your product needs an MCP server:
- You have a REST API. If builders are already writing integrations against your API, they are ready to wire up an agent next.
- Your product has discrete actions. Not every product fits - a video streaming service does not need an MCP server. Products with clear verbs (create, update, send, read) fit cleanly.
- Your category has an agent-adjacent use case. If customers are asking "can your tool be in a Claude conversation?" - that question is MCP-shaped.
For teams evaluating whether to ship: start with the 5 highest-value tools your product exposes. Wrap those as MCP tools first. Ship to one client (Claude Desktop is the reference implementation). Expand from there.
How to get started as a builder
If you want to use MCP - not ship one - the fastest path is connecting Claude Desktop to FoxReach or a similar MCP server. Five minutes from "what is MCP" to "I have a working agent that runs cold email."
If you are building an agent with LangChain, CrewAI, or OpenAI Agents SDK, use the adapter library for your framework and point it at any MCP server. The framework guides in our cluster walk through exactly this:
- LangChain + MCP
- CrewAI + MCP
- LangGraph multi-step + MCP
- OpenAI Agents SDK + MCP
- Claude Agent SDK + MCP
The pillar guide on cold email for AI agents covers the decision framework for which framework + MCP combination fits which team.
Why we care at FoxReach
FoxReach was built MCP-first because the category FoxReach is in is moving toward agent-native outbound. A cold email platform that shipped a REST API in 2019 and bolts MCP on top in 2026 ends up with a tool catalog shaped like a dashboard rather than shaped like an agent's task list. We started with MCP as a first-class surface and everything else - SDKs, CLI, plugin - feeds the same state machine.
Opinion: MCP is the 2026 version of what REST APIs were in 2010. In two years everyone who builds a developer product will ship one, the same way everyone who built a SaaS shipped a REST API. Products that shipped MCP first get agent-shaped ergonomics for free; products that retrofit will carry some API-legacy weight forever.
If you are building in cold email, start with FoxReach's MCP server. If you are building in another category, the same pattern applies - the builders buying your product in 2027 will ask about MCP before they ask about REST.
