Short answer: use MCP for flexible, conversational AI access to Odoo; build a custom API integration when you need one fixed, high-throughput data pipeline; reach for RPA only when no API exists at all. They solve different problems. Here is the honest breakdown of each, so you can pick the right one instead of the trendiest one.
The three options, in one sentence each
- MCP — Odoo exposes its data and actions through one open, permission-aware protocol; any MCP-capable AI (Claude, others) discovers and uses them.
- Custom API integration — a developer writes glue code against Odoo’s External API (XML-RPC or JSON-RPC), wiring one specific use case end to end.
- RPA (Robotic Process Automation) — a bot drives Odoo’s web UI like a human would, clicking and typing, with no understanding of what the data means.
Quick comparison
| Criteria | MCP | Custom API integration | RPA |
|---|---|---|---|
| What it talks to | Odoo’s ORM via a protocol AI can discover | Odoo’s External API (XML-RPC/JSON-RPC) | Odoo’s web UI (clicks, forms) |
| Setup effort | Install once, AI adapts to your models | Build and maintain per use case | Record/build scripts per screen |
| Flexibility | High — new questions don’t need new code | Low — one integration = one job | Low — breaks on any UI change |
| Multi-AI / multi-model | Native — any MCP client connects | None — bespoke to whoever built it | None |
| Permission awareness | Runs under the connecting user’s Odoo rights | Whatever the integration’s service account can do | Whatever the bot’s login can do (often broad) |
| Best for | Conversational, exploratory, evolving AI use | One fixed, high-volume, well-defined pipeline | Legacy systems with no API at all |
| Odoo fit | Purpose-built for this (Cledoo MCP) | General-purpose, works with any external API | Doesn’t need Odoo have an API — that’s the point |
MCP: one standard, discoverable by any AI
MCP is the open protocol Anthropic introduced in 2024 for connecting AI models to external tools and data through a single interface, rather than a fragmented web of one-off integrations (see what MCP is for the deeper explanation — we won’t repeat it here). Applied to Odoo, an MCP server exposes your models, records, and actions as tools the AI discovers at connection time. Ask Claude something you never explicitly wired up — “which customers haven’t ordered in 90 days” — and it composes the answer from existing tools, on the fly.
Real strengths:
- No per-question engineering. The AI adapts to what’s available; you don’t write a new endpoint every time someone has a new idea.
- Works with any MCP client, not just one AI product — you’re not locked to a single vendor’s proprietary connector.
- When implemented natively (like Cledoo MCP), calls run under Odoo’s existing ACLs and record rules — the AI can’t see or do more than the connected user can.
Honest weaknesses:
- It’s still young as a standard (late 2024 onward); tooling and ecosystem maturity vary by client.
- Discovery-based flexibility is not what you want for one narrow, ultra-high-throughput job — you’re paying for generality you may not need.
- Not free of governance questions — an AI with broad tool access still needs scoping and oversight (that’s a separate topic; see our piece on governing agent access).
Custom API integration: full control, full responsibility
Odoo has shipped an External API for years: XML-RPC and JSON-RPC endpoints
that let external code authenticate and call execute_kw against any model —
read, write, create, unlink, whatever the calling user can do. It’s mature,
well documented, and the right foundation when you’re building one specific,
long-lived pipeline: nightly sync to a data warehouse, a fixed webhook that
creates leads from a form, a billing system reading invoices on a schedule.
Real strengths:
- Maximum control. You decide exactly what’s called, when, and how errors are handled.
- No dependency on an emerging protocol — XML-RPC/JSON-RPC has been stable since early Odoo versions.
- Ideal for high-throughput, fixed-shape jobs where “the AI figures it out” is the wrong model entirely — you want deterministic behavior, not a language model in the loop.
Honest weaknesses:
- This is the N×M problem: every new AI client, every new use case, is a new piece of code to write and maintain. Ten integrations means ten codebases to keep working across Odoo upgrades.
- Nothing adapts automatically. Add a field, change a workflow, and the integration needs a developer to catch up — it has no way to “notice” and ask.
- Auth and scoping are entirely on you to design well (a service account with API keys is common, and it’s easy to over-grant access if you’re not careful).
Custom API integration isn’t a lesser option — it’s the right option when the job is fixed and the volume is real. It’s the wrong option when what you actually want is an AI that can answer new, unanticipated questions about your Odoo without a developer in the loop each time.
RPA: the fallback when there’s no API at all
RPA — as Gartner and IBM define it — automates tasks by driving software the way a human would: through the user interface, with configured scripts or “bots” that click, type, and read screens. It exists because plenty of enterprise software has no usable API, and RPA was the only way to automate it.
Real strength: it works on literally anything with a UI, API or not. If a system is a black box with no integration surface, RPA can still automate a repetitive task against it.
Honest weaknesses — and they’re serious for Odoo specifically:
- Odoo has a mature API (External API, and now MCP). Driving its UI with a bot instead of calling its data layer directly is strictly worse: slower, more fragile, and it gets none of Odoo’s ACL enforcement at the data level — it inherits whatever the logged-in bot account can click.
- Zero semantic understanding. An RPA bot doesn’t know what an invoice is — it knows “click this pixel, type in this field.” Change a button’s position, rename a menu, add a wizard step, and the bot breaks.
- Maintenance is a constant tax: every Odoo update is a potential script breakage, discovered only when the bot fails silently or does the wrong thing.
For Odoo, RPA is a last resort, not a strategy — reach for it only if you’re automating a third-party tool that genuinely has no API, not Odoo itself.
How to actually decide
Ask three questions:
- Is the job fixed and high-volume, or exploratory and evolving? Fixed → custom API integration. Evolving, conversational, “let people ask questions” → MCP.
- Does the target system have an API at all? If yes (Odoo does), RPA is rarely justified. If no, RPA may be your only option.
- Do you need one AI model forever, or flexibility across models and clients? MCP is the only one of the three built for multi-client, multi-model use by design.
Where Cledoo MCP fits
Cledoo MCP is the MCP path for Odoo, built as a native module rather than an external relay. Classic is free and ships 17 tools covering the day-to-day data operations most teams need. Pro is a one-time €189 and adds governance controls, works entirely inside your own Odoo instance — On-Premise or Odoo.sh — with your existing ACLs, and no external server holding your data. It doesn’t replace a well-built custom integration for a fixed, high-volume pipeline, and it has nothing to do with RPA. What it replaces is the pattern of writing a new bespoke integration every time someone wants the AI to do one more thing in Odoo.