MCP-ready means four building blocks: an MCP endpoint, authentication with real user delegation, machine-readable tool descriptions, and a security posture that controls write actions.
Approach 1: A proxy translates your existing API. Fast, but security sits with the proxy operator.
Approach 2: A hosted gateway makes third-party software connectable, but moves your API key to a third party.
Approach 3: Your own MCP endpoint is the official route: your infrastructure, your scopes, your protocol. Standard build: 2–4 weeks.
More and more customers ask the same question, out loud or silently: "Can I use your software with Claude, ChatGPT, or my own agent?" The honest answer for 17 of the 21 German B2B SaaS providers we audited is currently: no. The good news: The road to the answer "yes" is shorter than most think. It starts with the question of which of the three options fits your situation.
What "MCP-ready" concretely means
MCP (Model Context Protocol) is the official standard through which AI agents work with software. Software is MCP-ready when four building blocks are in place:
- An MCP endpoint that speaks the handshake defined in the specification.
- Real delegation: The agent acts on behalf of a logged-in user, with that user's permissions, via OAuth. A global API key is not delegation.
- Machine-readable description: Every tool documented so that a language model selects it correctly.
- Controlled write actions: Idempotency on retries, mandatory confirmation for destructive operations, an audit log.
The good news: Your REST API stays as it is. MCP sits as a layer in front of it (the difference in detail).
Approach 1: A proxy in front of the existing API
A proxy product or service adapts your existing API into MCP tools. The fastest option, often without a single line of your own code.
The catch: The tools inherit your API, including its weaknesses. If your API has no scopes, the proxy cannot claim any. If your API creates two invoices on a duplicate call, the proxy is right there with it. And you depend on a third party's maintenance cycle, whose translation you cannot inspect.
Best for: First internal experiments, throwaway keys, nothing customer-facing.
Approach 2: A hosted gateway
Gateways make the reverse route convenient: Your software does not become MCP-ready; instead, the agent is supplied with a wide range of ready-made software connections. Sign up, paste in an API key, done (an honest comparison).
The price: Your key sits with a third party, your customer data flows through their infrastructure, and in the GDPR chain the gateway is another recipient. For production and customer data, that is not a state, it is a risk.
Best for: Proof of concept with a throwaway key. Not for: real customer data.
Approach 3: Your own MCP endpoint
The official route: You operate your own MCP server in front of your API, with per-user OAuth, scopes per tool, idempotency, mandatory confirmations, and an audit log. awork and clockodo show that this is becoming the standard: awork as the benchmark at 53/100, clockodo with an endpoint that our test found before it was documented.
The effort is the price, and it is predictable: With a standard architecture, build and handover come in at a fixed price of 2–4 weeks. After that, the endpoint belongs to you.
The decision
| Proxy | Gateway | Own endpoint | |
|---|---|---|---|
| To first demo | Days | Minutes | 2–4 weeks |
| Who holds the key? | Proxy provider | Gateway provider | You |
| Security per tool | No | No | Yes (scopes) |
| Audit log | No | With the provider | Yes, on your side |
| For customer data | No | No | Yes |
→ Where your API stands today, the free live test shows in under a minute: reachability, discoverability, and OAuth signals, measured instead of guessed.