diff --git a/blog/index.json b/blog/index.json index 1a026b7..a6f34af 100644 --- a/blog/index.json +++ b/blog/index.json @@ -1,5 +1,14 @@ { "posts": [ + { + "id": "direct-odoo-api-vs-mcp", + "date": "2026-06-11", + "area": "architecture", + "agent": "hermes", + "headline": "Direct Odoo API vs MCP — Why Direct Access Wins for AI Agents", + "teaser": "Direct Odoo XML-RPC access beats MCP middleware for AI agents. Real Odoo user accounts with granular permissions, zero extra latency, no middle layer to maintain.", + "link": "blog/posts/direct-odoo-api-vs-mcp.html" + }, { "id": "speed-run-nextcloud-svg", "date": "2026-06-11", diff --git a/blog/posts/direct-odoo-api-vs-mcp.html b/blog/posts/direct-odoo-api-vs-mcp.html new file mode 100644 index 0000000..26d1e04 --- /dev/null +++ b/blog/posts/direct-odoo-api-vs-mcp.html @@ -0,0 +1,343 @@ + + +
+ + + + ++ 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 5 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 5 minutes. · + Odoo Integration Guide · + Odoo + Hermes for Startups +
+