MCP vs. a Normal API
REST APIs already have machine-readable descriptions (that is what OpenAPI is), and tools already exist to turn those into AI tool definitions. So the honest comparison is narrower than most introductions suggest:
| REST + OpenAPI | MCP | |
|---|---|---|
| When tools are discovered | When a developer generates a client | Live, every session |
| Who the description is for | Developers reading docs | The model, deciding what to call |
| Can the server ask you a question? | No | Yes |
| Failure handling | One status code for everything | Split: developer errors vs. model-fixable errors |
| Integration effort | Per app, per service | Once per app, once per service |
When MCP is not worth it:
- You control both ends and there is one of each. A direct API call is simpler.
- Nothing about the call is model-facing. Service-to-service traffic gains nothing.
- You need high throughput or low latency. MCP adds a hop and an envelope.
- You are moving large files or streaming binary. Use the underlying protocol.
The rule of thumb: adopt MCP when the number of connections is the problem. Integrating one thing with one other thing means paying the costs without collecting the benefit.