Architecture · 4 setup options · 7 min read
Connecting AI agents like Claude, ChatGPT or Copilot to Odoo is now standard practice. The MCP server is the translator that sits between the two, turning a question in plain language into the right call against your database. But there are four very different places that translator can live, and the choice has real consequences for your security, your costs, and how your team uses it day to day.
The shortcut: pick where the server lives first, and most of the other tradeoffs fall out of that. This piece walks through the four options, what each is good for, and how to decide.
An MCP server is the bridge between your AI agent and your ERP
MCP, short for Model Context Protocol, is the protocol AI agents use to call tools and read data. For Odoo, an MCP server is the component that translates "show me last quarter's invoices" from Claude into the right XML-RPC or JSON/2 call against your database.
Two quick clarifications before we compare setups. MCP is not just a REST wrapper. It exposes tools, resources, and prompts to the model in a structured way. And an MCP tool is not an agent: tools execute; agents plan. For a deeper primer on MCP itself, read Daniel's introduction: MCP as the translator between your AI and your tools.
Four ways to set up an MCP server for Odoo, at a glance

| Local | Embedded in Odoo | VPS | Hosted (Pantalytics) | |
|---|---|---|---|---|
| Where it runs | Your laptop | Inside Odoo | A VPS you control | Managed service |
| Setup effort | Low | Medium | High | Lowest |
| Multi-device access | No | Yes (basic auth) | Yes (OAuth) | Yes (OAuth) |
| Multi-AI client | One client at a time | Limited | Yes | Yes |
| Team-ready | No | Per-user only | Yes, you build it | Yes, built in |
| Identity layer | None needed | On you | On you | Managed (Zitadel) |
| Maintenance | You | You | You | Pantalytics |
| Typical cost shape | Free + your time | ~€99 module + ops | €10–50/month VPS + ops | Subscription |
If you stop reading here, the table covers most of what you need. The rest goes into the why.
Running it locally is the fastest start and the smallest world
The simplest setup: install an MCP server on your laptop, point your Claude Desktop (or other client) config at it, and you're talking to Odoo in minutes.
What it gets you. Zero infrastructure. Direct access to your local files, your CLI, and your machine. The server can call Odoo over the API or MCP protocols, and if you're on Odoo.sh you can wire in SSH access so the agent can pull logs straight from your instance.
Where it falls short. The server lives and dies with your laptop. Close the lid, the server stops. There's no access from your phone, your browser, or another device. And no memory of the chat or server state on those surfaces either. You're also the one patching dependencies and watching for security flaws. And because keys typically sit in plain config files on disk, this is the setup where credentials leak.
Best for: solo developers prototyping, or anyone who only ever uses one AI client on one machine.
Embedding the server in Odoo feels native but exposes your database
This is the option that maps most directly to how Odoo already works: install an MCP server as an Odoo module, and your agent talks to your database from inside the application.
What it gets you. It aligns with Odoo's module model. You get fine-grained control over what flows in and out of the database because access rights are already there.
Where it falls short. Odoo doesn't officially support this yet. The market is a patchwork of third-party paid modules (usually around €99), and you have very little visibility into what you're actually installing into your database. Once it's in, you own the upgrades, the security audits, and the patches. Run multiple Odoo instances and you'll get version drift across them. You also still carry the identity-layer complexity (more on that in the VPS section). And one constraint worth flagging early: this option is a non-starter on Odoo Online, which doesn't allow custom modules. You need Odoo.sh or on-prem.
So far, none of the available modules has earned the level of trust we'd build a production AI workflow on.
Best for: a single Odoo.sh or on-prem instance, where you've already vetted the module code yourself.
Self-hosting on a VPS unlocks team access, with a maintenance bill
The next step up is a streamable HTTPS MCP server hosted on your own infrastructure: a Hetzner box, an AWS instance, anything you control. This is where an MCP setup starts to behave like a normal SaaS backend.
The jargon worth unpacking: "streamable HTTPS" means many different AI tools and devices can connect to one server, with the authentication and identity layer handled online. That matters because Claude, OpenAI, Mistral and Microsoft Copilot all handle auth differently. You're dealing with dynamic client registration, OAuth, OpenID, and a stack of handshakes that need to interoperate cleanly. Done well, the identity layer disappears for the user. Done poorly, it becomes its own product to maintain. That complexity also applies to anyone running the embedded option above.
What it gets you. Multi-client, multi-device access. No tool-call limits. You only pay for the VPS. Full control over data, logs, and updates.
Where it falls short. You maintain the server, the identity layer, the certificates, the upgrades. A single VPS is also a single point of failure: when the box goes down, every AI agent in your company loses access at the same time.
Best for: teams who want control, are comfortable running infrastructure, and have someone in the on-call rotation.
A hosted service trades sovereignty for uptime and breadth
The hosted option is the same architecture as the VPS (one streamable HTTPS server, many clients, identity layer in the middle), except a vendor runs it.
What it gets you. Updates handled for you. A larger shared user base, so new features (and new AI client support) roll out continuously: Claude, ChatGPT, Mistral, Copilot, Grok, and others as they come online. Managed uptime, which is hard to match on a single VPS. And because the platform is multi-tenant, team plans, SSO and enterprise governance features are built in rather than bolted on. With Pantalytics specifically, that includes a managed Zitadel identity layer and a ready-made team plan: the parts you'd otherwise build yourself in Option 3.
Where it falls short, honestly. Your data flows through a third party. You inherit someone else's security posture. There's a degree of vendor lock-in: switching providers means re-onboarding your team and reconnecting your AI clients. And you have less freedom to customise the server's behaviour than you do on your own VPS.
Best for: teams that want AI access in production this week instead of this quarter, and that need it to work across multiple AI clients on day one.
Pick the setup that matches how your team already works
A short decision tree, not a sales funnel:
- Solo developer, just experimenting → Local.
- One Odoo instance on Odoo.sh or on-prem, comfortable vetting a module → Embedded, with eyes open.
- Team, ops capability in-house, want full control → VPS.
- Team, want it working now, want multi-AI support, want governance from day one → Hosted.
There's no single right answer. Only the answer that fits your team's tolerance for maintenance, your data sovereignty needs, and how many AI surfaces you actually use.
Pantalytics builds the hosted option and open-sources the rest
We run the hosted option (MCP Pro) on top of the same MCP server we publish as open source under Elastic License 2.0 at github.com/pantalytics/odoo-mcp-pro. If you'd rather run it yourself on a VPS, that's the codebase. The hosted side adds the parts you'd otherwise build yourself: Zitadel identity, team management, usage tracking, billing.
And if you want to tighten AI governance inside Odoo itself (agent identity, audit logs, and the building blocks for EU AI Act compliance), install our free Odoo companion module odoo-mcp-pro-governance alongside MCP Pro.
Whichever route you pick, the choice that matters most is the first one: where the server lives. Get that right and the rest is detail. Try MCP Pro →