An MCP server is a running program that exposes one system's capabilities to AI applications through the Model Context Protocol, an open specification. MCP is the spec; a server is an implementation of it.
A server exposes exactly three primitives: tools, which are actions the model can call; resources, which are data it can read; and prompts, which are templates. The spec's own table assigns control: tools are model-controlled, resources are application-controlled, and prompts are user-controlled.
Most of the web explains the benefits of MCP servers. Almost nobody explains what a server costs you per step, or how to tell whether you need one at all. We build ego (lite), which takes the CLI route and is not an MCP server, so this article looks at the tradeoffs from the other side.
What an MCP server is (and what MCP is)
MCP stands for Model Context Protocol. It is an open specification. An MCP server is a running program that exposes one system's capabilities to AI applications through that spec. MCP is the spec. A server is an implementation of it.
The acronym is overloaded. In other contexts, MCP also stands for Multi-Cloud Platform and Modular Control Plane. Neither of those is this. This article is about the Model Context Protocol.
Host, client, server: who is who
Three roles appear in every MCP setup: host, client, and server. The host is the application the user interacts with, such as a chat app or an IDE. The client is the component inside the host that speaks the protocol. The server is the program that exposes capabilities.
The connection between a server and a client is one to one. One server connects to one client. The host application can run many clients, so a single host can connect to many servers at once. The 1:1 rule applies at the server-to-client link, not at the host level.
Tools, resources, prompts, and who controls each
A server exposes exactly three primitives: tools, resources, and prompts. Tools are actions the model can call. Resources are data it can read. Prompts are templates.
The spec's own table assigns control for each primitive. Tools are model-controlled. Resources are application-controlled. Prompts are user-controlled. That control column is part of the specification, not a convention layered on top.
Is an MCP server just an API?
No. An MCP server is not just an API, and it is not an API for AI. Underneath, you are still writing an API. The real dividing line is runtime discovery. With a plain API, the caller must know in advance which endpoints exist and what they do. With MCP, the client does not need to know in advance which capabilities exist. It discovers them at runtime.
This does not make MCP better than an API. They sit at different layers. The API is the underlying interface. MCP is a specification for describing and discovering that interface at runtime. You still write the API. MCP adds a discovery layer on top.
What runtime discovery actually buys you
Runtime discovery means the client can ask a server what it offers instead of being hardcoded to a fixed list. The client does not need to know in advance which capabilities exist. It learns them when it connects.
The Language Server Protocol solved the same N x M problem the same way. One spec, JSON-RPC, so M editors did not each need N plugins. MCP applies that pattern to AI applications and the systems they connect to.
Where it is still just an API underneath
Underneath the discovery layer, an MCP server is still an API. You define the operations, handle the inputs, and return the outputs. The protocol does not remove that work. It standardizes how those operations are described and found at runtime.
What an MCP server actually does, step by step
An MCP server is a running program that exposes one system's capabilities to AI applications through the Model Context Protocol. MCP is the specification. A server is an implementation of it. The server exposes exactly three primitives: tools, which are actions the model can call; resources, which are data it can read; and prompts, which are templates. The spec's own table assigns control: tools are model-controlled, resources are application-controlled, and prompts are user-controlled.
One server connects to one client. The host application can run many clients. The real dividing line between an MCP server and a plain API is runtime discovery. The client does not need to know in advance which capabilities exist. Underneath, you are still writing an API. The precedent is the Language Server Protocol, which solved the same N by M problem the same way, with one spec and JSON-RPC, so M editors did not each need N plugins. Note that "MCP" is also used for Multi-Cloud Platform and Modular Control Plane. Neither is this.
Discovery handshake, tool call, result
The first step is discovery. The client connects to the server and asks what it can do. The server returns its list of tools, resources, and prompts. The client does not need prior knowledge of those capabilities. This is the handshake that separates MCP from a fixed API integration.
The second step is a tool call. The model selects a tool from the discovered list and the client sends the call to the server. The server executes the action and returns a result. The result goes back to the model through the client. The protocol layer does not guarantee that a human approves the call before it happens. Human confirmation before a tool call is a client UX convention, not a protocol guarantee.
Local stdio versus remote Streamable HTTP
MCP defines two transports. stdio is for local servers. Streamable HTTP is for remote servers. The older HTTP+SSE transport has been superseded, and a large share of tutorials online still teach it. If you are following a guide that uses HTTP+SSE, you are reading outdated material.
The 2026-07-28 spec revision removed protocol-level session tracking. The protocol layer is now stateless. The same revision deprecated sampling and roots. Deprecated features are kept at least 12 months. Some changes are not backward compatible. Check the spec revision your server targets before you install it.
Are MCP servers safe?
Vendor pages tend to answer a different question than the one readers ask. They explain how to harden a server you built. The reader is asking whether it is dangerous to install someone else's. Those are not the same problem, and the second one has fewer clear answers.
The core mental model is this: a tool description is an instruction to the model. When a server exposes a tool, its description enters the model's context and can shape what the model does next. Google Cloud's documentation states: "Developers should not trust tool descriptions unless they come from a reliable server." That applies to descriptions you read as a user, not just ones you write as a developer.
A common claim is that human-in-the-loop approval is always enforced. It is not. Human confirmation before a tool call is a client UX convention, not a protocol guarantee. The spec ships a Security Best Practices document covering confused deputy, token passthrough (explicitly forbidden), session hijacking, and XSS. Those are the protocol's own listed concerns. They are not a complete safety net for third-party code.
The risk is the tool description, not the network
The risk is usually not the network. It is the tool description. Research published in April 2025 (arXiv:2503.23278) showed that prompt injection and poisoned tools can exfiltrate data through other connected tools. The attack does not need to break the transport. It needs the model to treat a description as an instruction.
This is why the Google Cloud guidance matters. If a tool description can direct the model, then a description from an untrusted server is an untrusted instruction. The spec's Security Best Practices document names confused deputy and token passthrough as known patterns. Token passthrough is explicitly forbidden. Even so, the protocol cannot verify intent. That work falls to the client and to you.
What the biggest browser server says about itself
Microsoft's Playwright MCP README, in its Security section, says in full: "Playwright MCP is not a security boundary." That is vendor candor, not an accusation.
The README also tells coding agents they "might benefit from using the CLI+SKILLS instead," because CLI calls "avoid loading large tool schemas and verbose accessibility trees into the model context." The same README is candid that MCP still wins for long-running loops needing persistent browser state. Read the security section before you install any browser server. The vendor has already told you where the boundary is.
Can you give me an example of an MCP server?
The useful way to group MCP server examples is by how much each call hands back. Not alphabetically, not by popularity. Return size is what determines cost, because every token a tool returns is a token the model has to read.
The official MCP registry describes itself as launched in preview on 2025-09-08 and may still make breaking changes or reset data. Treat any list of servers as a snapshot, not a catalog.
Small returns
Ticket trackers, calendars, feature flags. Small schemas, small results. A tool call returns a status, a date, a boolean. The MCP shape is right here: the model discovers the capability at runtime, calls it, and gets back something short enough to reason about.
Medium returns
Databases, repositories, document stores. Results can be large, but they can be filtered server side. The server decides what to return, so a query for one row does not have to ship the table.
Large returns
Browsers, desktops, large tables. Every step returns a whole page. A single complex page snapshot from Playwright MCP can exceed 50,000 tokens. Provar reported one Salesforce accessibility tree at 114K tokens.
This is where the arithmetic starts to reverse. The call is cheap to make and expensive to read. The model pays for the page whether or not the page matters.
Do I need an MCP server?
For most systems, yes. An MCP server gives your agent runtime discovery: the client does not need to know in advance which capabilities exist. Underneath, you are still writing an API, but the agent can find it.
There is one shape of exception, and it is about return size. When every call hands back more than the model needs, the protocol's discovery benefit does not cover the token cost.
When an MCP server is clearly right
Four criteria. First, return size: does a typical call return a status, or a page? Second, can your agent run shell commands? If it can, a CLI may be cheaper than a tool schema. Third, do you trust the source? Google Cloud's documentation states: "Developers should not trust tool descriptions unless they come from a reliable server." Fourth, is this a one-off task or a persistent session?
A one-off task does not need a long-lived connection. A persistent session, where the agent keeps state across many steps, is a different problem.
When the arithmetic flips
Large returns plus an agent that can run shell. Anthropic's article "Code execution with MCP" reports going from 150,000 tokens to 2,000 tokens, which it describes as a 98.7% saving. That number is Anthropic's.
Microsoft's Playwright CLI release reported 114K tokens per test through MCP against 27K through the CLI. Same task, same browser, different transport. The gap is the cost of loading tool schemas and verbose accessibility trees into the model context.
What the protocol's own maintainers recommend instead
Microsoft's Playwright MCP README tells coding agents they "might benefit from using the CLI+SKILLS instead," because CLI calls "avoid loading large tool schemas and verbose accessibility trees into the model context."
The same README is candid that MCP still wins for long-running loops needing persistent browser state. The recommendation is conditional, not absolute.
The honest answer depends on what the server hands back. For a ticket tracker or a feature flag service, an MCP server is exactly the right shape: a few small tool definitions, small results, nothing you would think twice about. Browsers are where the arithmetic flips, because a page is not a row, it is thousands of tokens, returned again on every step. Microsoft's own Playwright MCP README now tells coding agents they "might benefit from using the CLI+SKILLS instead," because CLI calls "avoid loading large tool schemas and verbose accessibility trees into the model context." The same README is candid that MCP still wins for long-running loops that need persistent browser state. We build ego (lite), which takes the CLI route: it is not an MCP server. It is a real Chromium you drive with a shell command, already signed in to the sites you are signed in to, where the agent writes a few lines of JavaScript to do several things on a page in one round trip, in its own Space instead of the tab you are reading.
One boundary worth stating plainly, because it decides the whole question: sites can still ask for a CAPTCHA or another check, and nothing here promises to get around one. What changes is how often a fresh profile triggers them in the first place, so 2FA tends to become a pause you clear once rather than a failure that ends the run.
| If this is your situation | Do not use ego (lite). Use this instead |
|---|---|
| Your agent runs in a host that cannot execute shell commands | An MCP browser server. This is the most common case, and MCP is the right answer for it. |
| Unattended tests in a CI pipeline | Playwright or Puppeteer. ego (lite) has no headless CI mode. |
| Cross-browser checks on Firefox or WebKit | Playwright. We do not do cross-browser testing. |
| Many browsers scaled out on servers with no desktop | Browserbase or another cloud browser service. |
| Static HTML with no login and no interaction | Plain HTTP or a scraping API. Do not start a browser for it. |
| Breakpoints, network waterfalls, performance profiles | Chrome DevTools MCP. ego (lite) has no debugging panel. |
| You are connecting to GitHub, Jira or a database, not a browser | Install that MCP server. This article is not arguing against MCP. |
Is MCP still relevant?
Yes. Adoption is broad and dated. OpenAI adopted MCP in March 2025. ChatGPT apps supported MCP in September 2025. In December 2025 the project was donated to the AAIF, co-founded by Anthropic, Block and OpenAI.
The protocol is also changing, and not everything is backward compatible. The 2026-07-28 spec revision removed protocol-level session tracking, so the protocol layer is now stateless. The same revision deprecated sampling and roots. Deprecated features are kept at least 12 months.
That means a meaningful share of tutorials you find are teaching superseded transports or describing the protocol as stateful when it is not. The older HTTP+SSE transport has been superseded, and many online guides still teach it. Check the date on anything you follow.
Agent Skills is a complementary standard from the same authors, not a replacement for MCP. Anthropic published Agent Skills in December 2025. It sits alongside MCP rather than replacing it.
Does ChatGPT use MCP, and which AI supports it?
Yes. OpenAI adopted MCP in March 2025, and ChatGPT apps supported MCP in September 2025. In December 2025 the project was donated to the AAIF, co-founded by Anthropic, Block and OpenAI.
Support is not limited to one vendor. Anthropic, Block and OpenAI co-founded the AAIF, which now hosts the project. Microsoft ships Playwright MCP, and Google Cloud documents MCP usage. The official MCP registry launched in preview on 2025-09-08 and may still make breaking changes or reset data.
Frequently asked questions
What does MCP stand for?
MCP stands for Model Context Protocol. It is an open specification. An MCP server is a running program that exposes one system's capabilities to AI applications through that spec. The spec is MCP; a server is an implementation.
Is an MCP server just an API?
Underneath, you are still writing an API. The real dividing line versus a plain API is runtime discovery: the client does not need to know in advance which capabilities exist. A server exposes exactly three primitives: tools, resources and prompts.
Are MCP servers safe to install?
Not automatically. The spec ships a Security Best Practices document covering confused deputy, token passthrough (explicitly forbidden), session hijacking and XSS. Research (arXiv:2503.23278, April 2025) showed prompt injection and poisoned tools can exfiltrate data through other connected tools. Google Cloud's documentation states: "Developers should not trust tool descriptions unless they come from a reliable server." Human confirmation before a tool call is a client UX convention, not a protocol guarantee.
Do I need to build my own MCP server?
Not necessarily. One server connects to one client (1:1), and the host application can run many clients. Microsoft's Playwright MCP README tells coding agents they "might benefit from using the CLI+SKILLS instead," because CLI calls "avoid loading large tool schemas and verbose accessibility trees into the model context." The same README is candid that MCP still wins for long-running loops needing persistent browser state.
What is replacing MCP?
Nothing in the verified record replaces MCP. Agent Skills (Anthropic, December 2025) is a complementary standard, not a replacement. The 2026-07-28 spec revision changed MCP itself, removing protocol-level session tracking and deprecating sampling and roots.
