Odoo MCP: what it sees, and what it does not

The question comes up in every meeting now: “Odoo is shipping its own MCP connector — doesn’t that settle it?” The honest answer is: partly, and less than you would think. What follows is what an Odoo MCP server actually exposes, what it cannot expose however well it is built, and why that difference decides what you still have to build yourself.

What an MCP is, without the jargon

A language model knows nothing about your company. To act, it needs two things: a list of what it is allowed to do, and a way to do it. The Model Context Protocol is a convention that describes exactly that — a piece of software publishes what it can do, a model discovers it and uses it, with no glue code written between the two.

The closest analogy is a power socket. Before, every appliance came with its own fitting, and you needed one adapter per pair. A standard socket does not make appliances better — it removes the adapter. That is what an MCP does, and it is already considerable: an agent can query your Odoo without anyone building a connector for it.

What it does expose — and it is a lot

This needs saying plainly, because the opposite is often claimed: Odoo’s ORM describes its own structure, and your custom developments appear in it the moment they are installed. A module that adds a field to an order line registers that field in the model description tables, exactly like a native one. Nothing distinguishes them technically.

So an agent wired to that introspection gets, for every model: the technical field names, their labels, their types, their relations to other models, the allowed values of a selection, whether a field is required, and any help text. It can read, filter and write, within whatever permissions you grant it.

So do not rely on the argument that “MCP won’t see your custom work”. It will. Anyone telling you otherwise has not looked, and your CTO will notice within ten minutes.

Three status fields, and only one that counts

Here is what we find in almost every Odoo older than three years. On a single order line, three things coexist:

• the native status field, the one Odoo ships, following the standard order cycle;
• a field added in 2022 by a custom development, to track a state the standard did not carry at the time;
• a third one, which arrived with a third-party module and partly overlaps the second.

All three exist, all three are populated, all three are perfectly visible to introspection. No technical signal says which one counts. And yet your teams know — without ever having written it down: since the upgrade, the native one decides, the 2022 field is only kept alive by an automation nobody dared switch off, and the third feeds a monthly export and nothing else.

That is the difference between schema and meaning. The schema says: “there are three status fields.” Meaning says: “this one counts, the other two are leftovers, and here is what breaks if you write to them.”

What an agent gets wrong, and why that is worse than an error

Ask a well-connected but poorly briefed agent: “which orders are awaiting delivery?” It will pick a field. Most likely the one whose name is closest to the question — the 2022 custom field, precisely, because it is called something like “delivery status”. It will return a list. The list will be coherent, neatly formatted, and wrong.

The problem is not the error: it is that the error is invisible. An agent that fails openly gets corrected. An agent that is right nine times out of ten, and wrong the tenth without flagging it, destroys trust faster than it creates value — and it destroys it for every use case that comes after.

What has to be built on top

Between schema and meaning, a layer is missing. There is nothing mysterious about it, and it cannot be bought: it is written, out of what your teams already know. It states which field counts for which question, which writes are allowed and which need human review, which business rules exist nowhere in the database, and which leftovers to ignore.

This layer is not documentation: documentation goes stale quietly. It is an executable description, versioned alongside your Odoo, tested like the rest. And there are only two ways to get it: knowing Odoo well enough to read the database, and knowing your company well enough to know what it means.

The economics, which is the real point of this article

AI platforms replace each other quickly. The one you pick this year is probably not the one you will be running in two: models change, prices collapse, protocols standardise. Everything you invest inside a platform is paid again at every switch.

The meaning layer does not change when the platform changes. It describes your company, not your supplier.

It is the only durable asset in this story, which is why it had better belong to you. The connector will end up being provided — by Odoo, by a vendor, by standardisation. That is not where the value sits.

What we do with it

We integrate Odoo and we build agents around it: the same team reads the database and writes the meaning layer, which spares everyone the meeting where the integrator explains to the AI specialist what a field means. And we say it upfront: some tasks will disappear. Better to know at kick-off than at handover.