MCP: What It Is, Protocol, & Everything You Need to Know

MCP (Model Context Protocol) is a standard for connecting AI applications to external tools and data through reusable servers. Instead of wiring tools into each app, they’re exposed once and discovered at runtime.

At a surface level, it looks like function calling with extra steps. Sometimes it is.

The question is whether it’s worth adopting at all. If you’re already using function calling with a single model and stable tools, MCP may add more infrastructure than value. It starts to matter when tools need to be shared across models, apps, or teams.

This article breaks down what MCP changes entail, whether the infrastructure is stable or still evolving, and how to decide when it’s actually worth using.

What Is MCP If You Already Use Function Calling?

The most common thing Leland AI coaches hear from engineers at this exact moment is "wait, isn't this just function calling?" That instinct is correct, and it's the whole game. MCP is built on the tool-use concept you already know. Understanding the relationship between them is most of what you need.

MCP standardizes the part you currently hardcode, instead of defining your tools inside each app's code and wiring them to one model's SDK. MCP puts tool definitions behind a server that any MCP-compatible host can discover and call.

MCP (Model Context Protocol) is an open protocol introduced by Anthropic in November 2024, built on JSON-RPC 2.0, for connecting LLM applications to external tools and data. Any host that speaks MCP can connect to that server, list its tools, and call them.

The payoff is combinatorial. Without MCP, connecting 3 models (Claude, GPT-4o, Gemini) to 3 tools (GitHub, Slack, Postgres) is 9 separate integrations; every model needs its own wiring to every tool. With MCP, it's 6: three servers plus three clients. The N×M problem collapses to N+M.

MCP is not a model, it's not a framework like LangChain, and it's not a replacement for your LLM API. You still call Claude or GPT-4o the way you do now. MCP is a wire protocol for how hosts talk to tool servers, nothing more.

And yes, it's the "USB-C for AI" thing you've seen, a universal connector between models and tools. That analogy is accurate. It's also where every other explainer stops, which is why you still don't know whether to use it.

Is MCP a Real Standard or Just Early Momentum?

MCP is no longer a single-vendor experiment. The important signal is convergence. Competing AI platforms are aligning around a shared tool interface instead of building isolated integration layers.

Adoption splits into three groups. Model providers are building MCP support into their agent ecosystems. Developer environments are integrating it directly into IDE workflows. Tooling companies are exposing MCP servers so their products can be used across multiple AI systems without custom integrations.

This creates the appearance of standardization. In practice, it means interface alignment, not ecosystem maturity. The protocol is stabilizing, but the surrounding layer of servers, permissions, and operational tooling is not.

Most of the remaining risk is no longer about the protocol itself. It is about everything around it. Tool quality is uneven. Security practices are inconsistent. Production reliability depends heavily on who is implementing the server, not the protocol spec.

So, MCP is becoming a standard interface. It is not yet a standardized ecosystem.

How MCP Protocol Works

The MCP protocol works through three roles. A host runs the AI application and the model that the user interacts with. An MCP client lives inside the host and manages connections to external systems. A server is a separate process that exposes tools and data. The client and server communicate through JSON-RPC, which enables AI models to interact with external systems in a consistent way.

1. Host: The host is the AI application (for example, an IDE or chat interface). It runs the model and coordinates tool usage.
2. Client: The client lives inside the host and manages communication with MCP servers. Each client maintains a connection to a specific server.
3. Server: The server exposes tools, resources, and prompts. It runs independently and responds to structured requests from clients.

This separation allows tools to be modular, reusable, and independent of any single AI application.

How MCP fetches data in practice

A typical MCP interaction follows this flow:

1. The host application starts and initializes the model
2. The client connects to one or more MCP servers
3. Each server advertises available tools and capabilities
4. The model selects a tool based on user input
5. The client sends a structured request to the server
6. The server executes the request (e.g., queries an API or database)
7. The result is returned and injected into the model’s context
8. The model continues generating its response

Steps 4 through 8 follow the same execution pattern as function calling. The key difference is earlier in the flow. MCP clients dynamically discover available tools from different MCP servers at runtime instead of relying on tools being hardcoded into the application. This design enables AI models to interact with external systems without predefined integrations.

What MCP servers expose

MCP servers expose three primitives. Tools are model-invoked actions such as get_pr_diff. Resources are data sources the host can pull into context, such as files or database records. Prompts are reusable workflows exposed to the user as ready-made instructions.

For example, a server can expose a /summarize-pr prompt that appears in tools like Claude Desktop as a shortcut that fetches a diff and summarizes it.

Local vs. remote transport

Transport is a deployment choice with security implications. The stdio option runs the server locally on your machine. It offers low latency and no network exposure because everything runs in-process. The Streamable HTTP option runs the server remotely. It makes MCP servers shareable across systems but introduces authentication, networking, and access control requirements.

Local transport is best for development and experimentation. Remote transport is used when servers need to support multiple users or production environments.

MCP vs Function Calling vs RAG: When to Use Which

Function calling, MCP, and RAG solve different problems, and most systems only need one of them at first.

Function calling is the default starting point when you have a single model and a small set of stable tools. MCP becomes relevant when those tools need to be shared across multiple models or applications, or when you want to reuse external servers instead of rebuilding integrations. RAG sits alongside both when the problem is not about actions but about grounding the model in external knowledge.

MCP and RAG are not competing approaches. MCP can call retrieval systems tools, which means they often coexist in the same architecture.

This is the section most explanations skip, because it is less clean than the diagrams suggest. In practice, teams often stay on function calling longer than expected because it reduces operational overhead and avoids introducing infrastructure that does not yet pay for itself.

Comparison

Decision guidance

Function calling is usually enough when the system is small, stable, and self-contained. It is the fastest path to production and often the correct long-term choice for focused applications.

MCP starts to matter when duplication becomes a problem. If multiple applications or models need the same tools, or if third-party servers are more efficient than rebuilding integrations, the overhead begins to pay for itself. RAG is separate from both. It applies when the model needs access to information it was not trained on, not when it needs to take structured actions.

The important constraint is the cost of complexity. MCP introduces infrastructure, deployment, and security considerations that function calling avoids entirely. In many systems, that cost is not justified until reuse becomes unavoidable.

A simple example makes this clear. A customer support bot with a few internal tools, like lookup_order, issue_refund, and escalate, does not benefit from MCP. Function calling is faster to ship and easier to maintain. MCP only becomes useful if those same tools need to be exposed to multiple agents or external systems.

The real decision point is reuse. Until tools need to exist beyond a single application, MCP adds structure more than value.

What Actually Changes When You Adopt MCP

When teams adopt the model context protocol MCP, the biggest shift in the system is design. Instead of writing custom connectors and scattering traditional APIs across applications, teams begin exposing capabilities through reusable MCP server implementations. These servers define standardized server capabilities that can be reused across multiple clients, turning integrations into shared infrastructure rather than application-specific logic. In effect, MCP addresses the fragmentation problem of tool integration by introducing a standardized interface for connected tools.

A second change is the move toward dynamic tool discovery. Rather than hardcoding available tools at build time, MCP allows clients to discover what a server can do at runtime and add MCP servers as new capabilities are needed. This shifts systems from static integration graphs to flexible networks where multiple clients can interact with the same server, depending on configuration. As a result, data retrieval, file systems, and external services become interchangeable sources of structured data that models can access to retrieve relevant information or access real-time data during execution.

Finally, MCP changes how systems are operated at scale. Because multiple clients may interact with the same server, consistency, error handling, and versioning become shared concerns rather than local implementation details. In environments like an AI-powered IDE, MCP effectively behaves like a USB-C port for AI systems: a single interface for plugging into popular enterprise systems, development tools, and external APIs. This makes MCP less about replacing API calls and more about standardizing how AI systems connect to and coordinate across external infrastructure, shaping how future MCP ecosystem designs will evolve.

How to Start Using the MCP Protocol Today

To try the MCP protocol is to consume an existing server before you build one. Install Claude Desktop, add a prebuilt server like the filesystem server to its config file, restart, and confirm the tools appear. This takes an afternoon, requires no cloud account, and teaches the host-client-server flow in about fifteen minutes without the distraction of writing handlers.

The simplest host for local experimentation is Claude Desktop. It is a working MCP host, and connecting a prebuilt server takes a config edit and a restart.

The quickstart:

1. Install Claude Desktop.
2. Install a prebuilt server. The filesystem server runs via npx, so there is nothing to clone.
3. Add it to the mcpServers block in claude_desktop_config.json. On macOS, this lives in ~/Library/Application Support/Claude/. Check the quickstart for your OS. The block names the server and the command that launches it.
4. Restart Claude Desktop and confirm the new tools appear in the interface.

Now Claude can read and write files in the directory you scoped, and you have watched the full discovery-and-call loop happen against a real server.

When you are ready to build your own, the official resources are these:

• modelcontextprotocol.io, the spec and documentation. Start here.
• The official SDKs, available in Python, TypeScript, and several other languages, which you use to build a server.
• github.com/modelcontextprotocol, reference servers, and examples worth reading before you write your own.

A tool-schema definition plus a handler function that does the work and returns a result. Define the schema, write the handler, register it, and point a host at it. The SDK quickstart covers the rest. The goal is not to build something elaborate first. It is to feel the protocol from the server side once you have seen it from the host side.

What MCP Servers Already Exist, and Are They Safe to Use?

Prebuilt MCP servers already exist for common systems. They fall into three tiers. Reference servers live in Anthropic's official repo and show off core features. These include filesystem, Git, fetch, and memory. Official integrations are maintained by the companies themselves, like Cloudflare, Neon, and Linear servers. Community servers round out the long tail, and the repo warns that these are untested and should be used at your own risk. The reference and official ones are the safer defaults. Connecting to any server you did not write means accepting a trust decision, because a server can run code on your machine or access your data.

The three tiers, at a glance:

• Reference servers. Maintained by Anthropic to demonstrate core features. Examples are filesystem, Git, fetch, and memory.
• Official integrations. Maintained by the companies behind each platform, like Cloudflare, Neon, and Linear.
• Community servers. A large open ecosystem. These are untested and use at your own risk.

Here is why the trust decision is sharper than a normal API checklist. The risks are specific to how MCP works:

• Prompt injection via tool responses. A malicious server returns content crafted to hijack the model's behavior. The model treats the tool's output as trusted context, so a server that controls what comes back can steer what the model does next.
• Tool poisoning. The attack hides in the tool's description, not its output. The model reads tool descriptions to decide what to call, so a description stuffed with hidden instructions can manipulate the model before any tool runs.
• The rug-pull problem. A server you reviewed and approved pushes a later update that adds malicious behavior. You vetted version 1.2; version 1.3 ships something else. Trust granted once is not trust granted forever.

A pre-connection checklist that addresses these:

• Prefer official or audited servers. The reference repo is a known quantity in a way a random community server is not.
• For remote servers, use OAuth 2.1 and scope tokens to least privilege. Give the server access to exactly what its tools need and nothing more.
• Review what each tool can actually do before approving it. Read the tool's capabilities, not just its name.
• Pin and audit server versions. Do not auto-update a server with access to your data. That is the rug-pull opening.
• Treat a local server like an npm dependency. You are running someone else's code with your permissions, so vet it the same way.

The Bottom Line

MCP is not an AI upgrade. It is an infrastructure decision. If you have one model and a few stable tools, native function calling is usually the right choice. It is faster to ship, easier to maintain, and avoids operational overhead that may never pay for itself.

MCP becomes valuable when the same tools need to work across multiple AI assistants, agents, IDEs, or models. At that point, the challenge is no longer tool usage. It is managing integrations. MCP provides a standardized way to connect AI systems to external services and data sources without rebuilding the same connector for every application.

A useful rule of thumb is to ask whether the tool is being reused. If one application needs it, use function calling. If multiple applications need it, consider MCP. If the goal is to retrieve information from documents, use RAG. Most teams do not adopt MCP too late. They adopt it too early, before reuse creates a problem worth solving.

Make the Call With Confidence

The Model Context Protocol (MCP) has become an established standard for connecting AI assistants to external data sources, resources, and tools through a reusable client-server architecture. That maturity has reduced much of the uncertainty that made teams hesitant to adopt it in 2025. Still, established does not mean essential. For a single model connected to a small number of stable, internal tools, function calling is often faster to implement and easier to maintain. Leland’s AI Automation and AI Agents can help you determine whether MCP would meaningfully improve your workflow or simply add unnecessary complexity.

If that moment has arrived for your build, start small. Point Claude Desktop at a filesystem MCP server, watch the tool invocation and discovery loop run once, then decide whether available MCP servers are enough or whether you need custom code. And if you are ready to build agentic AI workflows beyond experimentation, Leland’s AI Builder Program can help you move from concept to working AI-powered tools with a clearer technical path.

Want to strengthen your understanding before committing engineering time? Join one of Leland’s free AI events to learn from builders, operators, and coaches working with MCP, AI agents, conversational AI, and integrating AI systems in real development environments.

Read these next:

• The 5 Best AI Tools & Agents for Business: Reviewed & Ranked (2026)
• AI Agents for Business: Use Cases, Examples, & Expert Tips (2026)
• The 5 Best AI Coding Agents: Pros & Cons, Reviews, & Which is Best for You
• AI Change Management: How to Lead Your Organization Through the AI Transition
• Claude vs. ChatGPT vs. Gemini: Pros & Cons and Which AI Tool is Best for You
• The 10 Best AI Tools & Agents for Startups: Reviewed & Ranked (2026)
• 50+ AI Prompt Templates & Expert Tips (2026)

FAQs

What is the MCP protocol in AI?

• The MCP protocol, or Model Context Protocol, is an open protocol that standardizes how AI applications connect to external tools, data sources, and systems. It lets MCP-compatible hosts discover and call tools through MCP servers instead of hardcoding every integration inside the app.

How is MCP different from function calling?

• Function calling defines tools inside one application and usually ties them to one model SDK. MCP moves those tools behind reusable servers, so multiple AI models, assistants, or applications can discover and use the same tools through a standardized protocol.

When should I not use MCP?

• Do not use MCP for a single AI app with one model and a few stable internal tools. In that case, native function calling is simpler, faster to ship, and easier to maintain.

What MCP servers can I use without building my own?

• Common prebuilt MCP servers include filesystem, GitHub, Postgres, Slack, and Google Drive servers. These let AI assistants access files, repositories, databases, messages, and documents without requiring you to build a custom connector first.

How do I get started with MCP?

• The fastest way to start with MCP is to connect Claude Desktop to a prebuilt MCP server, such as the filesystem server. Add the server to the mcpServers configuration, restart Claude Desktop, and confirm the available tools appear.

Does MCP work with models other than Claude?

• Yes. MCP is model-agnostic. It standardizes the connection between an AI application and an MCP server, not the model itself, so MCP can work across different AI models and assistants.

What are the security risks of MCP servers?

• MCP security risks include prompt injection through tool responses, tool poisoning through malicious tool descriptions, and supply-chain risk from untrusted server updates. Treat MCP servers like software dependencies: use trusted servers, limit permissions, review tool capabilities, and avoid exposing sensitive data unnecessarily.