Who created MCP, and is it really open?

Anthropic designed and open-sourced MCP in November 2024, publishing the full specification, SDKs in multiple languages, and a repository of reference servers (Source: Anthropic, 2024). Anyone can build a client or server against the spec for free, with no approval process. Other AI applications, including ChatGPT and several code editors, have since adopted it too.

What's the difference between a tool, a resource, and a prompt in MCP?

These are MCP's three server-side building blocks. A tool is an action the agent can call, like sending a message or starting a process. A resource is data the agent can read, like a file's contents or a database row. A prompt is a reusable template — a pre-written starting point for a specific kind of task.

Does an MCP server need an internet connection?

Not necessarily. A local server using the stdio transport runs as a process on your own machine and talks to the AI app over standard input and output, with no network port involved at all. Only remote servers, the kind that connect to a cloud service like Slack or a hosted database, use an HTTP connection over the internet.

Can more than one MCP server run at the same time?

Yes, this is normal, not an edge case. An AI application opens one MCP client per server it's connected to, so a single Claude Code session might run a filesystem server, a GitHub server, and a database server simultaneously, each with its own connection and its own set of tools.

Is an MCP server the same thing as a plugin?

Close, but not quite. A traditional plugin is usually built for one specific application's own extension format. An MCP server is built once against a shared, open protocol, so the same server works unmodified across any application that speaks MCP: Claude Code, Claude Desktop, Cursor, VS Code, and others.

Do I need to know how to code to use an MCP server?

No, not to install and use one that already exists — that's typically one command plus, for shared or unfamiliar servers, an approval prompt. You only need to write code if you're building a new server yourself, which means implementing the tools you want to expose and wiring them to whatever system they control.

Can an MCP server see everything on my computer?

Only what you and your operating system let it see. A local server runs with the permissions of the process that starts it, same as any other program you install; it isn't sandboxed by MCP itself. That's exactly why approval prompts, scoped folders, and reading a server's source before you trust it all matter.

MCP Explained (For People Who Just Want More)

MCP, the Model Context Protocol, is an open standard, published by Anthropic in November 2024, that lets an AI agent connect to real tools and data instead of only reading and writing text. A small program called an MCP server exposes a fixed set of actions; your agent calls them the way it calls any other tool, and the server does the actual work.

Updated August 2026: MCP has gone from one company's announcement to something Claude, ChatGPT, and a growing list of editors and IDEs all speak natively, which is why it's worth understanding on its own terms and not just as a Claude Code feature. The idea stays simple even where the spec gets detailed: give the model hands, on your terms.

What is MCP?

MCP is a set of rules, not a product, for how an AI application talks to an outside program. One side runs an MCP client inside the AI app (Claude Code, Claude Desktop, Cursor); the other runs an MCP server exposing tools, data ("resources"), or reusable prompt templates over JSON-RPC 2.0 messages.

The "client" part is invisible to you as a user. Every time you connect a server, the AI app quietly opens a dedicated client for it behind the scenes, so a session with five servers connected is really running five separate client-server conversations at once. What differs server to server is mostly where it runs and how the two sides reach each other:

Transport	Where it runs	Typical use
stdio (standard input/output)	A local process on your own machine	Tools needing direct system access — files, local apps, shell commands
Streamable HTTP	A remote server over the network	Cloud services — a hosted database, Slack, GitHub

Both transports carry the exact same message format underneath. A local filesystem server and a remote Slack server are speaking the identical protocol; only the pipe between them is different.

What problem does it solve?

Before MCP, every agent-to-tool connection was a one-off integration — a custom plugin for Slack, another for GitHub, another for your database, each written to one AI app's own format. MCP standardizes that connection once: any MCP-speaking agent can use any MCP server without custom glue code.

That's the practical shift underneath the "give it hands" framing: instead of every AI application building its own bespoke connector for every tool it wants to reach, tool builders write one server against a shared spec, and every MCP-compatible application can use it immediately. It's the same logic that gives one USB-C cable a shot at charging your laptop, your headphones, and your phone.

Anthropic's own launch bundled six ready-made connectors — Google Drive, Slack, GitHub, Git, Postgres, and Puppeteer — when it published the protocol on November 25, 2024 (Source: Anthropic, 2024). That's the concrete size of "solving this once": six integrations that used to require six separate custom builds, published on day one as a single open spec. This is one piece of the wider vibe coding workflow: describing what you want and generating it is only half the loop, and MCP is largely what lets the "look at it and react" half reach outside the chat window.

What does a server actually do?

A server does three things on every tool call: it validates the request against the JSON Schema it declared for that tool, it does or delegates the actual work — reading a file, hitting an API, controlling a local app — and it hands the result back as a plain content block Claude can read, usually just text or JSON.

Here's what that looks like end to end, drawn from a real, shipping MCP server built for a desktop app. The server is a short script the AI app launches as a subprocess over stdio. It imports an MCP SDK that supplies two building blocks — a server object and a transport — so the developer's own job is just registering tools; none of the JSON-RPC wiring is hand-rolled.

Each tool registration is three pieces: a name Claude will call it by, a description written for the model, not the person using it (Claude reads that text to decide whether this tool is the right one for the current request), and a schema for its inputs, usually written with a validation library instead of hand-typed JSON Schema.

In the server this section is grounded in, that pattern repeats five times: start a recording, stop it, check whether one is running, list past recordings, and fetch a finished recording's write-up. None of those five handlers does the underlying work itself. Each one reads a small file the desktop app writes to disk, containing a local port number and an access token, and — if that file exists — makes an authenticated request to the app's own local API and returns the JSON response as a text block. If the file is missing, the tool returns a plain sentence saying the app isn't open, instead of a raw connection error the model would have to interpret on its own.

Strip away the specifics and almost every MCP server does the same four things:

Declares its tools — name, description, and input schema — when a client connects.
Waits for a tools/call request naming one of them.
Validates the input, then does the work directly or forwards it to whatever system it fronts.
Returns the result as a content block — text, an image, or a resource link — that the model reads like any other tool output.

How do you install one?

Installing an MCP server usually takes one command and, for anything you didn't build yourself, an approval step. In Claude Code, claude mcp add registers a remote server by URL or a local one by the command that starts it; you then pick where the configuration lives: your own project, shared with your team, or every project on your machine.

Pick a server. Remote, reachable over HTTP, or local, running as a process your machine starts.
Add it with one command. claude mcp add --transport http <name> <url> for a remote server, or claude mcp add --transport stdio <name> -- <command> for a local one. Other AI apps use their own equivalent — a settings panel or a JSON config file that means the same thing.
Choose a scope. Local (this project only, private to you, the default), project (checked into the repo and shared with your team), or user (every project on your machine).
Approve it. A server that arrived with someone else's project rather than one you added yourself has to be reviewed and approved before it's allowed to run (Source: Claude Code documentation, 2026).
Confirm it connected. A list or status command shows each server as connected, needing authentication, or failed, so a broken server doesn't fail silently in the background.

What can go wrong?

MCP servers run with real permissions, and Claude decides when to call them, so most problems are trust and scope, not the protocol itself. A local stdio server runs as a process with whatever access you gave it. A tool's description can mislead the model into calling it wrongly. Claude Code asks for approval before running a server you didn't set up yourself.

A few specific failure modes are worth knowing before you go install ten servers at once:

Over-scoped access. A filesystem server pointed at your whole home directory can do more than the task needs; pointing it at one project folder is the safer default.
Descriptions are untrusted input, too. The model reads a tool's description to decide when to call it, so a poorly or maliciously written description can talk it into calling that tool when it shouldn't — not a hypothetical, just the reason project-scoped servers get an approval prompt.
Auth, not the protocol, usually breaks first. A remote server's OAuth token or bearer credential expires or gets revoked; a "failed" status in your server list is almost always that, not a bug in MCP itself.
Local processes can just crash. A stdio server is a normal program; if it dies, nothing about MCP resurrects it, which is why checking connection status after any change is worth the ten seconds.

What's worth installing first?

Start with something that removes real copy-pasting from your day: a filesystem or Git server so Claude can read your repo directly, GitHub for issues and pull requests, and a web-fetch server for pulling in a page instead of pasting it in. Add narrower tools once you know what you keep re-explaining by hand.

A reasonable starter set:

Filesystem — the agent reads and writes files in a folder you specify directly, instead of you pasting code back and forth.
Git or GitHub — it sees commit history, opens issues, and reviews pull requests on its own.
A web-fetch or search server — it pulls in a page instead of you copying the text over by hand.
Slack — worth it once a meaningful share of your context lives in channel history.
Whatever database you already query by hand — Postgres and similar servers exist for exactly this.

Add narrower tools once a real gap shows up. One example built on exactly the request-and-bridge pattern described earlier is Walkie, a screen-and-voice recorder for reviewing AI-generated code: its MCP server exposes five tools — start a recording, stop it, check status, list past recordings, fetch a finished review — that forward to the desktop app's own local API, the same shape as the walkthrough above. If you're weighing that kind of feedback tool against the alternatives, a fair, priced comparison covers where it fits and where a free screenshot is still the better answer, and the review bundle format it hands back is documented on its own. You can see the product itself here.

The fastest way to understand any of this is to install one server and watch what changes. Open your AI app's MCP settings, add the filesystem server for a project you're already in, and ask it to do something that used to mean pasting a file into chat. Everything else here is detail on top of that one loop.