REST, MCP and WebMCP make application functions accessible, but at different layers. REST is an architectural style for HTTP interfaces, MCP a protocol between AI applications and tool servers, and WebMCP a proposal for browser tools.
Choosing an interface#
| Question | REST API | MCP | WebMCP |
|---|---|---|---|
| Typical consumer | Applications and HTTP clients | MCP-compatible assistants | Supporting browser agents and applications |
| Location | Server | Local or remote server | Open browser document |
| Discovery | Documentation, such as OpenAPI | tools/list on a connected server | Tools registered through the document's browser API |
| Sign-in | API-specific | Transport- and server-specific | Existing application session and permissions |
| Status | Established architectural style | Open protocol with a versioned specification | Community Group draft, not a W3C Standard |
As of September 30, 2026. Supporting a specification does not guarantee every client implements every feature or transport revision.
REST: an interface for applications#
A REST interface might offer GET /api/customers/42. The application defines the result, access permissions and errors. OpenAPI can document it in a machine-readable format; an AI integration does not have to rely exclusively on prose documentation.
REST fits web frontends, mobile apps and services sharing the same data. JSON is common but not a requirement of REST. The main work depends on business logic, permissions and the existing system.
MCP: tools for a connected assistant#
An MCP server describes tools and their inputs. A client lists them with tools/list and invokes them with tools/call. A CRM server might expose get_customer and use the CRM's REST API internally.
MCP has stdio for local processes and Streamable HTTP for remote servers. The legacy HTTP+SSE transport is separate; SSE still serves responses within Streamable HTTP. Revision 2026-07-28 uses per-request metadata instead of protocol sessions. Many existing clients and servers still support earlier revisions. See stdio versus HTTP for details.
A shared interface reduces integration work, but authentication, client compatibility, tool selection and permissions still need checking. A tool does not automatically become available in every chat.
WebMCP: tools in an open document#
The current WebMCP draft registers JavaScript tools through document.modelContext. A property website could expose its existing search with location and price inputs. Execution uses the website's logic; it can involve HTTP but does not have to.
WebMCP is not a crawlable JSON endpoint at /.well-known/webmcp. A manifest alone does not provide browser tools. The declarative form API is still being developed. Actual support by a browser or agent must be checked separately.
WebMCP fits a limited trial on an existing web application with useful actions and a compatible agent. It does not guarantee every assistant automatically discovers or operates a public website.
Combine interfaces when the workflow needs it#
A booking system can have a REST API for its application, expose selected functions through MCP to an assistant, and offer the same search through WebMCP in the browser. Security rules must apply to every path. Structured tool descriptions alone make no protocol inherently faster or safer.
An agents.json is a separate manifest using an agreed or custom format. An A2A Agent Card describes an agent that accepts tasks. llms.txt is another content proposal. These files do not form a mandatory standards stack or establish a ranking advantage.
For a small business, start with the workflow: who should read which data or perform which action? Choose the interface afterward. That is where our AI solutions begin.
Sources: MCP transports, stdio, WebMCP, OpenAPI.
