Setting up an Odoo MCP server — and governing it

The Model Context Protocol turned "connect my AI to Odoo" from a custom integration into a configuration step: point an MCP client — Claude Desktop, Cursor, your own agent — at an MCP server for Odoo, and your ERP shows up as tools the model can call. The open-source servers on GitHub will get you a working connection in an afternoon. This piece walks the setup path, then spends its second half on the part the READMEs leave to you — because a working connection to your production ERP is precisely where the real questions start.

#What an Odoo MCP server actually does

MCP standardizes how AI tools ask other systems for data and actions. A server for Odoo exposes operations — read the pipeline, list overdue invoices, draft a quotation — as tools with typed inputs; the client's model decides when to call them and composes the results. The quality spread between servers is mostly in three places: how many operations they expose and how well-typed those are, how they authenticate to Odoo, and what happens between a tool call and your database. In Odient's server — which lists its 131 tools across 15 modules on that page — that last part is the product: every call through the same five-gate path as every other way in.

#The setup path

Whatever server you choose, the shape is the same. Connect the server to Odoo: an instance URL, a database name, and a credential — on Odoo 17 and 18 that conversation happens over XML-RPC, on 19 over the JSON-2 REST API. Connect the client to the server: MCP clients take a server entry in their configuration (a command or URL); once registered, the client lists the server's tools automatically. Ask something real: a first question like "which invoices are overdue?" exercises the whole chain — client, server, Odoo, and back. With Odient the sequence is: install the module on your Odoo, add the credential, point the client at the endpoint; the docs walk it credential-to-first-answer, and the connection looks like this from the client's side (figures from our seeded demo dataset):

# any MCP client — Claude Desktop, Cursor, your agent
tools/list  →  131 tools · 15 modules
tools/call  "account.invoice.overdue"
firewall    →  5 layers · passed
policy      →  read · allowed
result      →  $279,496.75 · 2 customers · 31–60d
audit       →  one record · tied to you

#The part the READMEs don't answer

Here is the engineering reality behind that credential you just configured. Most guides say "create an API key in Odoo's settings" — and keys created there are stored with a NULL scope, which Odoo's credential check accepts against any requested scope (res_users.py, _check_credentials). Meanwhile the RPC dispatch path re-checks scope per call, pinned to scope='rpc' for API-key credentials (odoo/service/model.py; branches 17.0 and 18.0 checked). Two consequences: a UI-minted key is effectively an all-doors key for whoever holds it, and "we use scoped keys" from any vendor deserves a follow-up question. The full write-up is in what ERP buyers get right about AI; the design answer we chose — short-lived session exchange bounding each call to the asking person's own permissions — is on the security page.

Beyond the credential, govern the connection like the production access it is: the server should act as a person, not as a superuser; writes should wait behind an approval gate you configure; refusals and successes should land in one audit trail your team can actually read. If the server you evaluate has no answer to those three, it is a demo tool, not an ERP connection — run it against a staging database and enjoy it there.

#Frequently asked questions