Teams that run Odoo already hold the answer to almost every operational question inside the database — but getting it out means knowing which model to filter, which report to run, or which developer to interrupt. AI assistants are excellent at reasoning over data they can reach and useless on data they cannot. Odoo's native XML-RPC and JSON-RPC endpoints can technically be called by an external tool, but they expose the raw ORM with no notion of what an assistant should be allowed to see, no structured tool catalog, no per-record scoping, and no audit trail of what the AI actually touched. Bolting an assistant onto those raw endpoints is where the native road ends: you either over-expose the whole database or hand-code brittle glue for every question you want to ask.

is the connector we build to close that gap. It implements a Model Context Protocol server inside a proper Odoo module — its own __manifest__.py, a set of models.Model classes for configuration, tool registration, and request logging, and a transport layer that speaks MCP to the assistant while translating each request into a governed ORM call. Instead of exposing raw search_read across every model, we define a curated catalog of MCP tools (for example: look up a customer, summarize open sales orders, report a stock level, draft an internal note on a project task) that map to explicit, reviewed Odoo operations. Each tool declares its own input schema, resolves the request through the ORM as a dedicated integration user, and returns a compact, structured result the assistant can reason over.

Every call is bounded by Odoo's own permission model rather than a bypass of it. The integration user is constrained by ir.model.access.csv and by record rules you approve, so a tool can only reach the models and rows that user is entitled to — multi-company boundaries, portal-vs-internal visibility, and your existing groups all still apply. Write-capable tools (creating a lead, posting a message, logging an activity) are opt-in per deployment and can be gated behind confirmation, dry-run previews, or an approval step, and every invocation is written to a log model with the tool name, arguments, resolved user, and timestamp so you have a complete audit trail. Where it helps, we add compute fields with @api.depends, QWeb-rendered summaries, or automated actions so the assistant receives clean, purpose-built payloads instead of dumping raw records.

Because this is build-to-order, we start from your data model and your intended assistant use cases, not from a fixed feature list. In a short scoping call we agree which Odoo models and operations to expose, which are read-only versus write-capable, how record rules and companies should constrain access, and which Odoo version (17.0, 18.0, or 19.0, Community or Enterprise) you run. We then build your version of the module, validate it on a staging database, walk your team through it, and hand over the source and git repository. Typical delivery is 2–4 weeks from confirmed scope. Pricing starts from $249 (indicative, single-company base scope); the number of exposed models and custom tools, write/approval workflows, multi-company scoping depth, and any additional integrations increase the quoted scope.