---
title: "What Is MCP? The Model Context Protocol in Plain English"
url: https://apyhub.com/blog/what-is-mcp-the-model-context-protocol-in-plain-english
author: ApyHub
published: 2026-09-15T10:59:00Z
---

# What Is MCP? The Model Context Protocol in Plain English

# What Is MCP? The Model Context Protocol in Plain English

## Introduction

MCP (Model Context Protocol) is an open standard that lets AI applications connect to outside tools and data in one consistent way. Instead of building a custom integration for every service, a developer wraps the service in an MCP server once, and any MCP-compatible AI assistant can find it and use it.

If you've heard people call MCP "USB-C for AI," that's the idea. Before USB-C, every device needed its own cable. Before MCP, every AI app needed its own connector for every tool. MCP replaces that drawer of cables with one plug.

This guide explains what MCP is in AI, what an MCP server does, how a conversation between an assistant and a server actually works, how MCP compares to regular APIs and RAG, and what to watch for on security. No prior knowledge needed.

## The problem MCP solves

AI models are good at reasoning and writing, but on their own they can't open your files, check today's exchange rate, or convert a document into a PDF. To do real work, they need tools.

Before MCP, connecting a model to a tool meant writing custom code for that exact pairing. Picture five AI apps and ten tools. Without a shared standard, you need up to 50 separate integrations, and each one breaks in its own way when something changes. This is often called the **N×M problem**.

MCP turns it into an **N+M problem**. Each tool gets one MCP server. Each AI app gets one MCP client. Any client can then talk to any server.



Without MCP                         With MCP



App A ──┬── Tool 1                  App A ─┐          ┌─ Server: Tool 1

&#x20;       ├── Tool 2                  App B ─┼── MCP ───┼─ Server: Tool 2

App B ──┼── Tool 1                  App C ─┘          └─ Server: Tool 3

&#x20;       ├── Tool 2

App C ──┴── ...  (every pair         (one connection per app,

&#x20;            built by hand)            one server per tool)

## Where MCP came from

Anthropic introduced MCP as an open standard in November 2024. Adoption moved fast. When Anthropic [donated MCP to the Agentic AI Foundation](https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation) on December 9, 2025, it reported more than 10,000 active public MCP servers and adoption by ChatGPT, Cursor, Gemini, Microsoft Copilot, Visual Studio Code, and other AI products. The foundation is a directed fund under the Linux Foundation, co-founded by Anthropic, Block, and OpenAI, with support from Google, Microsoft, AWS, Cloudflare, and Bloomberg.

That move matters for anyone deciding whether to build on MCP: the standard is now governed by a neutral body rather than a single company.

## What is an MCP server? The three building blocks

MCP has three roles. Learn these three and the rest of the protocol is easy to follow.

* **Host.** The AI application you actually use, such as Claude, ChatGPT, Cursor, or VS Code. The host runs the model and decides what the model is allowed to reach.
* **Client.** A connector that lives inside the host. Each client holds one connection to one MCP server and handles the messages back and forth.
* **Server.** A small program that wraps an outside system (a database, a file store, an API) and describes what it can do in a format any client understands.

text

```
You
 │
 ▼
Host (Claude, Cursor, VS Code...)
 │   └── runs the AI model
 ▼
MCP client ─────────────►  MCP server  ─────►  Outside system
(one per server)           (describes and       (API, database,
                            runs capabilities)   files)
```

**So, what is an MCP server in one sentence?** It's the adapter that turns an outside service into something any AI assistant can discover and use without custom code.

## What an MCP server can offer: tools, resources, and prompts

An MCP server exposes its capabilities through three types, called primitives.

| Primitive | What it is                          | Who decides to use it | Example                                                |
| --------- | ----------------------------------- | --------------------- | ------------------------------------------------------ |
| Tools     | Actions the AI can run              | The model             | Convert a file, validate a VAT number, create a ticket |
| Resources | Data the AI can read as context     | The application       | A file's contents, a database record                   |
| Prompts   | Reusable templates for common tasks | The user              | "Summarize this contract" with preset instructions     |

Tools get the most attention because they let an assistant *do* things rather than only read. According to the [MCP specification](https://modelcontextprotocol.io/specification/2026-07-28/server/tools), tools are designed to be model-controlled: the language model discovers and invokes them automatically based on the conversation and the user's request. Each tool has a unique name and a schema describing its inputs.

## How MCP works, step by step

Here's what happens when you ask an MCP-connected assistant to do something.

**1. Connect.** When the host starts, its client connects to the server and the two agree on which features they support.

**2. Discover.** The client asks the server what it offers by sending a `tools/list` request. The server replies with each tool's name, a plain-language description, and an input schema:

json

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "convert_document",
        "description": "Converts a document into another file format and returns a link to the new file.",
        "inputSchema": {
          "type": "object",
          "properties": {
            "source_url": { "type": "string" },
            "target_format": { "type": "string", "enum": ["pdf", "docx"] }
          },
          "required": ["source_url", "target_format"]
        }
      }
    ]
  }
}
```

**3. Decide.** You type "send me this report as a PDF." The model reads the tool descriptions, sees that `convert_document` fits, and writes the arguments.

**4. Call.** The client sends a `tools/call` request to the server:

json

```json
{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "convert_document",
    "arguments": {
      "source_url": "https://example.com/files/report.docx",
      "target_format": "pdf"
    }
  }
}
```

**5. Answer.** The server runs the conversion and returns the result. The model reads it and replies to you, or calls another tool if the job has more steps.

All of these messages use JSON-RPC 2.0, a lightweight format for requests and responses. The examples above are simplified: the current specification revision also requires some metadata fields on each request, which the spec itself leaves out of its examples for readability.

For a longer walkthrough of this loop from the agent's side, see [How AI Agents Use APIs: A Beginner's Guide](https://apyhub.com/blog/how-ai-agents-use-apis-a-beginner-s-guide).

## Local vs remote MCP servers

MCP servers run in one of two places.

* **Local servers** run on your own machine, next to the AI app, and usually talk to it through standard input and output (stdio). They suit tasks like reading local files or running tools on your laptop.
* **Remote servers** run on the internet and talk to clients over HTTP (the spec's Streamable HTTP transport). One remote server can serve many users, and connecting to it is often as simple as pasting a URL into your AI app's connector settings.

Most services built for teams, including API catalogs, use remote servers, because nothing has to be installed on each user's machine.

## MCP vs API: what's the difference?

This is one of the most common questions, and the short answer is that MCP doesn't replace APIs. It sits on top of them.

An **API** defines how software talks to one specific service: its URLs, parameters, and responses. A developer reads the documentation and writes code for it.

**MCP** defines how an AI application discovers and uses capabilities, and most MCP servers wrap one or more existing APIs. The server translates between the model and the API, so the model never needs to know the API's details.

|                             | Traditional API                           | MCP                                                |
| --------------------------- | ----------------------------------------- | -------------------------------------------------- |
| Who it's designed for       | Developers writing code                   | AI applications and agents                         |
| How capabilities are found  | Reading documentation                     | At runtime, via tools/list                         |
| Integration work            | Custom code per API, per app              | One server per service, reused by every client     |
| Describes itself to a model | No                                        | Yes, through names, descriptions, and schemas      |
| Best for                    | Fixed, high-throughput, low-latency paths | Assistants and agents that choose tools as they go |

MCP can be overkill for a single-purpose app with one fixed integration. If your code always calls the same endpoint in the same way, calling the API directly is simpler and faster.

## MCP vs function calling

Function calling is a feature built into most model APIs. The developer writes tool definitions inside their own application, and the model can request those functions.

MCP builds on the same idea but moves the definitions out of the app and onto a server. With function calling, every application defines its own tools. With MCP, a tool is defined once and every compatible client can use it.

## MCP vs RAG

RAG (retrieval-augmented generation) and MCP solve different problems, so they often work together.

* **RAG** is a pattern for *knowledge*: before answering, the system searches documents (often in a vector database) and adds the relevant passages to the prompt.
* **MCP** is a protocol for *access*: it standardizes how an assistant connects to tools and data sources, including ones that take actions.

A RAG system can even be exposed through an MCP server, so an assistant can search a knowledge base the same way it calls any other tool.

## One server, many APIs: how catalog MCP servers work

Most MCP servers wrap a single product: one for your code repository, one for your calendar, one for your database. That works well for a handful of tools. It gets harder when an assistant needs dozens or hundreds of capabilities, such as file conversion, OCR, email validation, currency rates, and search rankings.

Connecting a separate server for each one brings back a version of the N×M problem: more connectors to install, more keys to manage, and a longer tool list in the model's context. A long tool list has a real cost, because every tool description sits in the model's context, and a model choosing between hundreds of near-identical tools picks less reliably.

Catalog MCP servers take a different approach. Instead of exposing one tool per endpoint, they give the assistant a small, stable set of tools to **search** the catalog by task, **read** the contract for the service it finds, and **run** it. The catalog can grow to thousands of capabilities while the assistant's tool list stays short.

This is how [ApyHub MCP](https://apyhub.com/mcp) works. One connection gives an assistant access to every API in the [ApyHub catalog](https://apyhub.com/catalog), over 1,500 endpoints or capabilities and growing, and every one of them is available through MCP natively, with no wrapper or tool definition to write. In practice, that covers four kinds of work:

* **Reading documents** the model can't read on its own, like [scans, invoices, and PDF tables](https://apyhub.com/catalog?q=document).
* **Checking whether something is real**, such as [VAT numbers, IBANs, and disposable email addresses](https://apyhub.com/catalog?q=validation).
* **Making and converting files**, between [PDF, Word, Excel, and image formats](https://apyhub.com/catalog?q=convert).
* **Looking up live data**, including [exchange rates and search rankings](https://apyhub.com/catalog?q=lookup).

Because every API sits behind one gateway, the assistant uses one scoped key instead of one key per vendor. Every call is priced in atoms, a single usage unit that reflects the work each call performs, so costs are comparable across the catalog. Each service also carries machine-readable certification describing where data is held, how long it is kept, and its alignment with GDPR, SOC 2, and ISO 27001. Teams can choose which APIs their assistants can see, and anything left out stays invisible to the model.

For the technical background on the server, read [ApyHub MCP Server: Native API Discovery and Execution for AI Agents](https://apyhub.com/blog/apyhub-mcp-server-native-api-discovery-and-execution-for-ai-agents).

[**Connect ApyHub MCP →**](https://apyhub.com/mcp)

## Is MCP safe? Security basics

MCP makes it easy to give an assistant real capabilities, which is exactly why security deserves attention. An MCP server can let a model read sensitive data and take real actions.

The [OWASP Top 10 for LLM Applications (2025 edition)](https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf) lists prompt injection as the top risk and names Excessive Agency as another, tracing it to three causes: excessive functionality, excessive permissions, and excessive autonomy. The MCP specification itself says there SHOULD always be a human in the loop with the ability to deny tool invocations.

A few habits cover most of the risk:

1. **Connect only servers you trust.** An MCP server runs code on your behalf. Check who publishes it and what it does with your data.
2. **Expose only the tools a task needs.** Fewer tools means less that can go wrong, and better tool choices by the model.
3. **Keep credentials out of the model's context.** Keys belong in the host or server configuration, scoped as narrowly as possible.
4. **Require approval for high-impact actions.** Reading is low risk. Sending, paying, and deleting should wait for a human yes.
5. **Watch for prompt injection.** Text returned by a tool, such as a web page or a document, can contain instructions meant to manipulate the model. Treat tool output as information to check, and keep instructions coming from you.

## Getting started with MCP

You don't need to write code to try MCP.

1. **Pick an MCP-compatible client.** Claude, ChatGPT, Cursor, VS Code, and Claude Code all support MCP connectors.
2. **Connect a trusted server.** Most remote servers need only a URL and an account. For example, adding ApyHub MCP to Claude Code (EU region) is one command:

bash

```
claude mcp add --transport http apyhub https://mcp.eu.apyhub.com
```

1. **Start with simple requests.** Ask for one thing you already do by hand, such as "convert this Word file to PDF" or "is this VAT number valid?"
2. **Add safeguards as you go.** Review which tools are enabled and which actions need your approval.
3. **Build your own server when you need one.** Official MCP SDKs exist for the major programming languages. If you publish APIs, the ApyHub guide on [designing APIs AI agents can find](https://apyhub.com/blog/how-to-design-apis-to-be-found-by-ai-agents) is a good next read.

For ideas on what to connect first, see [Top 5 APIs Every AI Agent Needs in 2026](https://apyhub.com/blog/top-5-apis-every-ai-agent-needs-2026).

## Conclusion

MCP is the standard way to connect AI assistants to the outside world. Hosts run the model, clients handle connections, and servers describe what outside systems can do through tools, resources, and prompts. It sits on top of APIs rather than replacing them, it complements RAG, and since December 2025 it has a neutral home under the Linux Foundation.

For most teams, the practical questions now are which servers to connect and how to keep them safe. For assistants that need many capabilities, a catalog server keeps the setup to one connection, one key, and one short tool list.

[**Explore the catalog →**](https://apyhub.com/catalog)

## FAQ

**What does MCP stand for?** MCP stands for Model Context Protocol. It is an open standard for connecting AI applications to external tools and data sources.

**What is MCP in AI, in simple terms?** It's a common language that lets AI assistants use outside tools. A service is wrapped in an MCP server once, and any MCP-compatible assistant can then discover and use it.

**What is an MCP server?** An MCP server is a program that wraps an outside system, such as an API, database, or file store, and describes its capabilities in a format AI assistants understand. Servers can run locally on your machine or remotely over the internet.

**Who created MCP, and who owns it now?** Anthropic introduced MCP in November 2024. In December 2025, Anthropic donated it to the Agentic AI Foundation, a directed fund under the Linux Foundation.

**Is MCP open source?** Yes. The specification and official SDKs are open source, and the project is governed under the Linux Foundation.

**What is the difference between MCP and an API?** An API defines how software talks to one specific service. MCP defines how AI applications discover and use capabilities, and most MCP servers wrap existing APIs rather than replacing them.

**What is the difference between MCP and RAG?** RAG retrieves relevant documents and adds them to a model's prompt. MCP standardizes how a model connects to tools and data, including tools that take actions, and a RAG system can itself be exposed through MCP.

**Which AI apps support MCP?** Claude, ChatGPT, Cursor, Gemini, Microsoft Copilot, and Visual Studio Code are among the products that have adopted MCP, and support keeps growing.

**Do I need to code to use MCP?** No. Connecting a remote MCP server usually means copying a URL or a short config block into your AI app's connector settings.

**Is MCP secure?** MCP is as safe as the servers you connect and the permissions you grant. Connect trusted servers, expose only the tools you need, keep credentials out of the model's reach, and require approval for high-impact actions.

## About ApyHub

[ApyHub](https://apyhub.com/) is a curated API catalog and trusted operational layer for developers and AI agents, with over 1,500 endpoints or capabilities and growing. Teams use the whole [catalog](https://apyhub.com/catalog) through a single subscription priced in atoms, a unit that reflects the actual work each call performs. Every endpoint ships with machine-readable certification aligned with GDPR, SOC 2, and ISO 27001, and is MCP-ready by default, so AI agents can discover and call it through [ApyHub MCP](https://apyhub.com/mcp) without custom wrappers. ApyHub is headquartered in Amsterdam, with offices in the Netherlands, Greece, and India, and serves 65,000+ developer workspaces every month. The free Starter plan includes 5 API calls per day and  3,000 atoms per month, with no card required. Building an API of your own? [Become a provider →](https://apyhub.com/become-a-provider)
