AI Tool - Read

To forbid a field, tick AI Read Forbidden on it. As the administrator, either:

• Go to Settings > Technical > Database Structure > Fields, find the field and tick the flag (the AI Read Forbidden filter and list column help you review what is already flagged), or
• Open the model in Settings > Technical > Database Structure > Models and tick the flag on the line of the field, in the Fields tab.

The flag applies to base fields as well as custom ones, and takes effect immediately. A flag set on a mixin's field, such as email_normalized on mail.thread.blacklist, applies to every model inheriting it.

A forbidden field takes along the fields that expose its value through their definition, on any model: related fields, the fields a model delegates through _inherits, and computed fields that depend on it. The hidden list returned by the get_fields tool shows the result on a model. A value copied into another record when that record is written is not followed (see Known issues): flag such fields as well.

This errs on the safe side: a computed field is hidden as soon as it depends on a forbidden field, even when its value does not contain it. Forbidding res.partner.email also hides is_blacklisted, a yes/no computed from the address, and hr.employee.mobile_phone, computed by the same method as the work email. For the same reason, flag the fields that hold the sensitive values themselves (email, phone, address), not fields that many others are computed from, such as parent_id or company_id: those would hide far more than intended.

Fields restricted to a user group (groups= in their definition) are already left out of the results for a user outside that group, without any flag, and are not reported in the hidden list either. AI Read Forbidden is only needed for fields that the user is otherwise allowed to read.

The tools are registered as ai.tool records and are callable through any ai_tool integration: ai_oca_mcp, for instance, exposes them to MCP clients such as Claude Desktop. This module provides the tools themselves; how they are reached depends on the transport module installed.

A typical agent workflow:

• Call list_models to discover the models the bound user may read. Each entry gives the technical model name (e.g. res.partner) to pass to the other tools.
• Call get_fields with model to learn what each readable field means (label, type, help, selection options, relation target), and which fields are listed under hidden.
• Call search_read to fetch records:
• model (required): the technical model name.
• domain (optional): an Odoo domain as a list, e.g. [["is_company", "=", true]].
• fields (optional): an explicit field list; the stored readable fields are returned otherwise. An empty list returns ids only.
• limit (optional): page size, 200 by default and at most; a value of 0 or less, or past the cap, is treated as the maximum.
• offset (optional): skip that many matching records.
• order (optional): e.g. "name asc". Relational fields come back as record ids, dates and datetimes as ISO-8601 strings in UTC. has_more tells whether another page exists under the same domain and order; fields the call could not read are listed in inaccessible_fields, while forbidden or restricted fields are simply absent from the records.

Example search_read arguments:

{
  "model": "res.partner",
  "domain": [["is_company", "=", true]],
  "fields": ["name", "email", "country_id"],
  "limit": 20,
  "order": "name asc"
}

Every call executes with the access rights of the calling user — the API-key owner when reached through ai_oca_mcp — so Odoo ACLs, record rules and field groups apply as usual. Connect the agent as a dedicated user holding only the rights it needs.