Odoo 20 Native MCP Server: What Actually Ships in ai_mcp

Last updated: August 9, 2026. We build Odoo MCP servers for clients today, against Odoo 17, 18 and 19, using external Python gateways that translate MCP tool calls into XML-RPC or JSON-RPC against a running Odoo instance. Odoo 20 changes that pattern at the source. Reported module name: ai_mcp. It ships as part of Enterprise and turns the Odoo instance itself into an MCP server, at a single endpoint, with no external gateway process required.

Confirmed vs still speculation

This entire post is built on Odoo's Partner Days roadmap presentation and early reporting from partner channels, since Odoo 20 has not shipped. Everything below reflects what has been reported for the ai_mcp module design. We are not speculating beyond what has been described; where something is genuinely unclear (exact tool-registration UI, final auth flow details) we say so rather than filling the gap with a guess.

What MCP is, quickly, for readers who build integrations but haven't touched MCP yet

The Model Context Protocol (MCP) is an open standard, using JSON-RPC 2.0, that lets an AI model or agent call structured "tools" exposed by a server, with a defined discovery mechanism so the model can see what's available and what each tool expects. It has become the common interface for connecting LLM-based agents (Claude, and others) to real systems, replacing a lot of bespoke API-wrapper code with something the client-side agent tooling can drive directly.

The architecture Odoo 20 reportedly ships

• Module: ai_mcp, Enterprise only.
• Endpoint: a single /mcp route on the Odoo instance itself.
• Protocol: JSON-RPC 2.0, targeting MCP spec revision 2025-11-25.
• Tool model: tools are not hardcoded in Python. Each exposed tool is an ir.actions.server record flagged for MCP use, built on Odoo's existing ai.tool framework. This means the set of tools an Odoo instance exposes over MCP is configuration, not code you have to ship separately, which is a real change from how we build gateways today.
• Context injection: the server automatically injects the current user, timezone, active company and UTC context into every call, so a tool implementation doesn't have to re-derive that from scratch on each request the way an external gateway typically does.
• Available tools today: five, all read-only: context retrieval, model listing, field inspection, record search, and grouped analytics. Write functions exist in the underlying code but are disabled by default and must be explicitly enabled by an administrator. That default-off posture for writes is a sensible security choice and matches how we'd configure a gateway ourselves if we controlled the defaults.
• Auth: secured through a dedicated API key section, separate from a user's regular login credentials.

Architecture, before and after

The diagram shows the shape of the change. Today, an MCP client talks to a small external Python process, which in turn calls Odoo's XML-RPC or JSON-RPC API over the network, translating between MCP's tool-call format and Odoo's RPC format by hand. In Odoo 20 Enterprise, the MCP client talks to /mcp directly on the Odoo instance. The translation layer, the process management, the auth bridging, all of that collapses into the Odoo server itself.

The two modules people will confuse, and why the distinction matters

There is a separate, existing community mcp_server module on the Odoo Apps store, built for Odoo 19.0, that takes a different approach: OAuth 2.1 discovery and a stdio bridge for local MCP clients. It is a third-party module, not built into Odoo core, and it predates the native Enterprise version. If you already installed the community mcp_server module on a 19.0 instance, you are not looking at an early version of ai_mcp, you are looking at a different project with a different auth model (OAuth 2.1 vs a dedicated API key section) and a different transport (stdio bridge vs a single HTTP JSON-RPC endpoint). Getting this distinction right matters because the migration paths are not the same: moving from the community module to the native one is closer to a re-integration than an upgrade, since the tool definitions and auth flow don't map 1:1.

What this means if you already run an external MCP gateway against Odoo

If we've built you a gateway against Odoo 17, 18 or 19, here is the honest assessment. You do not need to rip it out the day Odoo 20 ships. The gateway pattern still works, and if you're not on Enterprise, ai_mcp isn't available to you regardless. But if you are on Enterprise and plan to upgrade to 20, the native server is very likely the better long-term home for read-only tool access: fewer moving parts, no separate process to keep alive and patch, and context injection handled for you. We would keep a custom gateway only for tool logic that genuinely doesn't map onto the ir.actions.server / ai.tool model, or where you need write access patterns more nuanced than a global enable/disable switch.

A worked example of the tool-model difference

To make the ir.actions.server / ai.tool design concrete: in a gateway we've built for a client, exposing "find all overdue invoices for a partner" as an MCP tool meant writing a Python function in the gateway process, mapping its input schema by hand, and maintaining that mapping separately from the Odoo instance itself, if the underlying Odoo report logic changed, the gateway code had to be updated in a second place. Under the reported ai_mcp model, the equivalent would be defined as a server action inside Odoo itself, flagged for MCP exposure, using the same ai.tool framework Odoo already uses for its other AI-assistance features. The tool definition lives next to the business logic it exposes, in the same codebase, versioned the same way as everything else in the instance. That's the practical difference between "a tool is a thing you maintain in a separate service" and "a tool is a thing you maintain in Odoo," and it's the reason we think this is a genuinely useful architecture change, not just a convenience wrapper.

Security considerations worth thinking through now

A single /mcp endpoint on your production Odoo instance, even read-only, is still a new network-facing surface with database access behind it. A few things worth planning for regardless of exact final implementation details:

• API key scope and rotation. Treat MCP API keys with the same operational discipline as any other production credential, scoped narrowly, rotated on a schedule, never shared across environments (a staging key should never work against production).
• Network exposure. Whether /mcp should be reachable from the open internet or only from a trusted network (a VPN, an internal service mesh) depends on your threat model and who's actually consuming the tools. We'd default to restricting it at the network layer in addition to the API key, defence in depth, not relying on the key alone.
• Monitoring tool call volume. An AI agent with a bug, or a compromised key, calling record-search tools in a tight loop is a real operational risk even for read-only access, large searches against a big database aren't free. Basic rate limiting and logging on the endpoint is worth having from day one, not added after an incident.

Practical planning steps now, before 20 exists

• If you're evaluating MCP access to Odoo today, and you're not committed to Enterprise, use the community mcp_server module or a custom gateway, both work now.
• If you're on Enterprise and Odoo 20 is realistic for your upgrade timeline, hold off building a large custom gateway investment purely for read-only access, since the native server likely covers exactly that use case with less infrastructure.
• Audit which of your integration's tool calls are genuinely write operations. Those will need the writes-enabled admin flag turned on deliberately, it will not be silently available.
• If security review is part of your deployment process (it should be), start scoping the network and credential questions above now, so they're not last-minute decisions made under launch pressure once 20 is available to test.

FAQ

Is the Odoo 20 MCP server available in Community edition?

Reported as Enterprise only. This is one of the concrete new items on the Enterprise side of the Community vs Enterprise comparison, see our full breakdown.

Does ai_mcp replace the community mcp_server module?

Not automatically. They are separate projects with different auth models and transports. If you're on 19.0 using the community module today, moving to ai_mcp after upgrading to 20 is a re-integration, not an in-place upgrade.

Can the MCP server write data in Odoo 20?

Write functions exist in the codebase as reported, but are disabled by default. An administrator has to explicitly enable them.

What authentication does the native MCP server use?

A dedicated API key section, separate from normal user login. Full OAuth flow details have not been independently confirmed by us at time of writing.

Sources: Model Context Protocol specification, Odoo Partner Days roadmap presentation (April 2, 2026), Odoo Apps store listing for the community mcp_server module.