If you want your AI agent to talk to your Odoo ERP, you have two choices: give it direct API access to Odoo's XML-RPC endpoint, or route everything through an MCP (Model Context Protocol) server that acts as a middle layer.
The MCP approach is trendy — it's an open standard from Anthropic, adopted by Claude, ChatGPT, VS Code, Cursor, and others. It promises a "USB-C port for AI" — a universal connector so any AI app can talk to any tool through a single protocol.
But trendy isn't always better. After building both approaches at derez.ai, here's why we believe direct Odoo API access via a dedicated agent user is the superior choice — especially for startups running Odoo Community Edition.
An Odoo MCP server (like tuanle96/mcp-odoo, ivnvxd/mcp-server-odoo, or
hachecito/odoo-mcp-improved) sits between your AI agent and Odoo. The agent talks to the MCP server
via the MCP protocol, and the MCP server translates those requests into Odoo XML-RPC calls.
Agent → MCP Server → Odoo API
The MCP server exposes a fixed set of "tools" — predefined operations like
search_records, create_record, read_record, etc. The agent can only
do what these tools allow.
With the derez.ai approach, your agent authenticates directly against Odoo's XML-RPC API using its own dedicated Odoo user account. There's no middle layer — the agent reads, writes, and queries Odoo models directly, subject only to the user's Odoo access rights.
Agent → Odoo API (as "Agent User")Pro Tip: A dedicated agent user in Odoo Community Edition costs $0. No per-user license fee. Create one with exactly the module rights your agent needs — CRM, Sales, Contacts — and lock everything else. Your agent operates within that permission boundary, just like any human employee.
This is the single most important difference.
With an MCP server, security depends on how well the MCP server itself handles permissions. The MCP server typically authenticates against Odoo with a single set of credentials — often a broad API key — and then decides which "tools" to expose. If the MCP server has a bug, your agent gains unrestricted access to everything the server's credentials allow.
With direct API access, your agent authenticates as a real Odoo user. That user has Odoo-native access rights — the same granular system you already use for your employees. The agent can only see and do what that specific user is allowed to. There is no extra layer to compromise.
Pro Tip: In Odoo Community Edition, create a user called "Hermes Agent" and enable only the modules it needs — CRM read, Contacts read/write, Sales read. Everything else (Accounting, Inventory, HR) stays locked. Your agent cannot access data you didn't explicitly grant.
Every MCP call adds a round-trip: Agent → MCP Server → Odoo API → MCP Server → Agent. That's two network hops instead of one. For a single query this is negligible. For an agent making 20-50 API calls during a complex workflow (research a lead, update the CRM, check inventory, create a quote, send an email), the latency compounds quickly.
Direct access eliminates the middle hop entirely. Your agent reads from and writes to Odoo as fast as any native Odoo client.
An MCP server exposes a curated set of tools. If your agent needs to do something the MCP server author didn't anticipate — query a custom module, call a specific workflow method, search across models — you're blocked until the MCP server adds that tool, or you fork the repo and build it yourself.
With direct API access, your agent can call any Odoo model method its user has rights to.
Custom modules, third-party apps, Odoo's own search_read, create, write,
unlink — everything is available. The only boundary is the user's Odoo permission settings,
not the imagination of an MCP server developer.
An MCP server is a running service. It needs a process manager, logging, monitoring, updates, and occasional debugging when something breaks. Every version of Odoo may require MCP server updates to handle API changes or new modules.
Direct API access requires nothing except the Odoo instance itself — which you're already running. No Docker containers, no environment variables for the MCP server, no "why is the MCP server returning 500" debugging sessions at 2 AM.
When your agent acts through an MCP server, Odoo sees the MCP server's API credentials — not the agent itself. All actions appear under a single service account. You lose the ability to audit "what did the agent do vs. what did a human do."
With direct access via a dedicated user, every action your agent takes is logged in Odoo under the agent user's name. You can run standard Odoo audit reports, check the user's history, and see exactly which records were read, created, or modified — all without any special monitoring setup.
To be fair, MCP isn't all downsides. It makes sense in specific scenarios:
For the combination of Odoo Community Edition + a dedicated Hermes Agent, direct API access is the clear winner. Here's the core insight:
Odoo Community Edition already has a permission system that's mature, granular, and free. Adding an MCP server on top doesn't enhance security — it replaces Odoo's native ACL with a second, independently-maintained permission layer that has to be kept in sync. That's not defense-in-depth; that's an extra attack surface.
A dedicated Odoo user with precise module-level rights, authenticating directly via XML-RPC, gives your agent everything it needs and nothing it doesn't — using the same security model you already trust for your human employees.
Pro Tip: The agent user approach also means you can revoke or modify the agent's access at any time from Odoo's standard Users menu — no need to reconfigure an MCP server, restart a Docker container, or update environment variables. Just uncheck a permission box and the change is immediate.
Deploy an Odoo-connected Hermes Agent in 10 Minutes. Direct XML-RPC access, dedicated agent user, full granular permissions. Use coupon code BLOG950 for $9.50 off your first month.
Buy Agent →derez.ai — Deploy your AI agent in 10 Minutes. · Odoo Integration Guide · Odoo + Hermes for Startups