Letting an AI agent work inside your ERP, without handing over the keys.
AI agents earn their keep when they can do real work in your systems: create tasks, update records, pull a report. But the moment an agent can act inside your ERP, you have a control problem. Handing it a raw API key and hoping for the best is the wrong answer. The right one is a gatekeeper in front of the system that tells the agent exactly what it can and cannot do.
That gatekeeper is a Model Context Protocol (MCP) server, an open standard that connects an AI agent to a system through a defined set of tools. The agent talks to the server, and the server decides what is allowed. The Rubi Odoo MCP is exactly that: a governed, conversational interface to Odoo for AI clients like Claude.
Before the how, here is a short walkthrough: deploying the connector, then loading a spreadsheet of tasks and having Claude create all of them, end to end.
Deploying an org-wide connector tied to single sign-on, registering a personal Odoo API key through a browser-only step, then toggling which operations are allowed per model. From there, uploading a spreadsheet of 25 tasks and having Claude create them in a batch, then mark them complete. Finally, model-level gatekeeping in action: the agent can clean up contact tags but is blocked from deleting projects or tasks.
Why a raw API key is the wrong tool for an agent.
Odoo's programmatic access uses XML-RPC API keys. Each key is bound to one user and inherits all of that user's permissions. If the user can delete a customer or edit an invoice, any agent holding that key can too. There is no way to say "read and update, but never delete." The key is all or nothing.
For a human clicking through a UI, that is fine. For an autonomous agent working at machine speed, it is a liability. Think of an AI agent as a toddler with superpowers: astonishingly capable, fast, and tireless, but with no instinct for which doors should stay shut. You do not hand a toddler the keys to the whole house. You childproof the room first, then let it loose to do real work safely.
An AI agent is a toddler with superpowers. You don't hand it the keys to everything and hope. You childproof the room first.
A Rubi MCP server is that childproofing. It changes the shape of the problem.
The gatekeeper pattern.
The agent never holds the credential and never talks to Odoo directly. The MCP server sits in between as a broker: it authenticates the user, fetches that user's secret from the vault, enforces what is allowed, and only then makes the call.
What the Odoo MCP can do.
The toolset covers the full lifecycle of working with records: discovery tools such as list_models and get_model_fields, reading tools such as find and search_records, and writing tools such as create_records (batch up to 100 in one call) and update_record, plus more for calling custom methods and filing a Helpdesk ticket straight from the conversation.
Two layers of control.
The security comes in two layers, and both matter.
Layer one is per-user identity. Every request is authenticated with the user's own Microsoft Entra ID single sign-on. Each user registers their personal Odoo API key through a browser-only step that stores it in Azure Key Vault. The key is never pasted into the chat, and the AI never sees it. The agent acts as you, not as a shared admin.
Layer two is model-level gatekeeping. On top of normal Odoo permissions, the MCP can allow or deny read, create, update, and delete per model. So even if a user could delete a project in the Odoo UI, the agent can be blocked from deleting it through the MCP, while still being free to create and update tasks.
Answers built for agents, not data dumps.
Responses are shaped for agents, not raw inspection. The server uses friendly model aliases, so you say "contacts" instead of res.partner or "tasks" instead of project.task. Every record comes back with a clickable URL, HTML is stripped, and related fields are flattened to readable names. You get a usable answer, not a data dump.
Three servers, one pattern.
The Odoo MCP is one of a family. We run the same gatekeeper pattern for Microsoft 365 and for Loom, and the approach works for any system with an API. A Q360 MCP and an AlayaCare MCP are in development, and command-line versions of every connector are on the way so the same governed access works in automation, not just in chat.
Frequently asked questions.
Only the specific results the agent asks for pass through, and the MCP server brokers every call. Your credentials never do. The Odoo API key lives in Azure Key Vault, and the AI never sees it.
Every request is scoped to your own Entra identity and your own vaulted key, so revoking your sign-in or removing your key cuts off the agent's access immediately. There is no shared admin key left behind to clean up.
Yes, precisely. Model-level gatekeeping lets you allow or deny read, create, update, and delete per model, on top of normal user permissions. You can let an agent read and update tasks while blocking deletes entirely, even on records the user could delete by hand.