Blog

What Is MCP (Model Context Protocol)? A Developer Guide

MCP (the Model Context Protocol) is an open-source standard, introduced by Anthropic in November 2024, that lets AI applications connect to external tools, data, and services through one shared protocol instead of a custom integration per pairing. The acronym also names unrelated things — a metacarpophalangeal joint, a managed care plan, a motor carrier permit — but this page and MCPifex, a hosted gateway built on MCP, are about the AI protocol.

Why MCP exists: the N×M integration problem

Before a shared protocol, every AI application that wanted to reach an external tool or data source needed its own custom integration for that specific pairing. Wire up N applications to M tools and data sources, and you end up building and maintaining N×M separate integrations — each one breaking independently as either side changes. Anthropic announced MCP on November 25, 2024, as a fix for exactly that: a single protocol that an application implements once as a client and a tool or data source implements once as a server, turning N×M bespoke integrations into N+M standard ones. The protocol was created by Anthropic engineers David Soria Parra and Justin Spahr-Summers, and it launched with early adopters including Block, Apollo, Zed, Replit, Codeium, and Sourcegraph already building against it.

The official framing from the MCP docs describes it as being "like a USB-C port for AI applications" — a standardized way to plug an AI application into whatever data, tools, or workflows it needs, rather than wiring a different cable for every device.

The MCP architecture: hosts, clients, and servers

MCP's architecture has three parts. A host is the AI application or environment a person actually uses — an IDE, a chat app, an agent framework — and it can run multiple client instances at once. Each client keeps a strict one-to-one connection to exactly one server. A server exposes its capabilities as tools (actions the model can invoke), resources (data it can read), and prompts (reusable templates) and can run as a local process or a remote service.

The spec has moved a few times since 2024: the 2025-03-26 revision replaced the earlier HTTP+SSE transport outright with Streamable HTTP, which has been the standard remote transport since. The most substantial change so far landed on 2026-07-28: the protocol core became stateless. There's no protocol-level session tracking — every request is self-contained, carrying its own version and capability negotiation in per-request metadata — plus a formal extensions framework for adding new functionality without breaking existing clients. David Soria Parra, one of MCP's creators, called the release "MCP's most important since remote MCP first launched over a year ago."

Transports: stdio for local servers, Streamable HTTP for remote ones

MCP defines two standard transports. stdio sends JSON-RPC 2.0 messages over a local process's stdin/stdout, one process per client — the natural fit for a server that runs on your own machine, like a filesystem or local database tool. Streamable HTTP exposes a single HTTP endpoint that handles both POST and GET, with optional Server-Sent Events for streaming responses — the fit for a server that lives somewhere else and multiple clients need to reach over the network. It's also the transport MCPifex's own gateway at https://mcpifex.com/mcp uses, since a hosted server is remote by definition.

MCP vs. a plain API or function calling

These three sit at different layers, and the confusion is fair — all three end with a model doing something outside its own context window.

REST APIFunction callingMCP
What it standardizesNothing across APIs — each one defines its own endpoints, auth, and shapesHow one model declares and calls functionsHow any client talks to any server, independent of the model behind it
Integration cost per toolCustom client code per APICustom function schema + handler, tied to that model's SDKOne client library; a new server needs no client-side changes
DiscoveryRead the docs, hardcode what you callYou define the available functions up frontThe client asks the server what it can do (tools/list) at connection time
Portable across models/clientsN/A — it's just HTTPNo — schemas are provider-specificYes — any MCP client can use any MCP server

In practice, an MCP server is often just a thin, standardized wrapper around a REST API or a database driver — MCP doesn't replace those underlying systems, it gives every AI application a common way to discover and call them.

Who's actually using MCP

Adoption moved fast past Anthropic's own products. OpenAI added MCP support to its Agents SDK in March 2025, with support in the Responses API and the ChatGPT desktop app following later that year; Google DeepMind announced support the following month. Microsoft integrated MCP with Semantic Kernel, Azure OpenAI, and GitHub Copilot in VS Code, and Cloudflare added support for deploying remote MCP servers. On the client side, Cursor, VS Code, and Windsurf all support MCP, alongside Claude's own apps and Claude Code — see the guide for adding an MCP server to Claude Code if that's your client.

MCP security: what the protocol doesn't solve for you

MCP standardizes how a client and server talk; it doesn't make what a server does safe by default. Security researchers publishing in April 2025 documented real risks in MCP integrations — prompt injection via tool results, "tool poisoning" where a malicious server description manipulates the model, and data exfiltration through overly broad tool access. None of that is unique to MCP, but the protocol's whole point is making it trivial to wire a model up to dozens of tools at once, which raises the stakes on which tools it can actually call. The practical mitigation is the same one behind least-privilege access anywhere: give an agent only the specific tools a task needs, keep destructive or write operations off by default, and treat anything a server hands back as untrusted input, not instructions.

The catch: MCP standardizes the wire format, not who runs the server

Reading the spec answers "what is MCP," but not "how do I actually use one." Someone still has to run the server process somewhere, keep its credentials safe, and decide which of its tools an agent is allowed to call — the protocol is silent on all three. That's the layer a hosted gateway exists to handle. MCPifex is a marketplace and hosted gateway for MCP: you create an instance of a catalog server in the MCPifex marketplace — PostgreSQL is one example, see the PostgreSQL server page — store that server's credentials in the portal, and choose which of its tools are enabled, with destructive or write tools off by default. MCPifex runs the real MCP server package for you and hands back one API key (starting mcpx_) that works with any MCP client speaking the Streamable HTTP transport described above; a connect guide and the quickstart cover the exact steps. The free plan covers 3 instances with no card required — register an account to try it, or see pricing for the paid tiers.

Key takeaways

  • MCP is Anthropic's open-source protocol (November 2024) for connecting AI applications to external tools, data, and services through one shared interface instead of a custom integration per pairing — unrelated to the medical or trucking uses of the same acronym.
  • Architecture is host → client → server, with a strict 1:1 client-to-server connection; servers expose tools, resources, and prompts.
  • The 2026-07-28 spec revision made the protocol core stateless: every request now carries its own version and capabilities instead of relying on a tracked session.
  • stdio suits local servers; Streamable HTTP suits remote/hosted ones, including MCPifex's gateway.
  • MCP doesn't make a server's tools safe by default — least-privilege tool access is still the operator's job, not the protocol's.
  • MCP tells you how a client and server talk; a hosted gateway like MCPifex handles running the server, storing its credentials, and deciding which tools an agent may call.

Frequently asked questions

Is MCP the same as a REST API?
No. A REST API is one specific interface you integrate against by hand; MCP is a protocol that standardizes how any AI client discovers and calls any compliant server's tools, so a new server needs no client-side code changes. An MCP server is often built as a thin wrapper around an existing REST API.
Is MCP secure?
The protocol itself doesn't guarantee safety. Security researchers documented prompt injection, tool poisoning, and data-exfiltration risks in MCP integrations as early as April 2025. The mitigation is least-privilege tool access: enable only the specific tools a task needs and keep destructive operations off by default, which is how MCPifex's gateway is configured out of the box.
Who created MCP?
Anthropic announced MCP on November 25, 2024, as a fully open-source standard, created by Anthropic engineers David Soria Parra and Justin Spahr-Summers. It has since been adopted well beyond Anthropic's own products, including by OpenAI and Google DeepMind.
Do I need to host my own MCP server?
No. You can run an MCP server yourself as a local or remote process, or use a hosted gateway like MCPifex, where you create an instance of a catalog server, enable specific tools, and get an API key without running or maintaining the server package yourself. See the MCPifex marketplace or pricing page for what's available on the free plan.
What's the difference between MCP and function calling?
Function calling is how one model declares and invokes functions using that model provider's own schema — it's not portable across models. MCP standardizes the connection itself: any MCP client can call any MCP server's tools, discovered at connection time via tools/list, independent of which model is doing the calling.

Sources

  1. Model Context Protocol, "What is the Model Context Protocol (MCP)?"
  2. Model Context Protocol, "Architecture", specification 2026-07-28.
  3. Anthropic, "Introducing the Model Context Protocol", November 25, 2024.
  4. Model Context Protocol, 2026-07-28 release announcement.
  5. Wikipedia, "Model Context Protocol".