|What is an MCP server?

The problem it solves

Before MCP, every combination of an AI client and an external system was its own integration. Support for a tool inside one assistant told you nothing about whether it worked in another, and each vendor shipped a bespoke plugin format with its own manifest, its own auth story, and its own lifetime.

MCP replaces that with one contract. A server declares what it can do; a client discovers that declaration at connect time and hands the model a matching set of tools. Anything that speaks the protocol works with anything else that speaks it, which is why the same URL below works in Claude Code, Cursor, VS Code, Zed, and a terminal you wrote yourself.

What a server exposes

Three kinds of thing, and the distinction matters more than it looks:

• +Tools — functions the model can call, each with a JSON Schema for its arguments. This is where anything with a side effect lives.
• +Resources — content the client can read and put in context, addressed by URI. Files, records, rendered images.
• +Prompts — reusable templates a user can invoke deliberately, usually surfaced in the client as a slash command.

Transports: local and remote

A local server runs as a process on your machine and talks over stdio. The client spawns it, pipes JSON-RPC through standard input and output, and kills it on exit. This is simple and needs no network, but it means the server has to be installed, it can only reach what that machine can reach, and there is no meaningful notion of who you are — the process runs as you, and that is the whole security model.

A remote server is an HTTP endpoint. The current transport is streamable HTTP: the client POSTs JSON-RPC to a single URL and the server may answer with a stream when it wants to push progress or notifications. Nothing is installed, the server is updated centrally, and authentication is a real question with a real answer.

A stdio-only client can still reach a remote server through a bridge such as mcp-remote, which runs locally, speaks stdio to the client, and HTTP to the server.

Authentication

Remote servers use OAuth 2.1 with PKCE. In practice: your client discovers the authorization server from the resource metadata, registers itself dynamically if it has no client ID, sends you to a browser, and receives a token scoped to your account. No API key is pasted anywhere, and revoking access is something you do on the server rather than by rotating a secret.

Dynamic client registration is the part that makes this pleasant. It is why you can point a client the server has never seen at a URL and have it work — the client registers itself on the spot rather than requiring somebody to pre-provision it.

What makes a server good

Schema size is a real cost. Every tool description is sent to the model on every request, so a server with sprawling schemas eats context that the actual work needed. Fewer, sharper tools beat many overlapping ones.

Validation belongs on the server. A model will send you a colour as a string, a number, and an object across three consecutive calls; the server has to reject the ones that are wrong rather than write them and produce a broken document later.

Give the model a way to check itself. A tool that renders the current state back as an image turns a blind sequence of writes into a loop the model can close on its own.

Loora as an example

Loora’s MCP server is remote streamable HTTP at one URL, with OAuth 2.1, PKCE, and dynamic client registration. It exposes 33 tools over a design canvas: reads such as readTree and searchNodes, writes such as insertNodes and patchNodes, and view tools that render the real document to an image so the model can look at what it just built.

Every write goes through the same validated transaction path the human editor uses, so an agent’s changes are ordinary document edits — logged, undoable, and safe to make on a branch.

https://mcp.loora.design/mcp

Questions