MCP in brief

The Model Context Protocol (MCP) is an open specification that standardizes how large language models (LLMs) connect to external data sources, tools, and systems. Instead of wiring custom integrations for each AI platform, a developer can build an MCP server once and let any MCP-compatible client—Claude, GPT-4, Cursor—use it.

MCP is not a library or SDK; it's a protocol spec in the same category as REST or GraphQL, but aimed at AI agents. Models still rely on their trained knowledge, but when they hit their limits, they can call real functions and fetch real data through MCP servers—querying your inventory system in real time instead of guessing stock levels, or pulling documentation that was merged to prod minutes ago rather than whatever was last crawled.

Server tools vs. plain APIs

The distinction comes down to who is calling what. An API is built for apps: a developer sends a request to a known endpoint and gets a predictable response. An MCP server is built for models. It exposes a machine-readable manifest—typically JSON—that describes each available tool's name, description, input schema, and output schema. The model reads that context, plans which tool fits the user's goal, and invokes it.

Each tool call is a normal HTTP request (or another transport) from the model to the MCP server. The server executes the logic and returns a result the model can use to decide its next step. The cycle repeats until the task completes.

You probably already have APIs and internal databases. An MCP server wraps those in a standardized layer so that any MCP-compatible agent can use them—no custom logic per model, no vendor lock-in.

When to build a server vs. define tools directly

If you're building for a single app or one AI provider, defining tools directly in the LLM call is the simpler path: it's faster and gives you full control over execution. MCP adds a layer where your tools live on a separate server. You connect to that server first, provide context to the model, then invoke the tool with the model's chosen input.

That extra layer pays off when you want the same context and tools shared across many apps, models, or environments.

Getting started and using a server

Both the AI SDK and the open source mcp-handler SDK simplify server creation. The mcp-handler works with Next.js, Nuxt, and Svelte apps in a few lines of code, and most frameworks are supported. You define what the model can do and what it has access to; the abstraction handles spec details. The Vercel team was able to add an MCP server to Grep in an afternoon.

To consume a server, a client (your model or AI host) connects and lists the server's capabilities—what inputs each tool takes and what outputs it returns. The model sees that toolbox, plans calls, and fires requests only when it needs a specific tool. No manual orchestration is required; the model drives the process from the MCP spec.

Transports: how model and server talk

Transports define the communication channel between the model and your MCP server. StreamableHTTP is the primary transport today: the model hits a URL over standard HTTP to establish a connection, with optional Server-Sent Events (SSE) for real-time notifications. The other common transport is stdio, used in local or CLI environments where the model and tools share the same process. The right choice depends on whether you need a one-off call or an ongoing stream of actions. Packages like mcp-handler support multiple transports, making it easy to switch or support several.

Agent vs. server, local vs. remote

An AI agent is the model (or the system using it) that plans and takes actions. An MCP server defines which actions are possible. The agent decides what to do; the server tells it how. The server never acts on its own—it only shows the model what's available.

The local/remote split is about where the server runs. A local MCP runs on the same machine as the model—common in playgrounds, dev tools, and prototyping when you don't want data exposed publicly. It's fast and private. A remote MCP lives on a separate server, which is how production apps typically work: models running on OpenAI, Claude, or your IDE can reach shared, centralized tools. You can develop locally first, then move remote for launch.

Security and governance

MCP servers don't bypass your existing auth or logic. They expose only what you choose: a model can see and use only the tools you define. If a tool requires user auth, you enforce it as you would with any API. You control the logic behind each tool, so you can build in checks, rate limits, logging, and more. mcp-handler supports the MCP Authorization Specification, letting you protect endpoints and access auth information inside your tools.

Use cases

MCP fits anywhere a model should interact with real systems safely:

  • E-commerce: expose product search, cart updates, order history, and checkout so a model can help users find items and complete purchases.
  • Finance: let models pull balances, categorize transactions, or generate reports while respecting permissions and limits.
  • Marketing: run audience queries, send outbound messages, or schedule campaigns through structured workflows.

There are meta-use cases too: one agent coordinating with another, or managing tools inside AI-native apps. The same pattern extends to customer support bots, logistics tracking, and clinical assistant tools.

Origins and ecosystem

Anthropic created MCP and released it as open source under the MIT license. The spec, SDKs, and examples live on GitHub. Development is community-driven—a core maintainer group plus contributors iterating in public, with no formal committee. Zed uses MCP for coding tools, Sourcegraph for code search and navigation, and independent developers have built servers for smart homes and research tools. The AI SDK and v0 support MCP out of the box.

Alternatives

MCP isn't the only way to wire models to tools. The Simple Language Open Protocol (SLOP) uses plain HTTP endpoints that accept natural language—easy to set up, but it pushes more interpretation work onto the model at runtime. Platform-specific options like OpenAI's function calling integrate tightly within their own ecosystem and perform well, but require rebuilding for each platform. Orchestration frameworks like LangChain help manage workflows across multiple LLMs and tools, and often support MCP alongside their own abstractions.

For quick experiments, SLOP is fast. For deep integration with one provider, platform tools make sense. For complex workflows, an orchestration framework helps. But if you want one tool setup to work across many AIs with clear structure and security, MCP is the practical choice for most projects.

The case for a common AI integration layer

MCP shifts the AI integration model from bespoke, per-platform efforts toward a shared standard. Rather than building and maintaining a separate adapter for each AI tool, developers can expose their existing APIs and services once, and those capabilities become available across the ecosystem.

The analogy to the early web is instructive. Before common protocols, websites required browser-specific code; the adoption of HTTP and REST brought a level of consistency that made the web far more capable. MCP applies that same principle to AI, providing a common interface between models and the tools they can act upon.

For developers, the barrier to participation is intentionally low. The systems and APIs an organization already has can be wrapped in an MCP server without abandoning existing infrastructure. As adoption of MCP grows across more platforms, each individual integration compounds in value.

The more significant shift is what becomes possible when an AI system is not limited to generating suggestions but can execute actions. With MCP, the boundary between knowing and doing becomes thinner, enabling a new class of applications.

A concrete example is the recent addition of an MCP server to Grep, a fast code search tool. Grep already had an API, but with an MCP server on top, it can be plugged into assistants like Cursor and Claude Code. This allows an AI to reference coding patterns and solutions collected from over a million open source repositories when helping build applications.