What Is the Model Context Protocol (MCP)?

The Model Context Protocol (MCP) is an open standard that lets AI applications connect to external tools, data sources, and services through a single, uniform interface. Instead of every AI client writing its own custom integration for every external capability, MCP gives both sides a shared contract: clients speak MCP, servers speak MCP, and things work.

That is the short answer. The rest of this post explains why that matters, how the protocol is structured, and what an MCP server actually exposes, using AgentBrush as a concrete example.

The problem MCP solves

Before MCP existed, connecting an AI assistant to an external capability meant writing a one-off integration. Want your coding agent to read from a database? Write a plugin. Want it to call a GitHub API? Write another plugin. Want a different AI client to do the same things? Write all the plugins again.

The result is an M-times-N matrix: M AI applications, each needing to integrate with N tools or services. Multiply that out and you get a maintenance problem that does not scale. Every team building a new AI client has to decide which integrations to support. Every team building a new tool has to decide which clients to target. The two sides do not talk directly.

MCP collapses the matrix. Build one MCP server for your tool, and it works with every MCP client. Build one MCP client into your AI application, and you can use every MCP server. The matrix becomes M plus N instead of M times N.

How MCP works

The protocol has three participants:

The host is the AI application the user is running, such as Claude Code, Cursor, or any other MCP-compatible client. The host is responsible for starting an MCP client and deciding which servers to connect to.

The MCP client lives inside the host. It manages connections to one or more MCP servers, routes requests, and surfaces server capabilities to the AI model.

The MCP server is a process (local or remote) that wraps some external capability and exposes it through the MCP interface. The server declares what it can do, and the client calls it.

The three primitives

Every MCP server exposes capabilities through three building blocks:

Tools are callable functions. The AI model can invoke them to take an action, retrieve data, or produce output. Tools are what most people mean when they talk about MCP: a filesystem tool that reads a file, a search tool that queries an index, or an image generation tool that creates an asset. Tools have typed input schemas, so the model knows exactly what parameters to send.

Resources are readable data. A resource might be a file, a database row, a calendar entry, or a documentation page. Resources do not take arguments the way tools do; they are identified by a URI and fetched directly. Not every client currently uses resources in the same way, and support varies.

Prompts are reusable prompt templates that a server can offer. The user or the model can invoke a prompt by name to get a pre-built instruction set. In practice, prompts are the least commonly used primitive today, but they are part of the spec.

Transports

MCP servers communicate with clients over one of two transports. stdio (standard I/O) is the common choice for local servers: the host spawns the server as a subprocess and they communicate over stdin and stdout. Streamable HTTP is the transport for remote servers: the client connects to a URL and uses HTTP with server-sent events for streaming responses. Most MCP servers developers encounter day-to-day are stdio-based because the local setup is simpler and has no auth surface to manage.

Streamable HTTP replaced the older HTTP+SSE transport in the March 2025 spec revision. If you see references to "HTTP+SSE" in older documentation, that transport has been deprecated in favour of Streamable HTTP.

What an MCP server actually exposes

The best way to understand what MCP enables is to look at what real servers expose as tools:

Filesystem servers expose tools like read_file, write_file, list_directory, and search_files. An agent can use these to read source files, write outputs, and navigate a project.

Version control servers (the GitHub MCP server is a widely-used example) expose tools for searching repositories, reading files, creating issues, opening pull requests, and fetching diffs. The agent can interact with GitHub without leaving the editor.

Database servers expose query tools, schema inspection, and sometimes read/write operations on rows. The agent gets a SQL interface without needing a separate client.

Image generation servers like AgentBrush expose tools that turn a text description (and optionally reference image paths for consistency) into a finished asset, saved directly into the project. More on this in a moment.

Each of these is just a set of named functions with typed schemas. The AI model sees the tool list, decides which tool is relevant, assembles the arguments, and calls it. The server runs the operation and returns the result.

Why this matters for developers

The practical upside is that your AI coding agent stops being a text-only tool. When it can read and write files, query your database, search your codebase, and generate image assets, it does useful work end-to-end instead of stopping at the point where it needs to touch a real system.

Two things make this durable rather than fragile:

Write once, runs everywhere. If you build or configure an MCP server, every MCP-compatible client can use it. Claude Code, Cursor, Codex CLI, Gemini CLI, and any other client that implements the spec can pick it up without changes. You do not need to rebuild the integration per client.

The model sees structured capabilities. Because each tool has a typed schema and a description, the model can reason about which tool to call and how to call it correctly. This is more reliable than asking a model to guess at an API surface it has only seen in documentation.

The compound effect is that agents in 2025 and 2026 started doing things that previously required a human to drive a browser or paste output between windows. MCP is the plumbing that makes that possible.

AgentBrush as a worked example

AgentBrush is an MCP server for image generation. It exposes gpt-image-2 as a set of tools your agent can call from inside Claude Code, Cursor, Codex CLI, Gemini CLI, or any MCP-compatible client.

The tools it exposes include:

  • agentbrush_generate: the main generation tool. You describe the image, pick a preset (realistic, flat_illustration, pixel_art, isometric, logo, or custom), set a quality level, and optionally pass reference image paths for visual consistency across generations. The server calls gpt-image-2, saves the result into your project, and returns the file path.
  • agentbrush_remove_background: takes an image file and removes its background locally. No API call, no tokens, always outputs a PNG with a transparent background. This is the two-step workflow for transparent assets: generate the opaque image, then remove the background.
  • agentbrush_edit_mask and agentbrush_edit_mask_result: let you mark a region of an existing image for inpainting. The agent opens the mask editor, you draw the region, and AgentBrush repaints only that area.
  • agentbrush_list_presets and agentbrush_list_references: inspection tools so the agent knows what is available before generating.

A request flows like this: your agent decides it needs an icon for a new feature. It calls agentbrush_generate with a prompt and quality: low (1 token, fast, good for iteration). AgentBrush validates the request, calls gpt-image-2, receives the image bytes, writes the file to the output directory you configured, and returns the local path. The agent can then reference that file in a subsequent message, use it in the UI code, or pass it back as a reference image for the next generation.

The agent never touches an OpenAI API key directly. It just calls a tool.

Generate a flat-illustration icon for a "sync" feature: two circular arrows, clean
line weight, single accent color, transparent-background PNG.
preset: flat_illustration ยท quality: low

The generation costs 1 token at low quality. After it lands, if you need a transparent PNG, the agent calls agentbrush_remove_background on the result. That step runs locally and costs nothing.

Where MCP is still maturing

MCP is a young protocol. Anthropic introduced it in late 2024, adoption spread through 2025 into 2026, and the surface area is still expanding. A few things to know before you depend on it heavily:

Authentication and authorization are still evolving. The spec has basic auth support, but the pattern for production remote servers (token rotation, scoped permissions, server-to-server trust) is not as settled as it is in, say, OAuth for web apps. Local stdio servers sidestep most of this, which is why they dominate in practice.

Not every client supports every primitive. Resources and prompts are part of the spec, but client support varies. Tools are widely supported. If you build a server that relies heavily on resources or prompts, test it against the specific client you are targeting.

Streaming and long-running operations are handled differently per client. A tool call that takes several seconds, like an image generation request, should be handled gracefully, but how the client surfaces progress or intermediate output depends on the client implementation.

The ecosystem is moving fast. The registry of available servers is growing quickly, and server quality varies. Before wiring an unfamiliar server into your agent, check how actively it is maintained and what permissions it requests.

None of these are reasons to avoid MCP. They are reasons to understand it before you commit a production workflow to it.

FAQ

Do I need to know the MCP spec to use an MCP server? No. You configure the server in your client's settings file (usually a JSON config that names the server and its command or URL), and the client handles the rest. The spec matters if you are building a server, not if you are using one.

Is MCP only for code editors? No. The protocol is client-agnostic. Any application that implements an MCP client can connect to servers. Code editors are the most visible adopters because agentic coding is where MCP adoption started, but the architecture works for any AI application that needs external capabilities.

How is MCP different from function calling? Function calling is a model-level feature: you define functions in an API request, and the model returns structured calls to them. MCP is a transport and discovery layer on top of that. An MCP client takes the tools a server exposes, formats them as functions in the model's API call, and routes the model's returned calls back to the server. MCP adds the server discovery, the persistent connection, and the cross-client standard on top of what function calling already does.

Does AgentBrush work with clients other than Claude Code? Yes. AgentBrush exposes a standard MCP stdio interface. It works with Claude Code, Cursor, Codex CLI, Gemini CLI, and any other MCP-compatible client. The install steps vary slightly per client, but the server is the same in every case.

Ready to connect AgentBrush to your editor? The install guide walks through the setup for Claude Code and Cursor in about two minutes. You will need an AgentBrush account and your client's MCP config file. That is it.