This post was originally published in May 2025. It was updated in June 2026.
Model Context Protocol (MCP) is an open standard that lets AI applications connect to external tools and data through a single interface, enabling a developer to make any service usable by any AI agent without writing a custom integration. Whether you’re evaluating MCP for your own stack or just trying to understand the ecosystem forming around it, this post covers what it is, how it works, and why it matters now.
MCP has become the default way AI tools reach anything outside themselves. Stripe ships an MCP server that lets an agent create customers and generate invoices without leaving the chat; Cloudflare lets developers build and host remote MCP servers on its own network; and Anthropic has handed the protocol to the Linux Foundation, so it belongs to no single vendor.
Retool is part of that ecosystem now, too, with its own MCP server. What that unlocks, and what it looks like when a platform becomes a server rather than just calling one, comes later in this post.
MCP runs on JSON-RPC 2.0, a lightweight protocol that encodes every exchange as a JSON object. Each request names a method and its parameters, and MCP defines the methods that matter for AI work.
A tool call shows the shape of it. The client sends a request naming the tool and the arguments the model chose:
1 2 3 4 5 6 7 8 9{ "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "get_weather", "arguments": { "location": "San Francisco, CA" } } }
The server runs the tool and replies with a result tagged by the same id, so the client knows which request it answers:
1 2 3 4 5 6 7 8 9 10{ "jsonrpc": "2.0", "id": 1, "result": { "content": [ { "type": "text", "text": "64°F and foggy." } ], "isError": false } }
For any developer, this looks a lot like a regular API. MCP is similar, but sits at a different layer and answers a different question. A REST API endpoint documented in OpenAPI tells you exactly what it does: here are the inputs (a customer ID and a date range), here’s the output (a JSON list of that customer’s orders), here’s the route to call (GET /customers/{id}/orders). That's plenty for a developer who already knows when to use it. It says nothing about why the endpoint exists, or when an agent should reach for it instead of a dozen others.
MCP adds that missing layer in the same object. A client and an MCP server start by negotiating capabilities, and from there, the client can discover what a server offers and act on it:
tools/listandtools/callto find and invoke toolsresources/listandresources/readto pull in data the model can use as context
When a client asks a server what it offers, each tool comes back not just with a name and an input schema but with a description written for both a person and a model:
1 2 3 4 5 6 7 8 9 10 11 12 13 14{ "name": "get_weather", "description": "Get current weather conditions for a location. Use this for present-moment conditions like temperature and sky state. For multi-day outlooks, use get_forecast instead.", "inputSchema": { "type": "object", "properties": { "location": { "type": "string", "description": "City and state, or city and country. Example: 'San Francisco, CA'." } }, "required": ["location"] } }
The description is the half that matters for selection: what the tool is for, when it’s the right choice, and when to reach for a different one. That’s the judgment a developer would otherwise keep in their head, now written where the agent can read it while it’s deciding what to call. It’s what lets an agent pick tools on its own rather than being told which endpoint to hit.
Why does a client need this extra information? The answer is context.
AI agents crave context. They want to understand the best way to grab data, trigger a workflow, and update a record. That context is implicit for human developers—they understand a REST API because they have read the docs, implemented the call, and gone through the errors. AI lacks that context, so MCP servers provide it.
There’s a classic example implementation of the OpenAPI spec that documents a hypothetical REST-based API for a Pet Store's inventory and order management. A developer might skim it and pull out the endpoints they need:
GET /pet/findByStatusto find what's availableGET /pet/{petId}to pull a specific item's detailsPOST /store/orderto place an orderGET /store/order/{orderId}to confirm it went through
An MCP implementation would take that same sequence and hand the agent the part the developer kept in their head. The server bundles find, order, and confirm into one described capability. So when you tell your assistant the dog food’s running low and you want it every month, it doesn’t reconstruct the sequence of calls. It reaches for that one tool and sets up the order, never touching the four endpoints beneath.
To bring it closer to home, picture asking your assistant why a Retool workflow that had run cleanly for months started failing last week. An MCP server that describes those tools, what each is for, and the order they belong in, lets it build the actual plan on the first try:
- Check the workflow’s run history to find when the failures started.
- Pull the audit log for that window to see what changed.
- Confirm whether a permissions change on the connected resource lines up with the timing.
Knowing which calls to make and in what order is the core context that MCP provides.
At its core, MCP standardizes how applications provide context to large language models (LLMs). MCP works behind the scenes using client-server technology, but users won’t see any of this technical setup when using the system. Here’s the basic flow:
- An AI application acts as the host. It runs an MCP client component that interacts with each tool that presents itself as an MCP server.
- The host calls the client, the client calls the tool server, receives a response, and sends it back to the host.
- The client can collect all this useful information from the MCP servers about capabilities, formats, and even prompting techniques needed to extract the most value.
MCP hosts can handle many business tasks with the right human help. These hosts need good knowledge, understanding, trust, and proper access to a defined set of tools.
These MCP servers can be handwritten by engineers or auto-generated by SDK generators like Speakeasy, which can transform OpenAPI specifications directly into MCP-compatible servers. Your platform of choice may just handle some of those details (including all kinds of pesky authentication and access policy nuance) for you.
Think about MCP architecture like different parts working together. Many types of apps can act as the main hub that connects to all your tools (like databases, APIs, and workflows you use every day). Each tool can tell AI systems what it’s for and when it should be used. This setup makes everything work together smoothly while making sure AI understands the right time and reason to use each tool.
What makes using MCP powerful is that each tool keeps its own identity within a bigger system. This helps AI understand not just how to use the tools, but when they’re most helpful for what you’re trying to do.
MCP servers can run locally (alongside the AI client) or be hosted remotely in the cloud. A local server runs on the same machine via stdio (Standard Input/Output): the client spawns it as a subprocess, and the two exchange JSON-RPC over standard input and output.
A remote server lives in the cloud and uses Streamable HTTP, a single endpoint that accepts POST requests and can keep a Server-Sent Events stream open to push back the results of long-running calls. Remote is the enterprise default because a hosted endpoint requires no installation and serves every client at once. Retool's MCP server is one of them.
Once a server is on the network, it has to control who can call it. Remote, cloud-hosted servers use OAuth 2.1, so a server can be opened to approved AI tools under the same permissions a person would have.
The detail that matters is PKCE (Proof Key for Code Exchange), which OAuth 2.1 makes mandatory because most MCP clients are public, a desktop app, a CLI, or an agent, with nowhere safe to keep a secret. PKCE covers that gap: the client generates a random verifier, sends only its hash when requesting authorization, and must present the original verifier to exchange the code for a token. An intercepted authorization code is then useless without it.
With that context available, an agent’s behavior changes in a few concrete ways. It finds the right tool instead of missing one or grabbing a near-duplicate. It puts a multi-step task in the right order instead of guessing at it. And it reads results for what they are, not mistaking a settled charge for a pending one. The failing-workflow diagnosis earlier was all three at once.
Those gains are per tool. They compound when an agent works across several in a row, planning, calling one, reading the result, and deciding the next move. When every tool in the chain carries metadata, the agent stops reading each description in isolation and starts seeing how they relate to one another.
It can tell that one tool’s output is the input another expects, that two of them are alternatives rather than steps, and that one has to finish before the next can start. Understanding those relationships, not just what each tool does alone, is what lets an agent compose a plan across tools nobody scripted. That is the mechanism behind an autonomous agent, not a vague sense that the models keep getting smarter.
MCP came out of Anthropic, and the clearest sign it has become a real standard is that Anthropic’s competitors adopted it anyway. OpenAI wired it into ChatGPT, Google into the Gemini API and Vertex AI, Microsoft across GitHub, Azure, and Microsoft 365. None of them had an obvious reason to back a rival’s protocol. They did it because the alternative, every vendor maintaining its own way to connect tools, costs more than agreeing on one.
The deployment pattern matured along the way, too. Early MCP was mostly local, a server that a developer ran on their own laptop, which suited a protocol still finding its footing. As teams and then whole companies came to rely on it, remote, cloud-hosted servers became the default. The mechanics we covered earlier, what matters here is that the move from local to remote is itself a marker of maturity. You host centrally when people depend on something, not while you’re still experimenting with it.
We watched that shift from inside it, and shipping our own server was part of it. Retool's native MCP server fits the remote, enterprise pattern exactly: a hosted server any MCP-compatible client can reach, with the organization’s existing permissions intact. What it actually unlocks is the next section; the full guide has the setup.
Almost every explanation of MCP runs one way: an AI tool reaching out to consume a server. The reverse gets far less attention and matters just as much. A platform can become a server.
The payoff is larger than it sounds. The old way to make a platform usable by an AI tool was to build an integration for it, then another for the next client, and so on. An MCP server does that work once. Every compatible client, the ones here now and the ones shipping next year, reaches the platform with nothing custom in between.
Retool is the closest example, since it’s ours. Say you’re in your editor and need a number from a database wired into Retool, signups by region last week.
- Before its MCP server: leave your work, open Retool, find the resource, write and run the query, carry the answer back.
- Now: ask your assistant from where you already are. It runs the query and the answer returns, no browser, no context switch.
Retool is one case of a spreading pattern. As more enterprise platforms ship servers, the software you pay for stops being something you log into and becomes something your agents operate directly, under your existing permissions. Across a whole stack, every tool is exposed once, and every agent already knows how to use it, which extends well beyond any single platform.
The payoff is concrete. For developers, the servers you write get found and used correctly, with far less time lost to debugging an agent’s strange choices. For people relying on those agents, it’s an assistant that knows what your systems can do, rather than guessing.
MCP has shifted. A year ago, the question was whether it would become the standard. It did. What’s left is depth: the protocol works, and everyone supports it, so the frontier moved to what gets built on top.
If we had to name where the real work is now, it’s two places:
- Craft. Implementing the protocol is trivial. Writing a server whose metadata reliably sends an agent to the right tool at the right moment is hard, and it’s what separates a good server from a generated one.
- Composition. MCP servers can already call other servers, and a single agent can act as both client and server, which makes layered, multi-agent systems possible.
It all points to one aim. We don’t just want AI systems that access and retrieve data. We want AI systems that understand what each datum means, that grasp the why and not just the what. Try Retool’s MCP server today.
Special thanks to Andrew Tate for his help with this article.
