Hand an agent a raw Odoo API key and it can do anything that user can do, including delete records. Rubi Odoo MCP puts a governed gatekeeper in front of Odoo instead, so AI clients like Claude talk to your ERP through one Model Context Protocol server that controls exactly what they can and cannot do.
Two layers sit between the agent and your data. Every request is scoped to the individual user's identity, and a per-model allow/deny policy decides which operations are even possible. No shared admin key, no raw credentials in the chat, no unbounded delete.
Full CRUD Tool Set
Agents handle everyday ERP work through a complete set of tools. Search with filters, paging, and sort, plus reads, writes, and deletes, with batch creation of up to 100 records in a single call.
Schema & Method Access
Before acting, agents can inspect a model's fields and list the models they are allowed to touch. They can also call custom model methods and file a Helpdesk ticket straight from the conversation.
Per-User Identity Scoping
Every request runs as the real person behind it, authenticated with their own Microsoft Entra ID sign-on. Each user's Odoo API key is registered through a browser-only step and stored in Azure Key Vault, so it is never pasted into the chat and the AI never sees it.
Model-Level Gatekeeping
You decide what agents may do, model by model. On top of normal Odoo permissions, the server can allow or deny read, create, update, and delete per model, so an agent can be blocked from deleting even where the same user could delete in the Odoo UI.
AI-Friendly Responses
Agents get answers they can act on, not raw data dumps. Friendly model aliases let them say "contacts" or "tasks" instead of technical names, and every record returns with a clickable URL, HTML stripped, and relations flattened to readable names.
Cloud Infrastructure
Nothing to run on your own servers. The server is built in Python and hosted on Azure Functions, with secrets in Azure Key Vault and identity through Microsoft Entra ID. An enforcement layer on the Odoo side applies the per-model permissions.
Deploy the MCP server
We stand up the Python server on Azure Functions, connected to your Microsoft Entra ID tenant.
Install the enforcement layer
The Odoo side is set up to enforce the per-model allow/deny permissions.
Define the model policy
We set which models agents may read, create, update, or delete, scoped tighter than the Odoo UI where needed.
Configure aliases & responses
Friendly model aliases and response cleaning are tuned to the models your team works with most.
Users register their key
Each user signs in with Entra ID and registers their personal Odoo API key through the browser-only form. Keys land in Key Vault.
Connect the AI client
Claude, Claude Code, or any MCP client is pointed at the server and validated end to end before live use.
Odoo / Improoved ERP
A reachable instance where the enforcement layer can be installed.
Microsoft Entra ID tenant
For single sign-on and per-user identity scoping.
Azure subscription
To host the Functions app and Key Vault, or we can host within ours.
Per-user Odoo API keys
Each user generates their own key in Odoo under Settings, Users, API Keys.
Model permission policy
Your call on which models and operations agents are allowed to perform.
An MCP client
Claude, Claude Code, or another Model Context Protocol client for your team.
Scope notice: This document describes the functionality included in your package. Anything not listed here, including custom tool development, additional ERP connectors, bespoke response transforms, or integrations with platforms other than Odoo, is outside this engagement and would be scoped and quoted separately.