MCP server

With the MCP server enabled, your Odoo database can be connected to external AI apps that speak the Model Context Protocol, such as Claude, ChatGPT or an AI-enabled code editor. The app can then search and read the data its user can see in Odoo and, with confirmation, propose changes, from inside the app the person already uses.

Note

This is the opposite direction of AI ‣ Configuration ‣ Providers ‣ MCP Servers, where Odoo calls tools of other servers (see Configuration). Here Odoo is the server.

Enable the server

  1. Install the modules AI MCP Gateway (and, for portal users, AI MCP Gateway - Portal).

  2. Open AI ‣ Configuration ‣ Settings, find the block MCP server and turn it on. The setting is off by default.

  3. Copy the address from MCP server URL. It is your Odoo address followed by /mcp, and it is what you paste into the AI app.

Important

AI apps call the server without a login cookie, so Odoo must select this database from the host name alone. If the server serves several databases, set its dbfilter option so that this host name selects only this database (for example ^%d$ with one database per subdomain), or serve a single database. If that is not the case, the settings page shows a warning and the apps get “404 Not Found”.

Connect an AI app

  1. In the AI app, add a custom connector or MCP server and paste the server URL.

  2. The app opens an Odoo sign-in page. Sign in with your own account. Only internal users in the AI: User group can connect, and the group is checked again on every request.

  3. A consent page says which app wants to connect, what it will be able to do (Read only or Read and propose changes) and which tools it can use. Click Allow or Deny. Consent is asked every time an app connects.

Behind the scenes the connection uses OAuth 2.1 with PKCE. Access tokens are short-lived and refresh tokens rotate on every use; only hashes are stored. Scripted clients can alternatively use an Odoo API key as the bearer token, if Accept Odoo API keys is on.

Connected apps and disconnecting

Every user sees their own connections in their preferences, on the tab Connected AI apps, with the date connected and last use. Disconnect takes effect immediately.

Administrators see all connections under AI ‣ Configuration ‣ MCP Server ‣ Connected AI apps (with Revoke) and the registered apps under AI ‣ Configuration ‣ MCP Server ‣ AI Apps. Revoking a refresh token revokes the whole connection.

Which tools are exposed

The server does not hand out everything the assistant can do. It offers an allow-list of tools that are known to respect confirmation, filtered by the user’s own capabilities:

  • Reading and looking up: search, read, group and aggregate records, describe fields, search the documentation of models, read the environment, list allowed actions and skills and use a skill, compute dates, read attachments, list menus, search memory, search and fetch web pages (if the Web access capability is on).

  • Changing (only if the Write, Delete or Business actions capability is on): create, update and delete records, call an allowed business action, fetch a file into a field.

Not exposed, whatever the capabilities: saving or forgetting memories, creating or running automations, changing views, fields or models, generating images and the website builder tools. A token with only read access sees only the read tools. Every tool call runs as the user, through the same access rules, policy checks and audit as the assistant in Odoo.

Changes made by AI apps

By default Always ask for confirmation applies: each connection has its own conversation (“MCP: app name”), and every create, update, delete or action becomes a proposal that you approve in the AI panel (see The AI panel). The alternative Follow the AI write settings uses the global write mode instead. Each tool call is written to the AI log as an MCP call and counts towards the rate limits.

Choose the behaviour in the setting Changes made by AI apps.

Registering apps

There are two ways to let an app in.

  • You register it yourself under AI ‣ Configuration ‣ MCP Server ‣ AI Apps: the App name shown on the consent page and the allowed Redirect URIs. Use Generate secret for a confidential app (the secret is shown only once) or Make public (PKCE only) for apps that cannot keep a secret.

  • Or you turn on Allow dynamic client registration and apps register themselves. This is off by default. Users still sign in and approve every connection, but registration is limited:

    • per network address (Registrations per address and hour, 10 by default). Beyond that the app gets “Too many app registrations from this address”;

    • an app may register at most 10 redirect URIs, each at most 2048 characters long, in a request of at most 16 KB;

    • every redirect URI must match one of the Allowed redirect URI patterns (see below);

    • at most 1000 self-registered apps are accepted (the system parameter ai_mcp_gateway.dcr_max_clients). Apps that never connected and are older than the clean-up time below do not count; and

    • an app that was registered by itself and never connected is deleted by a scheduled job after 72 hours (the system parameter ai_mcp_gateway.dcr_unused_client_hours).

  • An authorization error that is found before the consent page (a missing PKCE challenge, for example) is not sent back to a self-registered app: it is shown to you on an error page, so that an unreviewed app cannot use the server to redirect you somewhere. After the consent page, your own Deny is always sent back to the app, as the protocol expects. Apps that you registered yourself receive their errors as usual.

More settings in the block MCP server: Token lifetimes (access token minutes and refresh token days) and Allowed browser origins for browser-based apps.

Redirect URI rules

Where the AI app may send you back after sign-in is restricted by Allowed redirect URI patterns. Every redirect URI, whether you enter it or an app registers it, must match one of the patterns (separated by spaces or commas). A pattern has the form scheme://host[:port][/path]:

  • the host is a literal name, * for any host, or *.example.com for exactly one more label in front of example.com (a.example.com, not a.b.example.com);

  • the port is a number or * for any port. Without a port, the address may not name one (except the default port of the scheme);

  • the path is empty (any path), a fixed path (exact match) or ends in /* (that path and everything below it);

  • nothing else is a wildcard, and * never stretches over a /.

For example, https://claude.ai/api/* allows only addresses below that path. The default patterns accept any https:// address and the local loopback addresses (127.0.0.1, localhost and [::1]) that desktop tools use.

Independently of the patterns, a redirect URI must be absolute, must not contain a fragment or user information, must not use the javascript, data, file or vbscript schemes, and plain http is allowed for loopback addresses only. URIs with dot segments or spaces never match. When an app asks to be sent back to a URI, it must equal a registered one exactly; only the port of a registered loopback http address may differ.

Portal users

With the portal module and the setting Portal users may connect AI apps (off by default), portal users can connect AI apps too, from the page “My AI apps” of the portal. They get only the search, read and group tools, read-only, and only for models that have an explicit read allow rule in an AI access group they belong to. A shipped, empty group Portal users (MCP) is mapped to all portal users for that purpose. Odoo’s own portal rights still apply underneath.

Limits

  • The server is stateless and answers single requests: no streaming, no server-initiated messages, no resources or prompts.

  • Apps are identified by registration (yours or dynamic), not by a URL-based client identity document.

  • A user who is archived, removed from the AI group or banned loses access on the next request.