ivnvxd/mcp-server-odoo, reviewed.
One of the more inspectable open-source Odoo MCP servers: explicit tools, permissions delegated to Odoo, a genuine read-only switch. It is also XML-RPC-only on a version of Odoo that has moved on, and it ships a mode that takes the access-control module out of the path. Both are manageable if you know before you deploy.
What it is, in one paragraph
ivnvxd/mcp-server-odoo is an external Python MCP server that talks to Odoo over XML-RPC, paired with an optional companion Odoo module that carries the access control. It exposes a broad, generic surface — search, read, field inspection, aggregation, full CRUD and chatter — and it is one of the more inspectable projects in this space: the tool list is explicit, the permission model defers to Odoo's own access rights and record rules, and there is a real read-only switch.
Use it when you want a self-hosted server you can read end to end, you are on Odoo 16 or later, and you are willing to install the companion module. Look elsewhere when you need JSON-2 on Odoo 19, per-user OAuth against a multi-user client, or an audit trail that satisfies a compliance reviewer without extra work.
The specification, without the README adjectives
| Detail | What it means for you | |
|---|---|---|
| Shape | External Python server + optional Odoo addon | Two things to deploy, but the addon is where the controls live |
| Runtime | Python 3.10+ — uvx, pip, pipx or Docker | No Node toolchain; Docker image published |
| Transport | stdio or streamable-HTTP | stdio for local clients; HTTP is what a cloud client such as Claude needs |
| Odoo API | XML-RPC only | No JSON-2 — see the Odoo 19 note below |
| Odoo versions | 16.0+ in standard mode | Covers 16, 17, 18, 19 |
| Auth | API key (recommended) or username/password | Keys bind to a real Odoo user, so Odoo’s own rights apply |
| Writes | Full CRUD, plus chatter messages | Gated by model permissions and mode |
| Licence | MPL-2.0 | Permissive, file-level copyleft — not LGPL, not proprietary |
Note the licence line. MPL-2.0 is a file-scoped copyleft: modify one of its source files and distribute the result, and those files stay MPL. It combines cleanly with an LGPLv3 Odoo and with proprietary code around it, so it is unlikely to constrain a normal deployment — but it is a different licence from the one your Odoo is under, and a procurement reviewer will ask.
What this project gets right
Named tools instead of one escape hatch
The surface is broken into search_records, get_record, get_fields, list_models, aggregate_records, create_record, update_record, delete_record and post_message. That is the right shape, and it is not the universal one — plenty of Odoo MCP servers wrap XML-RPC's execute as a single tool and call the job done. When they do, a client-side allow-list has nothing meaningful to allow, because every model and method is reachable through the one tool you approved. This project mostly avoids that trap.
Authorisation delegated to Odoo, not reimplemented
Authentication uses an API key bound to a specific Odoo user, and the server states that it respects Odoo's built-in access rights and record rules. That is the correct architecture: the ERP already has a mature permission model, and an MCP server that invents a parallel one will diverge from it. Combined with a model allow-list configured in Settings → MCP Server, you get two independent gates.
A genuine read-only mode, and credential masking
ODOO_YOLO=read restricts the server to search and read operations — a real switch rather than a documentation suggestion, which is what you want for a first pilot. The server also withholds fields matching patterns such as *password, *secret, *token and *apikey from bulk reads. That is a thoughtful detail: without it, one ["__all__"] read can hand an LLM a column of credentials.
Aggregation server-side
aggregate_records does grouping in Odoo rather than shipping rows to the model to count. On ERP-sized tables this is the difference between a two-second answer and a timeout that gets blamed on the AI client.
Where it stops
XML-RPC only — which is a live problem on Odoo 19
This is the most consequential limitation. Odoo 19's current external API is JSON-2, and Odoo has marked XML-RPC and JSON-RPC for removal in Odoo 22. The server works on 19 today because 19 still serves XML-RPC. It is a dependency with a published end date, and if you are deploying onto 19 now you are choosing the deprecated transport. That is a defensible decision for a project supporting 16 through 19 from one code path — but make it deliberately, and put the migration on a roadmap rather than discovering it during an upgrade. JSON-2 vs XML-RPC and JSON-RPC.
“YOLO mode” bypasses the module that holds the controls
The project is refreshingly honest in its naming here, and the mode exists for testing and demos. But it is worth stating plainly: standard mode puts the companion Odoo module in the path, and that module is where the access control lives. YOLO mode takes it out. It will work against any Odoo with XML-RPC enabled and no addon installed, which makes it exactly the mode someone reaches for when the install is fiddly and the demo is in ten minutes. If you adopt this server, make “not YOLO in production” an explicit, written rule, and check the environment variable in your deployment pipeline rather than trusting the person who deployed it.
One key, one identity
An API key binds to one Odoo user. That is clean for a service account, and it means Odoo's record rules apply — but every person talking to the AI client arrives as the same Odoo user. Your audit log will show the bot, not the person who asked. For a read-only pilot that is usually acceptable; for writes it is the thing a compliance reviewer will find first. If per-user identity matters, you need a server that maps client identity to Odoo identity via OAuth.
call_model_method is the escape hatch, and it knows it
Arbitrary method invocation is restricted to YOLO mode, which is the right call — it is precisely the tool that undoes a carefully named CRUD surface. Just be aware the capability exists in the codebase, so “we only exposed safe tools” is a statement about configuration, not about what the binary can do.
What you would add before putting this on a real ERP
None of the following is a criticism of the project. They are the gap between a good open-source server and a governed ERP integration, and they are the same gap for almost every project in this category.
- Pin the mode. Set
ODOO_YOLO=readfor the pilot and assert on it in your deploy check. Treat any change to that variable as a change-controlled event. - Create a dedicated bot user with the narrowest possible groups, and never an administrator key. Then read the Odoo MCP security checklist and actually do the record-rule step.
- Curate the model allow-list by hand. The default posture should be the four or five models the job needs, not everything the bot user can technically see.
- Put the HTTP transport behind a reverse proxy with TLS and IP restriction. A cloud AI client needs a public endpoint; public does not have to mean open.
- Add the audit layer. Decide up front what a reviewer needs — who asked, which tool, which model, which record, which arguments, what came back, and what was denied — and confirm you can produce it before you enable writes.
- Plan the JSON-2 migration if you are on Odoo 19, so the XML-RPC deprecation is a scheduled task and not an incident.
If that list reads as more work than you wanted, that is the honest signal to compare it against an in-Odoo module that answers as the signed-in user and logs every question by construction — which is the design we took with Odin's own MCP module, and which is free on the Odoo App Store. We are obviously not neutral about that. The evaluation questions above are the same ones either way.
How it sits against the others
There is no universal winner in this category, and picking on tool count is how people end up with a large surface they cannot govern. The short version:
- You are on Odoo Online. You cannot install the companion module, so you are choosing between YOLO mode against the external API — with the Custom-plan gate in front of it — and a different architecture entirely. Odoo MCP on Odoo Online.
- You need per-user identity. Look for a project doing OAuth 2.1 with a real user mapping, not a shared service key.
- You want nothing to host. An in-Odoo module removes the extra service, the extra credential store and the extra thing to patch.
- You want the broadest version coverage from one codebase. This project is a strong candidate, and the XML-RPC choice is what buys that coverage.
The full field, with the seven questions we score against, is in Odoo MCP servers on GitHub, compared.
FAQ
What is ivnvxd/mcp-server-odoo?
An open-source MCP server, written in Python, that lets AI clients query and modify Odoo over XML-RPC. It pairs with an optional Odoo addon that carries the access control, and exposes named tools for search, read, field inspection, aggregation, CRUD and chatter.
Which Odoo versions does it support?
Odoo 16.0 and later in standard mode, which covers 16, 17, 18 and 19. It reaches Odoo through XML-RPC rather than JSON-2, which is what makes one code path cover that range.
Does it work with Odoo 19?
Yes, because Odoo 19 still serves XML-RPC. But 19’s current external API is JSON-2, and Odoo has marked XML-RPC for removal in Odoo 22 — so on 19 you are deliberately choosing the deprecated transport. Plan the migration rather than discovering it during an upgrade.
Is it safe to use on production Odoo?
Not by default, and not in YOLO mode. Standard mode puts the companion Odoo module — where the access control lives — in the path, and ODOO_YOLO=read gives you a real read-only pilot. Add a dedicated bot user, a hand-curated model allow-list, TLS with IP restriction, and an audit trail before any write is enabled.
Does it support per-user permissions?
It authenticates with an API key bound to one Odoo user, so Odoo’s access rights and record rules apply to that user. But everyone talking to the AI client arrives as the same Odoo identity, so your audit log shows the bot rather than the person. For per-user identity you need OAuth-based mapping.
What licence is it under?
Mozilla Public License 2.0 — a permissive, file-scoped copyleft. It combines cleanly with an LGPLv3 Odoo and with proprietary code around it, but it is a different licence from your Odoo and procurement will ask.
What is YOLO mode?
A mode intended for testing and demos that bypasses the companion Odoo module and works against any Odoo with XML-RPC enabled. Because it removes the module holding the access control, it should be a written rule that production never runs it — and a check in your deployment pipeline, not a matter of trust.
Related reading
Compare it against a module that runs inside Odoo.
Odin's MCP server answers as the signed-in user and logs every question by construction. Free on the Odoo App Store, or try the live sandbox first.