What Is an MCP Server? A Plain Answer for Developers

An MCP server is a small program that exposes one system's tools and data to an AI model through the Model Context Protocol, so any MCP-compatible agent can call that system without a custom integration written for it.

Here's what most explainers get wrong about an MCP server today: the current protocol revision is 2026-07-28, messages are JSON-RPC 2.0, and there are exactly two standard transports — stdio and Streamable HTTP. If an article describes three or four transports, or mentions a session handshake, it's describing a version of MCP that no longer exists. That revision is a few weeks old as of this writing, and it's the biggest change since launch.

By the end of this post, you'll know the three things a server can actually expose, what a real request and response look like on the wire, and where a server's reach quietly stops no matter how correctly it implements the spec.

What is an MCP server?

A server is the piece that actually does something: the program that holds the connection to your filesystem, your database, or an API like SocialCrawl's, and answers a model's requests. Anthropic, which announced the protocol on November 25, 2024, describes MCP itself as an open standard that enables developers to build secure, two-way connections between their data sources and AI-powered tools. It was created inside Anthropic by David Soria Parra and Justin Spahr-Summers.

It isn't Anthropic's alone anymore. On December 9, 2025, governance moved to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block, and OpenAI, with Google, Microsoft, AWS, Cloudflare, and Bloomberg backing it. MCP is a multi-vendor standard now, not a single company's API.

What is an MCP server in AI, and what does it actually replace?

What MCP in AI replaces is the custom integration written for each model-tool pair. Before it, connecting M different AI models to N different tools meant writing N×M separate integrations, each with its own auth and its own request shape. Anthropic's framing of the problem, verbatim: every new data source requires its own custom implementation, making truly connected systems difficult to scale (source). The ecosystem calls this the N×M integration problem — a community gloss, not Anthropic's own phrase, but an accurate one. An MCP server collapses N×M into N+M: build one server per tool, one client per model, and any compliant client can talk to any compliant server.

The launch shipped pre-built servers for Google Drive, Slack, GitHub, Git, Postgres, and Puppeteer, with Block and Apollo as early adopters alongside Zed, Replit, Codeium, and Sourcegraph. Adoption moved fast from there: OpenAI added support on March 26, 2025, Google DeepMind followed on April 9, 2025, and by December 2025 the project's own governance post listed ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, and Visual Studio Code among its clients, "and many more."

Two dated numbers, and only these two — treat any bigger figure you read elsewhere as unverified. On December 9, 2025, the project reported over 97 million monthly SDK downloads and 10,000 active servers. By July 28, 2026, that had grown to close to half a billion downloads a month, with the TypeScript and Python SDKs each individually past 1 billion total downloads.

How does an MCP server talk to the model?

Here's the MCP server architecture, mechanically: three participants, one message format, two ways to move it between them. The spec puts the roles plainly: MCP follows a client-server architecture where an MCP host — an AI application like Claude Code or Claude Desktop — establishes connections to one or more MCP servers, doing this by creating one MCP client for each MCP server (source). The host coordinates everything, the client maintains one dedicated connection per server, and the server is a program that provides context to MCP clients. A server is defined by what it does, not where it runs — a process launched locally over stdio and a service reachable over the network are both, formally, MCP servers.

A server exposes exactly three kinds of thing, and each is controlled by a different party:

Primitive	Controlled by	Methods
Tools	Model	tools/list, tools/call
Resources	Application	resources/list, resources/templates/list, resources/read
Prompts	User	prompts/list, prompts/get

Tools are functions the model decides to call on its own; resources are read-only context the application pulls in; prompts are templates the user triggers directly (source). Tool inputs are validated against JSON Schema, and a call may require the user's consent before it runs — the host is where that consent gets asked for.

Here's the part that dates almost everything written about MCP before this summer. The current protocol revision is 2026-07-28, and it defines exactly two standard transport bindings: stdio, for a subprocess the host launches and talks to over its standard streams, and Streamable HTTP, an HTTP POST to a single endpoint with an optional Server-Sent Events stream for replies. HTTP+SSE as its own standalone transport was deprecated back in the 2025-03-26 revision and was formally reclassified Deprecated under the new feature-lifecycle policy in 2026-07-28. The revision history, for anyone keeping score: 2024-11-05 → 2025-03-26 → 2025-11-25 → 2026-07-28. If a page tells you MCP has three or four transports, it's describing a spec that's over a year stale.

That same revision made MCP stateless: the old initialize/notifications/initialized handshake and the Mcp-Session-Id header are gone, and every request now carries its own protocol version in _meta. The design rationale, from the release notes: every request is self-describing, with an optional discovery call for clients that want capabilities up front, so any request can land on any instance behind a plain round-robin load balancer (source).

Here's the whole exchange, schematically — first the client discovers what's available, then it calls it.

Request — tools/list:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28"
    }
  }
}

Response:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "get_weather",
        "description": "Get current weather for a location",
        "inputSchema": {
          "type": "object",
          "properties": {
            "location": { "type": "string" }
          },
          "required": ["location"]
        }
      }
    ],
    "_meta": {
      "ttlMs": 3600000,
      "cacheScope": "server"
    }
  }
}

The ttlMs and cacheScope fields are new requirements in the 2026-07-28 changelog — they tell the client how long it can cache this list before asking again.

Request — tools/call:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "location": "Lisbon" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28"
    }
  }
}

Response:

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [
      { "type": "text", "text": "18°C, partly cloudy" }
    ],
    "resultType": "success",
    "isError": false
  }
}

resultType is required on every result now too — it's part of the same changelog that replaced server-initiated requests with Multi Round-Trip Requests. That's the entire exchange: one call to discover what's possible, one call to actually do something. For the full transport mechanics and the handshake this replaced, see the fetch MCP server guide.

What is an MCP server used for?

An MCP server is used to give a model controlled access to one category of system it couldn't otherwise reach: a filesystem, a database, a SaaS API, or a browser. The categories map cleanly onto the servers Anthropic shipped at launch — Git as a filesystem-style server, Postgres as a database server, Google Drive, Slack, and GitHub as SaaS API servers, and Puppeteer as a browser server (source).

In practice, most real MCP server use cases are the SaaS API kind: a thin layer over an existing API that turns a handful of REST endpoints into a small set of discoverable tools. That's also the shape most worth getting right, because it's the one where "how many tools should I expose" starts to matter — more on that below.

For five real calls against a live API — not a schematic like the one above, actual requests and actual responses — see MCP server examples.

What is the difference between a local and a remote MCP server?

The transport decides this, not the deployment target. A local server runs as a subprocess the host launches directly over stdio — no network hop, no separate process to keep alive. A remote server runs somewhere else and is reachable over Streamable HTTP. Both are, formally, MCP servers.

Credentials follow the same split. Stdio implementations "SHOULD NOT" follow the OAuth spec at all — they're expected to pull credentials straight from the environment (source). That's the whole reason a local MCP server is configured with an API key sitting in a JSON config file instead of a login flow: it isn't a shortcut, it's what the spec prescribes for that transport.

SocialCrawl's own MCP server is a stdio server that follows this exact pattern: published on npm as socialcrawl-mcp, currently v1.8.0, authenticated with a SOCIALCRAWL_API_KEY environment variable rather than an OAuth flow — one API key, set once, per the pattern stdio prescribes. It exposes seven tools, not one per endpoint: socialcrawl_list_platforms, socialcrawl_list_endpoints, socialcrawl_get_docs, socialcrawl_request, socialcrawl_check_balance, socialcrawl_monitors, and socialcrawl_web. Three need no key at all; four hit the network, and socialcrawl_request validates the platform, endpoint, and required parameters locally before it spends anything. It's a live instance of the progressive-disclosure pattern MCP rewards: hundreds of endpoints behind a catalogue, discoverable through the two listing tools, rather than dumped into the model's context as one flat list of functions — the same catalogue the SocialCrawl API exposes over REST, just discoverable instead of documented.

None of this says anything about whether a server can actually get the data it's supposed to expose. Reddit updated its bot policy to rate-limit or block unrecognized crawlers on June 25, 2024, X's terms have banned crawling and scraping since September 2023, and Cloudflare started blocking AI crawlers by default for new domains in July 2025, tightening further from September 15, 2026. The legal line, for what it's worth, runs along authentication rather than automation: in Meta Platforms v. Bright Data (January 23, 2024), a federal judge held that scraping public, logged-out pages after account termination didn't breach Meta's terms — logged-in access is a different question entirely. See where a fetch-style server stops working and what a server built to handle this looks like in practice.

What actually goes wrong with an MCP server?

Here's the honest version, not the sales pitch. The spec is explicit about one failure mode: token passthrough is flatly forbidden — servers "MUST NOT accept any tokens that were not explicitly issued for the MCP server" (source). That rule exists because a compromised local server runs with the same privileges as its client: if it's breached, an attacker can execute any command the client itself is allowed to run.

The protocol also doesn't solve the problem sitting one layer up. Tool descriptions are untrusted input the moment they come from a third-party server, and MCP has no opinion on what a model does with text it's told to trust. OWASP now catalogues this as MCP Tool Poisoning, first flagged publicly by Invariant Labs. The practical mitigations are the obvious ones: scope tokens to the minimum a tool needs, and lean on the host-mediated consent point already built into the tool-call flow above. For the concrete threat catalogue behind this — DNS rebinding, SSRF, prompt injection through fetched content — see the fetch MCP server guide. "MCP has an auth model" and "MCP is safe" are different claims — treat them that way.

MCP vs function calling: what actually changed?

Function calling already let a model describe the functions available to it and get back a structured call to one of them — that part isn't new. What MCP adds is discovery: instead of hardcoding a function list into every integration, an agent calls tools/list at runtime and learns the entire callable surface of a server it has never seen before, using the same JSON-Schema-described functions it would have gotten anyway. Function calling is the mechanism; MCP is how an agent finds out, at runtime, which servers exist and what they can do — across as many independent servers as a host chooses to connect.

Do you still need MCP if you already have RAG?

RAG and MCP solve adjacent problems, not the same one. RAG retrieves passive context to stuff into a prompt — which is roughly what MCP's Resources primitive does. What RAG doesn't give you is a standardized way for a model to take actions (MCP's Tools) or trigger user-selected templates (MCP's Prompts) through one discovery surface that works the same way across every server a host connects to. In practice, the two show up together more often than not: RAG for retrieval, MCP for everything a retrieval pipeline was never meant to do.

How do you start using an MCP server?

Two practical paths from here, and they aren't mutually exclusive. If you want to use one, most hosts — Claude Desktop, Cursor, VS Code — let you point at an existing server's config and start calling its tools within minutes. If you want to build one, MCP server examples walks through real calls against a live API with real JSON, and the fetch MCP server guide covers wiring a fetch-style server into a host, transport mechanics included.

Frequently asked questions

What is an MCP server used for?

An MCP server is used to give an AI model controlled access to one system — a filesystem, a database, a SaaS API, or a browser — that it couldn't otherwise reach. It exposes that system as a small set of discoverable tools, resources, and prompts rather than a bespoke integration built for one specific model.

What is an MCP server in AI?

In an AI context, an MCP server is the program on the other end of a model's tool calls: it holds the actual connection to a data source or service and answers requests like tools/list and tools/call over JSON-RPC 2.0 — the same interface any MCP-compatible client uses to call it.

Why is an MCP server needed?

An MCP server is needed because, without one, every model-to-tool connection has to be built as a custom, one-off integration. A server turns that connection into something any MCP-compatible client can discover and call the same way, which is what makes N tools reachable from M models without N×M separate integrations.

What is MCP in agentic AI?

In agentic AI, MCP is the standard an agent uses to discover and call external tools, read external resources, and trigger user-defined prompts at runtime, instead of having every capability hardcoded into the agent ahead of time. It's the layer that lets an agent's toolset grow without rewriting the agent itself.

Is MCP the same as function calling?

No. Function calling is the mechanism a model uses to request a structured call to a described function — that predates MCP. MCP adds runtime discovery on top: an agent calls tools/list to learn what functions a server offers, instead of having that list hardcoded into the integration ahead of time.

Do I need MCP if I already use RAG?

Not necessarily, and they aren't substitutes. RAG retrieves passive context, close to what MCP's Resources primitive does. MCP additionally lets a model call Tools and trigger Prompts through one standardized discovery surface — most real systems end up using both, RAG for retrieval and MCP for everything else.

What is the difference between an MCP client and an MCP server?

A client maintains one dedicated connection to a single server on behalf of a host application. A server is the program on the other end that actually holds the connection to a system — a filesystem, database, or API — and answers the client's requests. A host creates one client for every server it connects to.

Can an MCP server run remotely, or does it have to be local?

It can run either way — the difference is the transport, not a requirement. A local server runs as a subprocess over stdio; a remote server runs elsewhere and is reachable over Streamable HTTP. Both are, formally, MCP servers; only the credential-handling and network overhead differ.