Skip to main content
Odoo 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.
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.
Declaring the capability makes the connector available to agent builders; it does not authorize a specific agent and does not provision any Odoo credential. Per-agent gating remains the config-app authorized-agents allowlist, and the Odoo connection still lives in the workspace running the connector. There is no OAuth auth-config JSON to attach here: authentication is a server-side Odoo API key, not a per-user OAuth flow.

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).
This connector runs in the tenant app-instance context: your agent is identified by the 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 flagged isError 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 }.
Answers are capped at about 20,000 characters. A longer answer is cut, with a hint to narrow the query (fewer fields, a stricter domain, a lower limit).

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 an isError 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 to context_id,agent_id,user_id on 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_models returns 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 as stock.* appears as is; the agent can still call odoo_describe_model on a concrete model such as stock.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.