Guide

What is MCP, and how is an MCP server useful?

MCP shows up in a lot of AI product marketing right now, usually as a buzzword. It's actually a fairly small, boring, well-specified protocol — and understanding the boring part is exactly what makes it obvious why you'd want one in front of your API.

What MCP actually is

The Model Context Protocol is an open specification (originally published by Anthropic, now used across the industry) for how an AI client — Claude, ChatGPT, Cursor, or anything else that can act as an MCP client — talks to an external system that can take actions or return data. It's JSON-RPC 2.0 over HTTP, with a small, fixed set of methods:

  • initialize — the client and server agree on protocol version and capabilities.
  • tools/list — the server advertises what it can do: a list of named tools, each with a description and a JSON Schema input.
  • tools/call — the client invokes one tool with a specific set of arguments and gets a result back.

That's most of it. An MCP server is anything that answers those three calls correctly. An MCP client is anything that can connect to one, read tools/list, and decide when to call a tool based on the conversation it's having. Neither side needs to know anything about the other beyond that shape — which is the entire point.

The problem it replaces

Before something like MCP, giving an AI product access to a real API meant one of two things: hand-write a custom integration for that specific client (a ChatGPT plugin here, a Claude tool-use schema there, a LangChain tool wrapper somewhere else — each maintained separately), or paste an OpenAPI spec into a UI that lets the model describe your API without any of the plumbing to actually, safely call it. Neither scales past a handful of APIs and a handful of clients — you end up building N × M integrations, one per API-client pair, each with its own auth handling and none of them sharing an audit trail.

MCP collapses that to N + M: build one MCP server per API, and every MCP-speaking client can use it without a second integration. See connecting to Claude and connecting to ChatGPT for the same published server working unmodified in both.

What an MCP server actually does

An MCP server sits between the AI client and your real API. When a tool gets called, the server is the thing that turns tools/call arguments into an actual HTTP request against your API, and turns the response back into something the model can read:

POST /mcp/srv_XXXXXXXXXX { "jsonrpc": "2.0", "id": 2, "method": "tools/call", "params": { "name": "get_order", "arguments": { "orderId": "ord_042" } } } → { "result": { "content": [{ "type": "text", "text": "{\"status\":\"confirmed\",\"total\":24.99}" }], "isError": false } }

Nothing about that round trip is simulated — the tool call became a real request to a real backend, and the response is real data. That's the baseline. What separates a bare-minimum MCP server from a useful one is everything that happens around that call.

Why an MCP server is useful, not just functional

A tool being callable and a tool being safe to let an autonomous model call are different problems. A governed MCP server — the kind this platform publishes — adds the parts a bare protocol implementation doesn't specify:

  • Risk classification. Every tool gets a risk class derived from what it actually does (a read vs. a write vs. a delete), so the platform can treat them differently rather than trusting all tools equally.
  • Policy decisions. Each call resolves to allow, allow_with_confirmation, allow_with_approval, or denied — a destructive call can be held for a human instead of executing unattended.
  • Credential brokering. The model never sees your API's real key or token. The server holds the credential and injects it at call time.
  • Multi-tenant isolation. If you're exposing this to more than one customer or team, each tenant's tools, data, and audit trail stay isolated — enforced at the database layer, not just in application logic. See how Postgres RLS enforces that here.
  • An audit trail. Every call — which tool, which arguments, which decision, which client — is logged, regardless of whether the caller was Claude, ChatGPT, or something else entirely.

None of that is part of the MCP spec itself — the spec only defines how the call gets made. It's the difference between "an agent can technically reach my API" and "I'd actually let this run unsupervised."

Getting an MCP server without building one from scratch

You don't write this layer by hand. If you already have an API description, the platform generates a risk-classified MCP server from it directly:

If you don't have a spec, or you'd rather not touch a UI at all:

Once it's published, connect it wherever you're working — Claude, ChatGPT, or try the whole loop with no signup in the 5-minute quickstart.

Start free Try the quickstart