picture a wall socket. you don't think about which power station the electricity came from, or whether your laptop charger speaks the same language as your kettle. you plug things in. they work. that's the entire pitch of mcp.
the model context protocol is the wall socket between ai assistants (claude, chatgpt, cursor, whatever your team is using) and the actual stuff you want them to touch: your gmail, your shopify store, your github repo, that postgres database with the orders table. before mcp, every one of those connections was a one-off. every time a developer wanted an ai application to query a postgres database, they wrote a custom integration. when the same app needed slack access, they wrote another. each integration was tightly coupled to both the specific ai model's api format and the external tool's unique interface.
now imagine you have three ai tools and ten apps you want them to use. that's thirty bespoke pieces of code to write and maintain. mcp collapses that n×m matrix to n + m: each ai client implements mcp once, each data source implements mcp once, and any client can reach any server. the wall socket.
who made it and why anyone trusts it
anthropic, the company behind claude, released mcp in november 2024. that part matters less than what happened next. following its announcement, the protocol was adopted by major ai providers, including openai and google deepmind. openai folded it into the chatgpt desktop app. google followed. then, in december 2025, anthropic donated mcp to the agentic ai foundation (aaif) under the linux foundation, giving it the same neutral governance model as kubernetes and linux.
that last bit is what turned mcp from "vendor flavour of the month" into infrastructure you can actually build on without worrying it'll get yanked. it's now governed the same way the software running 80% of the cloud is governed. boring, in the good way.
the adoption numbers are the part that should make a non-technical reader pay attention. monthly sdk downloads went from ~100,000 in november 2024 to 97 million in march 2026 according to the official mcp anniversary report. a 970x jump in sixteen months. nothing in developer tooling moves that fast unless it's solving a real problem.
the three things in the room
every mcp setup has three pieces. the names are unfortunate but you need them.
- host: the ai app you actually talk to. claude desktop, cursor, the chatgpt desktop client. the host manages the llm's context window, decides when to invoke tools, routes user messages to the model, and feeds tool outputs back into the conversation. in plain terms, the host is the "conversation controller".
- client: lives inside the host. one client per server. it's the translator. you don't see it.
- server: a small program that exposes one thing. a "gmail server" knows how to read and send mail. a "stripe server" knows how to look up payments. the server is a lightweight process that wraps a specific tool or data source and exposes it through the mcp protocol. a postgres mcp server, for example, accepts structured queries from any mcp client, translates them into sql, executes them against the database, and returns formatted results. the server never communicates directly with the llm — all interaction is mediated by the client.
the useful mental shortcut: the host is the chat window, the server is the thing the chat window can now reach. everything else is plumbing.
a server can expose three kinds of things. tools are functions that the ai model can invoke: query a database, send an email, create a github issue, call a weather api. tools are model-controlled, meaning the ai model decides when and how to call them based on the user's request and the tool's description. resources, by contrast, are data the model can read. file contents, database records, api responses, and configuration data all qualify. resources are identified by uris and are typically application-controlled, meaning the host or user determines when to include them in context. the third is prompt templates, which matter less for this conversation.
the distinction between tools and resources is the one most people miss. tools are verbs the model can do. resources are nouns the model can read. if you remember nothing else, remember that.
setting one up, for real
let's say you have claude desktop and you want it to read files on your computer. this is the canonical first-mcp-server thing to do. here's what actually happens.
claude desktop reads a single config file. claude desktop reads its mcp configuration from claude_desktop_config.json. the location depends on your os. if the file does not exist, create it. on a mac it sits at ~/library/application support/claude/. on windows, %appdata%\claude\.
you open it, drop in a small json block telling claude what server to launch and where, save, and then — this is the part everyone forgets — close claude desktop completely (not minimize, quit). on macos: cmd+q. on windows: right-click the system tray icon and select quit. then reopen it. if you just close the window, nothing reloads.
if it worked, you should see a hammer icon with a number indicating how many tools are available. click it to see the list. that hammer is the dial tone. if it's there, you're connected.
for anyone allergic to editing json, anthropic shipped a better path. desktop extensions provide a streamlined way to install and manage local mcp servers through single-click installable packages. instead of manually configuring json files and managing dependencies, you can now install local mcp servers on your computer as easily as browser extensions. you go to settings, browse a directory, click install. done. no terminal.
three things will trip you up the first time. they always do.
- path problems. claude desktop launches your config with a minimal path, so short names like npx or docker often fail even when they work in your terminal. use the full path. which npx in a terminal will tell you what it is.
- json syntax. one missing comma silently disables every server you have configured. paste your file into any json validator before you wonder why nothing works.
- secrets in plain text. api keys go in the config file. api keys in the config file are stored in plain text, keep the file readable only by your user. this is fine for your laptop. it is not fine for a shared machine.
what to look for before you install one
mcp servers are software running on your computer with your permissions, talking to ai models on your behalf. that should make you at least mildly cautious. the protocol is good. some of the servers people are shipping are not.
in april 2025, security researchers released an analysis that concluded there are multiple outstanding security issues with mcp, including prompt injection, tool permissions that allow for combining tools to exfiltrate data, and lookalike tools that can silently replace trusted ones. none of those are theoretical. all of them have been demonstrated.
three filters before installing any mcp server:
- who published it. official servers from anthropic, github, stripe, supabase: fine. random github repo with 12 stars: not fine. treat them like browser extensions, because that's the threat model.
- what permissions it wants. a "filesystem" server that wants access to your entire home directory is doing too much. point it at one folder. start narrow.
- start read-only. start with read-only servers (toolradar, brave search) before adding servers with write access (github, filesystem). the worst a read-only server can do is leak data. a server with write access can also break things.
one more thing worth saying plainly: most mcp servers expose raw data, not governed context. the protocol enables quality; it does not enforce it. mcp gives the model a door. what's on the other side of the door is still your problem. if your underlying database is messy, exposing it via mcp doesn't make the answers cleaner. it just makes the mess reachable.
the honest version
mcp is not magic. it's a wire protocol. mcp does not replace function calling — it standardizes it. function calling remains the underlying mechanism by which llms invoke tools. mcp wraps that mechanism in a universal, discoverable protocol so that tool definitions, capabilities, and authentication flow consistently across all compatible systems.
what it actually buys you is leverage. one server, every assistant. write the gmail integration once, and your team can use it from claude, chatgpt, cursor, and whatever ships next quarter without you touching a thing. that's the whole point.
if you're a founder or operator reading this, the practical takeaway is small: ask whoever runs your tooling if your most-used internal systems have an mcp server. if the answer is yes, you're three clicks away from having an assistant that can actually do work in those systems. if the answer is no, that's a sensible next thing to build. build one mcp server. that single investment makes your product compatible with the entire ecosystem of enterprise ai tools overnight.
the wall socket was boring. then it was everywhere. mcp is on the same trajectory, just faster.