Odoo MCP Server: Talk to Your ERP in Plain Language
An Odoo MCP server lets AI assistants read and write Odoo records - CRM, inventory, accounting - through the open Model Context Protocol, with per-model access control. Inwizards has worked deep inside Odoo for years, from the Amazon Connector for Odoo to full implementations, on Community and Enterprise alike.
What is an Odoo MCP server?
An Odoo MCP server exposes your Odoo database to AI assistants through the open Model Context Protocol. Assistants can then read and update records across modules - leads, sales orders, stock, invoices - in plain language, restricted by per-model access control you configure.
One server, every Odoo module
Point tools cover a single app. MCP access spans the whole database — scoped model by model.
Odoo's whole appeal is that CRM, sales, stock, and accounting share one database. An Odoo MCP server inherits that: connect once, and your assistant can follow a question wherever it leads — from a quotation to its delivery order to the invoice behind it. Here is what natural-language access looks like, module by module.
CRM
Pipeline, lost reasons, and activities become questions instead of saved filters.
“Which leads have had no activity in fourteen days?”Sales
Quotations and orders, traced from confirmation through to delivery.
“Which confirmed orders are still waiting on delivery?”Inventory
Stock levels and movements across every warehouse and location.
“Which products are below their reorder point right now?”Accounting
Receivables, payables, and journal entries answered in plain words.
“Show unpaid invoices past 30 days, largest first.”Purchase
Supplier orders and expected arrivals without opening a single RFQ.
“Which purchase orders are overdue from vendors?”Manufacturing
Production orders, components, and whatever is holding them up.
“What is blocking this week’s manufacturing orders?”Helpdesk
Ticket queues summarized for you instead of scrolled by you.
“Summarize open tickets by team and by age.”A working day with an Odoo MCP server
Three roles, three ways the same server earns its keep.
The people who benefit most are rarely the ones who configured Odoo. They are the managers who know exactly what they want to know, but not which app, filter, or report will surface it. For them, plain language is the interface Odoo never shipped.
The morning starts with two questions instead of two dashboards: what dropped below reorder point overnight, and which incoming purchase orders slipped. The assistant reads stock and supplier orders from the same database, so the natural follow-up — draft a replenishment for the three worst shortfalls — can become a scoped write once you permit it. No exports, no pivot tables, no waiting for the one person who knows the Inventory app inside out.
Rather than opening Accounting and building a filtered view, she asks for overdue customer invoices grouped by customer — then asks which of those customers also have open orders sitting in Sales. That second question is the point: it crosses modules, the kind of thing a person normally stitches together by hand. The assistant reads only what finance chose to expose; payroll was never on the map.
Before the Monday pipeline call he asks for last week’s stage changes, deals with no next activity scheduled, and quotations that have sat unanswered. Then the one write he chose to allow: log a follow-up activity on each stalled deal. The meeting opens with answers on the table instead of ten minutes of screen-sharing.
Community and Enterprise — both welcome
The server talks to your database and honors your record rules, whichever edition you run.
Odoo Community
Self-hosted Community installs sit naturally beside an MCP server on the same infrastructure — and beside on-premise AI models, so the conversation and the data both stay inside your network. Custom modules are mapped in during configuration rather than ignored.
Odoo Enterprise
On Enterprise, the server works alongside hosted or on-site deployments and leaves your existing access rights intact. Per-model scoping applies identically: you decide which models the assistant may read, which it may write, and which it never sees at all.
How to put it to work
A deliberately boring rollout — in ERP, that is a compliment.
- Map your models
List the Odoo models your team actually asks about — contacts, sale.order, stock.quant, account.move, plus your custom ones. This map becomes the server’s entire world; a model left off it simply does not exist to the AI.
- Set per-model permissions
Mark each model read, read-write, or hidden. Most teams expose a handful read-only and hide HR outright. Your existing Odoo record rules keep applying underneath.
- Connect an AI client
Claude, Cursor, or a custom agent connects over the open protocol and authenticates against the server. From then on your team asks in chat and the answers come from live Odoo data.
- Start read-only, expand to scoped writes
Run read-only until the answers have earned trust, reviewing the logs as you go. Then grant writes narrowly — logging activities, creating drafts — one model at a time.
Part of the Inwizards Odoo practice
This server is not a side project bolted onto Odoo from outside. Inwizards has built inside Odoo for years — the Amazon Connector for Odoo, implementations, customizations, and AI-driven CRM work — and that is precisely the knowledge an MCP server needs, because a server that misreads models and record rules produces confident, wrong answers.
Explore the wider practice: Odoo AI Smart CRM, our guide to choosing an Odoo development company, and the Amazon–Odoo Connector.
Odoo MCP questions
What Odoo users ask before connecting AI assistants to their ERP.
Yes, both editions, including customized installations. Custom modules and fields are mapped in during configuration, and the record rules you already maintain in Odoo keep applying underneath the server's own per-model scoping.
No. The server exposes only the models you list during setup, each marked read, read-write, or hidden. Anything you leave off that map, payroll and HR being the usual examples, is invisible to the AI entirely.
Low-risk, reversible ones: logging a CRM activity, scheduling a follow-up, creating a draft record that a human still confirms. Teams typically run read-only for a while, review the logs, then open writes one model at a time.
Anything that speaks the open Model Context Protocol, which today means Claude and Cursor natively, agent tooling from OpenAI, and any custom agent your developers build against the standard. You are never tied to one AI vendor.
Yes. Self-hosted Odoo, the MCP server, and open AI models can all run inside your network, which is the arrangement many Community users prefer. Hosted and cloud Odoo deployments work just as well.
They are treated as first-class citizens. During the mapping step we include the custom models and fields your team relies on, so questions about them are answered just like questions about core modules.
With an Odoo MCP server. We build the server against your Odoo instance - Community or Enterprise - you add it to Claude as a connector, and Claude can then read and, where permitted, write Odoo records across CRM, inventory, and accounting in plain language.
Talk to your Odoo in plain language.
Book a demo and ask live questions of an Odoo database over MCP - then scope which models your own assistants should see.