Same goal. Three very different doors.
Everyone wants the same thing: let an assistant read the business straight from Odoo. Where the approaches split is where the door sits and who has to hold it open.
The laptop bridge
A typical App Store module
A module re-publishes Odoo's XML-RPC, and a small program on each user's machine translates MCP into those calls. Neat for one developer at a desk. It isn't an endpoint the browser and phone assistants can reach, and every user installs and maintains the bridge themselves.
Native on the instance
Odoo 20 built-in MCP
Odoo 20 Enterprise builds an MCP endpoint straight into the ERP. Clean and well-made. But it's v20-only, Enterprise-only, and header-authenticated, so the assistants that require a proper sign-in flow (claude.ai, ChatGPT) are locked out.
The governed platform
360 AI MCP
A real MCP endpoint on the 360 AI server, in front of the Odoo you already run. Users sign in with their own Odoo account from any client, scoped to the models you choose, read-first, and every call runs as the person who asked.
The comparison, row by row.
Every row is checkable against public source. Where a competing approach is genuinely fine for a use case, we say so further down.
| Capability | Recommended360 AI MCPGoverned platform in front of your Odoo | Typical App Store moduleXML-RPC + a local bridge app | Odoo 20 nativeBuilt into the ERP · Enterprise |
|---|---|---|---|
| Real remote MCP endpoint | Native /x360mcp, streamable HTTP + JSON-RPC 2.0 |
Re-exposes XML-RPC; a bridge app on each laptop speaks MCP | Native /mcp on the instance |
| Connect claude.ai (web + mobile) and ChatGPT | Yes — OAuth sign-in, no bridge | Desktop and scripted clients only | Header auth only; no OAuth discovery |
| Sign in with your Odoo account (OAuth 2.0 · PKCE) | Authorization code + PKCE, dynamic registration, refresh | Paste a static API key | Paste a static, mcp-scoped key |
| Every call runs as the real user (ACLs + record rules) | Yes — no shared super-user | Yes — bound to the key's user | Yes — runs non-sudo, user's own rights |
| Read-first by design | No generic write tools; methods are opt-in per model | Full create / write / delete available per model | Read-only by default; write tools opt-in per tool |
| Governed access controls | Model + per-method allowlists; private methods blocked | Per-model read / write / create / delete toggles | Curated server-action tools, enabled per tool |
| Works with the Odoo you run today | Odoo 16 · 17 · 18 · 19 | Odoo 18 / 19 | Odoo 20 Enterprise only (unreleased) |
| No new public surface on your Odoo | Rides the existing 360 connection | The bridge must reach your Odoo directly | Endpoint lives on the instance you expose |
| Stored audit trail in Odoo | Logged to a model, with retention | Logged to a model | Structured server logs, no stored model |
| One platform, many Odoo environments | A hub fronts every connected environment | One install per database | Built into each instance |
| License | Open source · LGPL-3.0 | Open source · LGPL-3.0 (varies) | Enterprise (paid tier) |
| Available today | Shipping now, on Odoo 16–19 | Available now | Ships with v20, ~fall 2026 |
The four that change the day-to-day.
Most rows are details. These four are the ones your users and your IT team feel within the first week.
Connect from anywhere
Because users sign in with OAuth, claude.ai in the browser and the Claude and ChatGPT apps on a phone just work. The other two need a client you can hand-configure on a desktop, so the CFO on their phone is out.
Answers, not write access
360 AI MCP exposes no generic create, write or delete tool at all. Change happens only through a public method you deliberately allowlisted. The bridge module ships full CRUD; native v20 can be switched to write per tool.
Your Odoo, your version
It runs against Odoo 16, 17, 18 and 19 today. Odoo 20 native lands with v20 Enterprise around fall 2026, so it's off the table unless you upgrade and pay for Enterprise. No forced upgrade to talk to your data.
Nothing new exposed
Clients reach the 360 AI server; your Odoo talks to it over the connection it already has. No new public port, no bridge program pointed at your database from a laptop. One surface to secure, not one per user.
Where each one is the right call.
A comparison you can share should be honest, or it isn't worth sharing. So here's when we'd point you elsewhere.
The App Store bridge
If you're a single developer who lives in Claude Desktop or Cursor and just wants to query your own Odoo, the bridge is quick and free. It solves that narrow case well. It stops scaling the moment you have real users, phones, browsers, or a "no blanket write access" rule.
Odoo 20 native
Once you're on Odoo 20 Enterprise and your assistants are header-based (Claude Code, Gemini CLI, n8n), the built-in endpoint is a genuinely good, well-engineered option, and a nice validation of this whole design. Its extensible server-action tools are excellent. It just can't do browser or phone sign-in, and it isn't here yet.
360 AI MCP
When more than one person needs it, on more than one device, across the Odoo versions you actually run, with governance your IT team signs off on, this is the one built for that. It's also the only one of the three that lets a colleague add the connector in claude.ai and sign in as themselves.
The questions this comparison raises.
Won't Odoo 20's native MCP make a third-party solution unnecessary?
Isn't the App Store module basically the same thing, for free?
Do you actually run as the user, like the others?
Is this comparison fair, or is it marketing?
One endpoint. Every assistant.
The Odoo you already run.
360 AI MCP is part of the 360 AI platform by 360 ERP. A governed MCP endpoint in front of your Odoo, so every assistant in your company gets the same, safe view of the business, and signs in as themselves to get it.