How the pieces fit
A bakery keeps its orders in a database and someone builds an MCP server for it. The AI app you use, a chat or a coding agent, connects to that server. From then on, the model can ask to "find the order for Mrs. Johnson" mid task. The model does not know which orders exist: the server does, and it exposes that tool.
MCP is not a model or a skill. A skill packages instructions for a task, like a recipe; MCP is the connection. And because it is a standard, the server you built is not tied to one app: it works with any that speak MCP, though each may support more or fewer features.
Who created MCP
Anthropic, the company behind Claude, introduced it in November 2024 as an open standard. In December 2025 it donated MCP to the Agentic AI Foundation, under the Linux Foundation, which it co-founded with OpenAI and Block. That is why MCP is not "a Claude thing": competing apps and companies use it.
MCP vs API
An API is the door a system offers to other programs, and the programmer decides what to call and when. An MCP server often sits on top of an API: it describes its actions so the model can understand them and pick one based on what you ask. They do not compete. The bakery MCP server may call its order system API under the hood.
Nor does it replace RAG. RAG searches chunks of documents prepared ahead of time; with MCP the model looks things up or acts on the spot, like checking today's stock. Both can live in the same app.
Tools, resources and prompts
An MCP server can offer three kinds of things, and the way to tell them apart is who controls them. Tools: the model asks for them to look things up or act, like finding an order or creating one. Resources: context the app manages, like the recipe book you attach to the chat. Prompts: templates you pick, like "close the register", so you do not write the same request every night.
These are protocol categories, not a promise about the screen: each app shows them its own way, and some do not show all of them.
MCP server examples
GitHub has an official MCP server so the agent can read issues, review pull requests or search code. Another classic is the filesystem server, which can read and write in the folders you choose. The community has all kinds, even servers for Brazilian public data. Before installing one, check who maintains it and which permissions it asks for.
Local or remote
A local server runs on your machine, for example one that reads a folder in your project. A remote one runs on another server, like a cloud service. The transport, how the app talks to it, is a separate question: MCP defines, for example, stdio (the app starts the server as its own process) and Streamable HTTP. Common mistake: "it uses HTTP, so it is remote". A server on your machine can speak HTTP too.
Many remote servers connect with OAuth: you authorize in the service and the app gets a token with the permissions you granted, not your password. OAuth does not shrink those permissions: if you accepted too much, the token has too much.
Connecting is not authorizing
A server that connects and works only tells you the connection is fine. What limits the agent is the access the server has and the controls in the app, not an instruction like "do not touch anything". If you connect your small business sales sheet just to look things up, give it read only access and test with a read first.
The key goes in a private, unversioned config; if you already pushed it to a repo, revoke it. And do not assume there will be an approval screen: the protocol does not require one, and whether it asks before each action is up to the app. Also watch what the server sends back: a piece of text can carry hidden instructions for the model, and that is prompt injection.