MCP Server for Odoo

Introduction#

Teams want Claude, Cursor, Gemini, or Copilot Studio to answer questions about stock, partners, and orders — and sometimes to confirm or cancel documents. The hard part is not the LLM; it is doing that without handing the model admin rights.

This article explains what MCP is in an Odoo context, how a native endpoint should enforce security, and when you still want classical JSON-RPC or an external Python service instead.

What MCP is (in Odoo terms)#

MCP (Model Context Protocol) lets AI clients discover tools and call them over a documented transport. For Odoo, the practical surface is Streamable HTTP: the client POSTs to an endpoint such as /mcp with a Bearer token (or OAuth), and the server returns tool results.

From Odoo’s perspective those tools map to ORM operations and carefully listed workflow methods — search_read, create, write, unlink, and action methods you explicitly allow. The assistant never gets a raw Python shell.

Why native-in-Odoo matters#

A sidecar that logs in as admin and proxies every model is easy to demo and hard to defend. A native module runs each call as the API-key user, so ir.model.access and record rules apply the same way they do in the UI.

Company fences, excluded fields, and per-operation caps further shrink blast radius. Audit logs and sessions give administrators a trail of what an assistant did — similar expectations to an integration user, with an AI-client UX.

Policy model: opt-in, not open by default#

A production-minded MCP app keeps a master switch off after install. Administrators enable models one by one and tick read / create / update / delete separately. Sensitive fields can be excluded; workflow methods (confirm, cancel) require an explicit list.

Optional record fences (for example only partners belonging to the key’s user) and rate or size caps reduce runaway writes. Connection wizards mint keys and paste-ready client snippets so operators do not invent insecure configs.

When MCP helps vs custom RPC or middleware#

Choose MCP when humans (or agent loops) need conversational or IDE-driven access to live ERP data under the same security story as a logged-in user — demos, ops Q&A, assisted data entry with confirmation.

Prefer JSON-RPC / XML-RPC or custom HTTP controllers when you need deterministic bulk sync, webhooks with HMAC, or high-volume upserts. Prefer external Python middleware when rate limits, retries, and multi-system orchestration dominate — those patterns are covered in REST APIs and External Integrations.

MCP and classical integrations are complementary: MCP for interactive assistants; middleware for channel sync and batch jobs.

Operational checklist before go-live#

Use a dedicated Odoo user for each assistant identity — least privilege groups, correct companies. Never mint keys for admin “because it is easier.”

Enable only the models and operations the use case needs. Test with a read-only connection check first. Turn the master switch on only after that passes.

Review audit logs after a pilot week. Rotate keys when people leave or clients are retired. Keep the Apps Store module updated across Odoo major versions you support.

Practical recommendations#

• ✓Keep the master switch off until models, operations, and a dedicated least-privilege user are configured.
• ✓Mint one API key per assistant identity; rotate keys when people leave or clients are retired.
• ✓Exclude sensitive fields (passwords, payment tokens, salary) even when the model is enabled for read.
• ✓Pilot with read-only Test MCP Connection before allowing create/update/delete.
• ✓Review audit logs after the first week of use and tighten record fences if needed.
• ✓Use MCP for interactive assistants; keep bulk channel sync on RPC or middleware.

Common mistakes#

• !Minting MCP keys for the admin user “just for demos” and leaving them in production.
• !Enabling a model with all CRUD operations when the use case only needs search_read.
• !Treating MCP as a replacement for high-volume Shopify or WMS sync jobs.
• !Turning the master switch on before a read-only connection test passes.
• !Assuming policy can grant access the Odoo user does not already have via ACLs.
• !Skipping field excludes on partner, employee, or payment-related models.

Conclusion#

MCP gives AI clients a standard door into Odoo; native enforcement under ACLs and record rules is what makes that door safe enough for production.

Start with opt-in models, least-privilege keys, and read-only tests. Keep classical RPC and middleware for bulk and multi-system sync — use MCP where interactive assistants add leverage.