The question we have been asked most often since the rise of the Model Context Protocol (MCP): “we already have a REST integration on Odoo — why would I still need an MCP server?” The short answer: because the user changes. A REST API is built for software you program yourself. An MCP server is built for an AI client that only decides which action is needed at the moment the question is asked.
Two layers, not competitors
Under the bonnet, an MCP server often uses the same APIs or methods as your existing integrations. The difference lies in the interface facing upwards. With REST, the developer knows in advance which endpoints exist and programs the path. With MCP, the server publishes during the session which tools exist, what they do and what input they expect — and the model chooses.
Vergelijking
| Eigenschap | REST API | MCP |
|---|---|---|
| Doelgroep | Applications and developers | AI hosts, agents and MCP clients |
| Ontdekbaarheid | Externe documentatie, OpenAPI-schema | Server publishes tools during the session |
| Semantiek | Technical fields and status codes | Descriptions intended for model selection |
| Autorisatie | Set up per integration | Per tenant, user and capability, on top of Odoo permissions |
| Foutafhandeling | Code vangt fouten af | Error message is input for the model's next attempt |
| Beheer | Per integration | Centrally per MCP server or gateway |
When do you choose REST?
- Fixed, high-frequency machine-to-machine integrations: stock synchronisation, order import, accounting integrations.
- Situations where you need exact, repeatable payloads and idempotency.
- Integrations with strict SLAs where non-determinism is unacceptable.
When do you choose MCP?
- Questions you cannot pre-programme: “which open quotations are running with customers who have a support ticket this month?”
- Research and reporting by people who know neither SQL nor Odoo Studio.
- Preparing drafts — a quotation line, a ticket reply, a project schedule — with a human approving.
- Situations where you specifically do not want credentials floating around in prompts or loose scripts.
The architecture principle you must not skip
MCP must never bypass existing authorisation. An MCP layer should respect the permissions in Odoo and can apply stricter scopes on top. In the DAADit Hosted MCP server this happens at three levels: which Odoo models are visible (model gating), which actions are allowed (capability gating: read, create, write, execute) and per user within a tenant. By default only the read-only tools are enabled — odoo_search, odoo_search_read, odoo_read and odoo_fields_get.
In practice: side by side
Most Odoo environments we support end up with both layers. The REST integrations keep doing what they do well: predictable, high-volume data traffic. The MCP layer is added for the human, variable questions — with logging per call, so you can trace afterwards who performed which action via which model.
A concrete example: a wholesaler synchronises stock every fifteen minutes via REST — that stays as it is, because it has to be exact and idempotent. But the question from the internal sales team (“which backorders affect customers with an open complaint?”) goes via MCP, because nobody built an endpoint for that in advance.
Practical tip: start with the MCP layer in read-only mode alongside your existing REST integrations and let one team work with it for two weeks — the questions they ask will tell you exactly which scopes you need next. Not sure which layer fits a specific integration? Contact DAADit Group — we are happy to think along about the architecture.
Vervolg lezen: how to connect Claude to Odoo, or the security and governance section of the product documentation.
Want to try it yourself? The DAADit Hosted MCP server for Odoo is free to start with 50 calls per day — no installation, no credit card. Create a free account or read the technische productdocumentatie.