The Odoo app gives read-only access to an Odoo instance (Odoo 18) through its external API, with the API key of a dedicated service account. It is generic: it reads any standard or custom model you allow, from contacts and products to sales orders, stock lots or x_ models. It can be consumed two ways: as a remote MCP server that Agent Creator agents call through six read tools (discover models, describe fields, resolve a name, read records, aggregate, count), or as a Builder app whose instructions you call directly from DSUL. It runs in the tenant app-instance context: each workspace enters its own Odoo URL, database, login and API key in the connector’s configuration app, resolved server-side and never exposed to the agent. Agents are identified by the capability Scope context_id,agent_id,user_id and gated by a per-workspace authorized-agents allowlist.
Any Odoo model
Discover the readable models, list their fields, then read records with an Odoo domain: standard and custom models alike.
Server-side aggregates
Totals, averages and counts grouped by field or period are computed by Odoo (
read_group), so the agent never sums thousands of rows itself.Read-only by design
Only read methods are allowed, in code. A model allowlist and the Odoo rights of the service account apply on top.
Video tutorial
This two-minute tutorial shows the connector end to end: connecting the Odoo instance and choosing the readable models in the configuration app, authorizing agents, then asking an agent to count records, explore a model, compute a yearly revenue indicator, and refuse a deletion because the connector is read-only. Use the buttons in the top-right corner of the player to switch the narration language and the subtitles. The sections on the left are clickable. Screens show the English interface; narration and subtitles are available in English and French.Who is this for?
This connector is used by three different roles. Jump to the section that matches yours; each one is self-contained.Agent builder
You build agents in Agent Creator and want them to answer questions from Odoo data. → Agent builder tab.
Platform admin
You run the platform and want to know what to set up once for everyone. → Platform admin setup accordion below.
Workspace builder
You write Builder automations (DSUL) that read Odoo directly. → Workspace builder tab.
Prerequisites
- An Odoo 18 instance (Odoo Online, Odoo.sh or on-premise) whose plan gives access to the external API. On Odoo Online, the external API requires the Custom pricing plan.
- A dedicated service account in Odoo (an internal user), with read rights only on the data agents may use. The connector applies the Odoo rights of this account as-is.
- An API key for that account: log in as the service account, open Preferences → Account Security → New API Key, choose a duration and copy the key (Odoo shows it once). Note its expiry date: the configuration app warns 30 days before it.
- The database name. On Odoo.sh it differs from the sub-domain and is shown on the branch page; on-premise, it is the database selected at login.
The connector never writes, even if the service account has write rights. A read-only account is still the recommended setup: it keeps the guarantee on the Odoo side too.
Platform admin (Governance): one-time platform setup
Platform admin (Governance): one-time platform setup
Goal: Odoo is a per-workspace connector: each workspace enters its own Odoo connection in the connector’s configuration app (see the Workspace builder tab), so there is no platform-wide credential to provision and no central OAuth client.
There is no shared Odoo credential for this connector. The URL, database, login, API key and readable models always live in the consuming workspace’s secrets, written by the connector’s configuration app. The platform operator has nothing to register centrally.
Declare the capability in AI Governance (optional)
If you want agent builders to pick Odoo from the capability catalog instead of pasting an MCP endpoint URL by hand, expose it as a reusable capability in AI Governance, pointing at the MCP endpoint of the workspace that runs the connector.1
Open AI Governance > Capabilities
Create (or edit) the Odoo capability.
2
Point it at the MCP endpoint
Set the capability’s MCP server URL to the MCP endpoint of the workspace running the connector (shown in the configuration app, Agents tab), and set its Scope to:The
agent_id in the scope is what lets the connector identify and authorize the calling agent.3
Make it available to agent builders
Once created, the capability appears in the capability picker for agent builders in your organization. Access to the catalog follows your organization’s existing roles; there is no per-capability role grant for this tenant-context connector.
The connector’s configuration app also offers a one-click Add to catalog button (Agents tab) that publishes the capability to the organization-wide Capabilities catalog for you. It requires catalog write rights in your organization.
- Agent builder (Agent Creator)
- Workspace builder (DSUL)
Agent builder
Goal: let an agent you build in Agent Creator answer questions from Odoo data through the six read-only MCP tools.Before an agent can call the connector, a Workspace builder must have installed and configured the Odoo app in a workspace (see the Workspace builder tab), or a Platform admin must have published an Odoo capability in AI Governance (see the Platform admin setup accordion above).
agent_id that Agent Creator injects through the capability Scope, and that agent must appear in the connector’s authorized-agents allowlist (managed in the configuration app). The Odoo credentials themselves are resolved server-side and never exposed to the agent.1
Install and configure the connector in your workspace
Follow the Workspace builder tab: install Odoo in your workspace, open its Configuration app, fill the Odoo connection and the readable models in the Authentication tab, then click Test connection.
2
Allowlist your agent
In the configuration app, open the Agents tab and tick your agent under Authorized agents, or enable Allow all agents.
3
Add the MCP capability to your agent
Next to the ticked agent, click Install capability: it adds the Odoo capability to the agent with the right endpoint and Scope. To wire it by hand instead, add a capability pointing at the MCP endpoint shown in the same tab, and set its Scope to:The
agent_id is what lets the connector identify and authorize your agent; without it, every call is rejected with an explicit “agent could not be identified” message.4
Brief the agent
Tell the agent the tools exist and in which order to use them (see Brief the agent in its system prompt below).
Org-wide alternative: Add to catalog. Instead of installing the capability agent by agent, click Add to catalog in the Agents tab to publish Odoo to the organization-wide Capabilities catalog (see the Platform admin setup accordion). Agent builders then enable it from the catalog with the endpoint and Scope already wired; each agent must still be allowlisted.
Brief the agent in its system prompt
Odoo model and field names are technical (sale.order, partner_id, amount_untaxed). A short brief avoids the agent guessing them:Read-only by design. The connector only calls Odoo read methods (
search_read, read, read_group, search_count, fields_get, name_search). This list is in the code, not in the configuration: no setting can open a write, whatever the rights of the service account. Least privilege comes from two further layers you control: the readable models allowlist in the configuration app, and the Odoo access rights of the service account. Keep both as narrow as the use case allows.Legacy AI Knowledge agents (no native MCP picker): add the connector under Advanced > Tools > MCP and paste the MCP endpoint URL. The agent still has to be allowlisted in the configuration app and its identity propagated so the connector can read its
agent_id.Available Tools
Discovery
Reading
Output Formats
Every tool returns its result as JSON text in a standard MCP tool result. On failure, the result is flaggedisError and its text explains what to fix (see Error Handling).odoo_list_models:{ models: [{ model, name }], total, truncated }.odoo_describe_model:{ fields: [{ name, type, label, relation?, required?, stored? }], total, truncated }, sorted by name, 400 fields at most.odoo_resolve:[{ id, name }].odoo_search_read:{ records: [...], count, limit, offset, more }. Relational fields come as[id, display name], as in Odoo.odoo_aggregate:{ groups: [{ <groupby keys>, <measures>, __count }], count }.odoo_count:{ count }.
Tool Details
odoo_search_read
Read records matching an Odoo domain.odoo_aggregate
Let Odoo compute totals, averages and counts, optionally grouped by fields or by date periods (date:day, date:week, date:month, date:quarter, date:year).odoo_resolve
Turn a name typed by the user into record ids, before filtering on them.odoo_describe_model
List the fields of a model so the agent requests existing field names only.Error Handling
The connector does not raise: failures come back as an explicit message, as anisError tool result over MCP or as { error } from a DSUL instruction. Odoo tracebacks are never forwarded.
Common Issues
- “This agent is not authorized to use the Odoo connector”: The calling agent is not in the allowlist. Open the configuration app → Agents → tick this agent under Authorized agents (or enable Allow all agents).
- “The calling agent could not be identified”: The MCP capability Scope does not declare
agent_id, so Agent Creator never injects the agent identity. Set the Scope tocontext_id,agent_id,user_idon the capability (the Install capability button does it), then allow the agent in the configuration app. - “Odoo refused the connection”: Run Test connection in the configuration app. Check the database name first (on Odoo.sh it is not the sub-domain), then the login, then the key. An Odoo API key cannot be read back: if it expired or was lost, generate a new one from the service account’s Preferences → Account Security and paste it.
- “The Odoo service account is not allowed to read this data”: the model is in the allowlist, but Odoo’s own rights refuse it. Grant the service account the matching read access in Odoo (user groups, record rules), or remove the model from Readable models.
odoo_list_modelsreturns allowlist patterns instead of models: Odoo restricts the model registry (ir.model) to administrators, and a read-only service account usually cannot list it. The connector then answers from the allowlist itself, so a pattern such asstock.*appears as is; the agent can still callodoo_describe_modelon a concrete model such asstock.lot.- Service-specific gotcha: relational fields (
partner_id,product_id…) return the display name of the related record even when the related model is not in the allowlist. This is standard Odoo behaviour: the connector never reads the related record itself, but if a display name is sensitive, restrict the field through the service account’s Odoo rights.
External Resources
Odoo External API
Odoo 18 external API reference: authentication, API keys and
execute_kw.Odoo search domains
Syntax of the domains used by every read tool.
Tool Agents
How Agent Creator agents consume MCP tools and capabilities.