MCP server

What it exposes

The specification defines three things a server can offer:

• Tools — functions the model can call
• Resources — data and context the model or user can read
• Prompts — templated workflows a user can invoke

A client connects, negotiates capabilities, and discovers what the server offers rather than being told in advance. That discovery step is the difference between an MCP server and a plain API: the agent learns the available operations at connection time, instead of needing them hardcoded.

Transports

The current specification revision, 2026-07-28, defines two standard transports:

• stdio — the client launches the server as a subprocess and talks over standard input and output. For local servers.
• Streamable HTTP — the server runs independently at a single endpoint handling both POST and GET. For hosted servers.

Streamable HTTP replaced the earlier HTTP+SSE transport, which is deprecated. A hosted documentation server will use Streamable HTTP.

Two kinds serve documentation, and they are opposites

This distinction matters when comparing tools, because both ship under the same three letters.

• A retrieval server lets an agent read published documentation — search it, fetch pages, ask questions grounded in it.
• An authoring server lets an agent write documentation — create pages, open change requests, restructure a site.

A tool with an excellent authoring server may give an agent no read access to published docs at all. A comparison table with a single "has MCP" column tells you nothing about which one you are getting.

Why it beats scraping

Without a server, an agent reaching documentation has to fetch rendered HTML and strip out navigation, cookie banners and footers, hoping the extraction is clean. It receives whole pages when it needed one paragraph, and has no way to ask a question.

A server replaces guesswork with defined operations. The agent calls a search tool and gets results, calls a fetch tool and gets one page's content. Nothing is inferred from markup.