Skip to content

Connection and discovery

Before operating against a new instance, identify its version, edition and deployment. The compatibility layer uses these details to resolve model and field names, so you almost never need to branch your queries by version.

1. Identify the environment

Call odoo_version. It returns:

  • version — major integer (10–19)
  • raw_version — the full version string reported by Odoo
  • edition — community | enterprise | unknown
  • deployment — onprem | saas
  • transport — the active transport (jsonrpc in auto, or xmlrpc after a fallback)

2. Health check with /odoo-doctor

The /odoo-doctor command runs a full diagnostic, writing nothing:

  1. Calls odoo_version and reports version / edition / deployment / transport.
  2. Calls odoo_connections and lists the active sessions.
  3. Does a scoped test read: odoo_search_read { "model": "res.partner", "fields": ["name"], "limit": 1 }.
  4. If any step fails, it shows the exact error and points you to /odoo-tools:odoo-setup-mcp (or odoo-setup-cli).

3. Explore the schema

Every instance differs. Before querying fields you do not know:

  • odoo_list_models — lists the installed models, optionally filtering by a name fragment (like).
  • odoo_fields_get — returns the field definitions of a model (cached). It accepts historical or modern names; the compatibility layer resolves to the correct one.
  • odoo_module_info — installation status and metadata of a module by its technical name (useful to know whether an Enterprise module is present).

Example: discover the contact fields

odoo_fields_get {
  "model": "res.partner",
  "attributes": ["string", "type", "required"]
}

4. Choose the right surface

  • If uvx or Python 3.11+ are available → MCP server (all the tools + compatibility).
  • If you only have Node → fallback CLI (see Fallback CLI).

Continue with the Tools reference.