MCP is a shared plug standard that lets an AI assistant use your business tools without a custom integration for each one. You connect a CRM, a database or a WordPress site once, as an “MCP server”, and any assistant that speaks the protocol can find and call it. That’s the whole idea.
So if you typed what is MCP model context protocol into a search bar because a vendor keeps saying “we support MCP”, here’s what that claim means for you. It means their AI can reach your tools in a standard way. It doesn’t mean the AI is safe, cheap or useful by default. This guide covers how it works, what it costs, where it breaks, and how to try it in an afternoon.
How MCP works: hosts, clients and servers
Three pieces do the work. The host is the AI app you type into, such as Claude Code, Claude Desktop or VS Code. The server is a small program that wraps one system, like Sentry, a Postgres database or your file system. The client sits inside the host and holds one connection to one server. The official architecture guide puts it plainly: the host creates one client for each server it connects to.
A server offers three kinds of things. Tools are actions the AI can run, such as “create invoice” or “search tickets”. Resources are data it can read, like a file or a database schema. Prompts are saved templates that tell the model how to use the rest.
Under the hood, the messages are JSON-RPC 2.0 (a simple format for “call this function with these inputs, send back the answer”). They travel in one of two ways. Local servers use stdio, which means the host starts the server as a program on your machine and talks to it directly. Remote servers use Streamable HTTP, so the server lives on the web and many people can share it.
Here’s the flow in practice. The host asks each server for its list of tools (tools/list). It hands those tool names and descriptions to the model. When the model decides it needs one, the host sends a tools/call request to the right server and passes the answer back. The model never touches your systems directly. The server does, with whatever access you gave it.
Why a protocol beat one-off integrations
Before MCP, every AI app needed its own connector for every tool. Ten apps and fifty tools meant up to 500 custom pieces of glue code, each one breaking on its own schedule. Anthropic’s launch post from November 25, 2024 named the problem directly: every new data source needed its own custom build, which made connected systems hard to scale.
The launch shipped a spec, SDKs and ready-made servers for Google Drive, Slack, GitHub, Git, Postgres and Puppeteer. Block and Apollo were early adopters, and Zed, Replit, Codeium and Sourcegraph were working on support.
What turned it from one vendor’s idea into a standard was neutral ownership. On December 9, 2025, Anthropic handed MCP to the Agentic AI Foundation, a fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI. Google, Microsoft, AWS, Cloudflare and Bloomberg back it. The same post counted over 97 million monthly SDK downloads and 10,000 active servers at the time.
That matters to a buyer for one reason. You aren’t betting on a single company’s format. If you build an MCP server for your internal tools today, it should work with Claude, ChatGPT and whatever comes next, because they’re all reading the same spec.
MCP vs a plain API vs function calling
People mix these three up, and vendors don’t help. An API is the door a system already has, like Stripe’s REST API. Function calling is a model feature: you describe a function in your own code, and the model asks you to run it. MCP sits on top of both. It’s a standard way to package APIs as tools so any compatible AI app can discover them at runtime, with no code changes on the app side.
| Approach | Who wires it up | Works across AI apps? | Best for | Main catch |
|---|---|---|---|---|
| Direct API call (in n8n, Make or code) | You, once per workflow | No, it’s tied to that workflow | Fixed, repeatable steps such as “new order, create invoice” | No AI judgment unless you add it |
| Function calling | A developer, inside one app | No, each app redefines its functions | A single custom AI app with a few actions | Rebuilt for every new app or model vendor |
| Local MCP server (stdio) | You install it on your machine | Yes, any MCP host on that machine | Files, local databases, developer tools | Runs with your own permissions |
| Remote MCP server (Streamable HTTP) | The vendor or your team hosts it | Yes, any MCP host with the URL and login | SaaS tools shared across a team | You trust the host with data and actions |
Our rule of thumb is simple. If the steps never change, call the API directly from a workflow tool. It’s cheaper, faster and easier to debug. Reach for MCP when a person or an agent needs to decide which tool to use, in what order, based on a messy request. That’s the job it was built for, and it’s the heart of any agentic workflow.
Who should care about MCP right now, and who can ignore it
You should care if your team already uses an AI assistant daily and keeps pasting data into it by hand. Copying rows from a CRM into a chat window is the clearest sign MCP would help. The same goes for agencies building agents for clients: MCP lets you build the connector once and reuse it in Claude, ChatGPT or an n8n agent.
Software sellers have a reason too. Buyers will start asking “do you have an MCP server?” the way they asked “do you have an API?” ten years ago. A read-only server for your product is a modest project and a real sales answer.
It’s safe to ignore MCP for now if your automations are fixed, rule-based flows that already run fine in Zapier, Make or n8n. Swapping them to MCP adds model costs and uncertainty for no gain. The same applies if nobody on the team uses an AI assistant yet. Start with the assistant. The plumbing comes after.
One honest limit: MCP makes connections easy, not good. An agent with ten connected tools and a vague goal still makes poor choices. How well it does depends on the model, the tool descriptions and how you manage agent memory and context, not on the protocol.
Connect your first MCP server in about 15 minutes
The quickest way to see MCP work is Claude Code, Anthropic’s terminal assistant. The Claude Code MCP docs show one command per server. A remote server takes a name and a URL:
claude mcp add --transport http notion https://mcp.notion.com/mcpA local server takes a name and the command that starts it. Everything after the -- goes to the server unchanged:
claude mcp add --env AIRTABLE_API_KEY=YOUR_KEY --transport stdio airtable \
-- npx -y airtable-mcp-serverNext, check the connection. Run claude mcp list in the terminal, then type /mcp inside a session to see status and log in to servers that use OAuth (the “Sign in with Google” style login).
To share a server with your team, add --scope project. That writes a .mcp.json file into the project, which you commit to git. Keep secrets out of it with variables:
{
"mcpServers": {
"api-server": {
"type": "http",
"url": "${API_BASE_URL:-https://api.example.com}/mcp",
"headers": {
"Authorization": "Bearer ${API_KEY}"
}
}
}
}Before you trust any server, open it in the MCP Inspector, the official testing tool. It lists every tool and lets you call one by hand, so you see exactly what the AI will see:
npx @modelcontextprotocol/inspectorIf you’d rather not touch a terminal, n8n has both directions covered. Its MCP Client Tool node lets an n8n agent use an outside server, with a “Selected” option so you expose only the tools you pick. The MCP Server Trigger node does the reverse and turns your n8n workflows into tools other assistants can call.
What changed in the 2026-07-28 spec
MCP has dated versions, and the latest one changed a lot under the hood. The 2026-07-28 changelog makes the protocol stateless. In plain terms, the server no longer has to remember who you are between calls. Every request carries its protocol version and the client’s capabilities, and the old start-up handshake is gone.
A new server/discover call replaces that handshake. Any client can ask a server which versions and features it supports before doing anything else. The same release deprecated three older features (Sampling, Roots and Logging) and confirmed the old HTTP+SSE transport is on its way out in favor of Streamable HTTP.
Why should a non-developer care? Two reasons. First, stateless servers are much easier to host. They can sit behind a normal load balancer and scale like any web app, which should make vendor-hosted servers cheaper and more reliable. Second, the release adopted a deprecation policy with a minimum twelve-month window, so features don’t vanish overnight.
The practical advice: when a vendor says “we support MCP”, ask which spec version. A server stuck on the old SSE transport still works with many hosts today, but it’s a sign the vendor isn’t keeping up. Claude Code, for example, now tries HTTP first and falls back to SSE only when a server refuses.
What MCP really costs a small team
The protocol is free and open source. The bill shows up in three other places: model tokens, platform tasks and setup time.
Tokens are the small chunks of text AI models read and charge by. Every connected tool’s name and description gets read by the model, and every tool result passes back through it.
Anthropic’s own engineers showed how fast that adds up. In their code execution write-up, one workflow fell from 150,000 tokens to 2,000 once the agent loaded only the tools it needed and filtered data before the model saw it. That’s a 98.7% cut.
Claude Code guards against runaway results too: it warns at 10,000 tokens of tool output and caps it at 25,000 by default.
Platform tasks apply if you go through an automation platform. Zapier’s MCP docs say each successful tool call uses two tasks from your plan, and failed calls use none. Their own example, finding a HubSpot contact and emailing them through Gmail, is two calls and four tasks.
Here’s a worked example, with the volume as our assumption. Picture a 10-person agency where each person asks an assistant for 4 CRM lookups or updates a day. That’s 40 calls a day. Over 22 working days, it’s 880 calls, which is 1,760 Zapier tasks a month (880 × 2).
Compare that with your plan’s allowance in our n8n vs Zapier vs Make cost breakdown before you switch it on. Self-hosted servers skip the task fee but add hosting and someone to maintain them.
Setup time is the cost people forget. Connecting an existing vendor server takes minutes. Writing your own server for an internal system is a small software project with testing, logins and updates.
The security risks an MCP server brings in
Every MCP server is code that can act on your behalf, so treat it like hiring a contractor with a key to the office. The risks are specific and well documented.
Tool poisoning comes first. On April 1, 2025, Invariant Labs showed a harmless-looking “add” tool whose hidden description told the model to read a user’s SSH keys and MCP config, then slip them out through an extra field. The user saw only a sum. The same post described “rug pulls”, where a server changes a tool’s description after you approved it, and “shadowing”, where one server’s tool quietly changes how the agent uses another, trusted tool.
The official security best practices add more. A server must not accept tokens that weren’t issued to it, a pattern the spec calls token passthrough. Local servers run with your own permissions, so a bad install command can read anything you can. And broad scopes like “full access” turn one leaked token into a much bigger problem.
What would we do? Use servers from the vendor whose data it is, or ones you’ve read. Start every new server read-only. Expose only the tools a job needs. Keep a person approving anything that sends, deletes or pays, as we explain in our guide to human-in-the-loop for agentic AI. OpenAI takes the same line: in its Responses API MCP guide, approvals are on by default and an allowed_tools setting limits what gets imported.
MCP mistakes that cost money or data
Most MCP trouble comes from a short list of habits. None of them are exotic.
- Connecting everything at once. Ten servers means dozens of tool descriptions in every request. The model gets slower, pricier and more confused. Connect what today’s task needs and remove the rest.
- Installing community servers blind. A one-line
npxcommand runs someone else’s code on your laptop. Read the repo, or test it in the Inspector first. - Giving write access on day one. Let the agent read your CRM for a week before it can edit records. You’ll learn how it behaves when mistakes cost nothing.
- Pasting API keys into shared config. A committed
.mcp.jsonwith a real key is a leaked key. Use${VAR}placeholders and keep the values in your environment. - Using MCP for fixed workflows. If the steps never change, a plain workflow in n8n or Make is cheaper and won’t improvise. Save MCP for work that needs judgment.
- Never checking what changed. Servers update. Re-run the Inspector after updates and compare the tool list, which is your only defence against a quiet rug pull.
The common thread is control. MCP removes friction, and friction was doing some of your security work. Put it back on purpose, with approvals and small tool lists.
A real example: this blog’s own WordPress MCP endpoint
We checked our own site while writing this. Thinkpeak.ai runs WordPress, and its public REST index at /wp-json/ lists an mcp namespace next to wp-abilities/v1. Under it sits /wp-json/mcp/mcp-adapter-default-server. When we sent a request without logging in, it answered with HTTP 401, meaning “not authorised”. That’s exactly what you want to see.
This comes from the official WordPress MCP Adapter. It builds on the Abilities API, which arrived in WordPress 6.9. According to the WordPress developer blog, the default server exposes three tools: discover abilities, get ability info and execute ability. Abilities stay private unless a plugin marks them public.
Connecting it to Claude Desktop or Claude Code over HTTP uses a small Node proxy and a WordPress application password (a separate password just for apps, which you can revoke any time):
{
"mcpServers": {
"wordpress-mcp-server": {
"command": "npx",
"args": ["-y", "@automattic/mcp-wordpress-remote@latest"],
"env": {
"WP_API_URL": "https://yoursite.example/wp-json/mcp/mcp-adapter-default-server",
"WP_API_USERNAME": "admin",
"WP_API_PASSWORD": "your-application-password"
}
}
}
}A small honesty note. This blog is written by scheduled Claude Code sessions working from a git repo, and they publish through the plain WordPress REST API, not MCP. Why? The job is fixed: write, check, post. A direct API call does that with fewer moving parts. We’d reach for the MCP endpoint when a person wants to ask an assistant loose questions about the site.
When MCP is the wrong tool
MCP is a connector standard, and some jobs don’t need a connector that thinks. Here’s how we’d choose.
For scheduled, rule-based automations, stay with a workflow tool. “Every Monday, pull last week’s invoices and post a summary to Slack” has no decisions in it. n8n, Make or Zapier will run it the same way every time and cost less per run.
Building one internal app with a fixed set of actions? Plain function calling is often enough. If only one product will ever use those actions, the cross-app benefit of MCP never shows up.
Heavy data jobs, like moving 50,000 rows between systems, should skip the model entirely. Pushing big payloads through an AI’s context is slow and expensive, as Anthropic’s own token numbers above show. Use a script or an ETL tool (software built to copy data between systems).
Coding agents that need repeatable procedures may be better served by Claude Code’s own extension points than by another server. Our comparison of Claude Code hooks, skills and subagents covers when each one wins. MCP is right when the agent must reach a system outside its own machine.
MCP readiness checklist
Run through this before you connect a server to anything that matters. If you can’t tick an item, fix that first.
- You can name the task the server is for, in one sentence.
- The server comes from the system’s vendor, or someone on your team has read its code.
- You opened it in the MCP Inspector and reviewed every tool description.
- Only the tools that task needs are enabled, using allow lists where the host supports them.
- It starts read-only, and any write, send or delete action needs a human to approve it.
- Credentials sit in environment variables or a secrets store, never in a committed file.
- The login is scoped to the least access that works, with a separate key you can revoke.
- You know the cost per call: tokens, platform tasks, or hosting.
- Someone owns updates and re-checks the tool list after each one.
- The vendor states which MCP spec version it supports, ideally the current one.
Ten ticks means you’re ready for a pilot. Fewer than seven means you’d be handing an AI a key before you know which doors it opens.
FAQ
Is MCP free to use?
Yes, the protocol, SDKs and reference servers are open source. You pay for the parts around it: the AI model’s tokens, any automation platform’s tasks, and hosting if you run your own server. Some vendor servers also need a paid plan of that vendor’s product.
Who owns the Model Context Protocol now?
Anthropic created it, then donated it to the Agentic AI Foundation in December 2025. That foundation is a directed fund under the Linux Foundation, co-founded by Anthropic, Block and OpenAI. No single AI company controls the spec anymore.
Does ChatGPT support MCP?
OpenAI’s Responses API has a built-in MCP tool that connects to remote servers over Streamable HTTP or the older HTTP/SSE transport. Approvals are on by default. Check OpenAI’s docs for which ChatGPT plans and models expose it in the app itself, since that changes often.
Do I need to code to use MCP?
Not to use existing servers. Claude Desktop, Claude Code and n8n can connect to a vendor’s server with a URL and a login, or a short config file. Writing your own server for an internal system does need a developer.
Is there an official list of MCP servers?
Yes. The official MCP Registry launched in preview on September 8, 2025, as a public catalogue of servers. Being listed isn’t a security review, so still vet a server before you connect it.
