← Knowledge

MCP and REST: Why you need both, and why a REST API alone is no longer enough

MCP does not replace your REST API. It builds on top of it. The honest comparison: what REST delivers for machines, what agents additionally need, and why 14 of 21 German APIs fail at exactly this point.

3 min read

14/21
tested German APIs have no machine-readable API documentation: for agents, that is like a shop without a door sign
Das Wichtigste in 30 Sekunden
  • REST remains the foundation: data, endpoints, permissions. MCP changes nothing about that.

  • MCP adds the layer REST does not have: tools with descriptions from which the language model derives what it does, when, and with what.

  • The effort is smaller than its reputation suggests, but only after an honest review of your own API (documentation, auth, write safety).

  • Trying it costs nothing: the live test checks your public API in minutes.


The question comes up in almost every first conversation: "We already have a REST API. Why do we now need a protocol on top?" The short answer: because REST was built for programmers. And agents are not.

What REST delivers and what it leaves open

A good REST API is precisely documented: endpoints, parameters, response formats, error codes. A developer reads the docs, writes the client, tests, done. For this purpose, REST (or GraphQL) remains the foundation. Even an MCP server almost always talks to a REST API in the background.

An AI agent, however, does not read documentation. At connection start it receives a list of tools, and for each tool a description text from which the language model derives: What is this for? Which arguments does it need? What happens when I call it? These descriptions are not decoration; they are the interface. An unclear description does not lead to an error message, but to wrong bookings.

This exact layer (tested, stable, described tools on top of your API) is MCP. Plus the rules around it: sign-in on behalf of the user (OAuth instead of API keys), confirmation requirements for destructive actions, logging.

Where German APIs stand today

Our German MCP Report 2026 automatically tested 21 B2B SaaS APIs. The gap is twofold:

  1. Only 4 of 21 offer their own MCP endpoint (awork, seven.io, clockodo, and personio, all with clean OAuth discovery).
  2. 14 of 21 do not even have machine-readable API documentation at standard paths. An agent (and every tool that wants to build one) cannot find the door.

The community steps into the breach: for at least 8 of the tested products, unofficial MCP servers exist on GitHub, built by users, without API access from the vendors, often without security layers. If your customers get the agent capability of your software from somewhere else, you have already given up control over permissions and logging.

What the switch really costs

The REST API stays as it is. On top comes an MCP layer: 10–20 tools that map your most important use cases, with descriptions regression-tested against real model clients, with idempotency for write actions and a confirmation flow for destructive ones. The numbers: the audit at a fixed price, the build in 2–4 weeks.

The first step costs nothing and commits you to nothing: the live test shows in minutes how agent-ready your public API is today, and where it stands compared to the 4 of 21.