# Local process, native addon, or remote Odoo MCP gateway?

Published: 2026-08-27
Last updated: 2026-08-27
Canonical: https://erpipe.com/guides/odoo-mcp-server-architecture

## Answer first

Use a local MCP process for one operator in one controlled environment. Use an Odoo addon when the capability must live with the Odoo deployment and its module lifecycle. Use a remote gateway when several external clients or Odoo instances need one stable, revocable boundary. In every case, the connected Odoo user's permissions remain authoritative.

The architecture diagram is the easy part. The useful comparison is who owns client authorization, credential storage, upgrades, instance routing, write policy, audit, and uptime after the first successful call.

## Environment

This architecture analysis comes from maintaining the open-source `odoo-mcp` lineage, building ERPipe's hosted path around Odoo 16–19 compatibility, and reviewing Odoo and MCP platform boundaries. The clients in scope are MCP-capable desktop or hosted agents. The Odoo side is a customer-controlled Community, Enterprise, or Odoo.sh instance reached through its supported remote API path.

It does not compare response-time benchmarks, does not claim every third-party addon behaves the same way, and does not turn a public HTTPS gateway into the right answer for private-only Odoo networks.

## Method

We compared the three placements against the responsibilities that remained after tools could list and read a record:

- How an external client authenticates and how access is revoked.
- Where the Odoo credential lives.
- Whether several clients and databases share one explicit routing model.
- Which team owns upgrades and availability.
- How writes are narrowed before Odoo applies ACLs and record rules.
- What evidence exists after a failed or ambiguous tool call.

## Result

| Placement | Best fit | Responsibility you keep |
| --- | --- | --- |
| Local MCP process | One operator, one machine, controlled development or analysis | Process lifecycle, local secrets, client configuration, and every upgrade |
| Native Odoo addon | Capability belongs inside the Odoo module and deployment lifecycle | Module review, Odoo upgrades, exposure/auth for outside clients, and server load |
| Remote MCP gateway | Several clients or databases need one endpoint, policy, revoke story, and audit | Gateway security, tenancy, credential encryption, availability, and network boundary |

The remote gateway did not remove Odoo security. It added a second control plane in front of it. That distinction matters: Odoo decides whether the connected user can read or write a record; the gateway can decide whether this client, tool, field, or proposed mutation should reach Odoo at all.

## Failure modes we kept finding

- **The local process becomes shared infrastructure by accident.** A laptop configuration starts serving several people, but nobody owns its uptime, token rotation, or upgrade path.
- **The addon is treated as external-client authorization.** Running code inside Odoo does not automatically provide a safe OAuth and revocation model for every outside AI client.
- **The gateway hides the selected database.** Multi-instance access without an explicit instance key makes a plausible agent call land in the wrong environment.
- **A write timeout becomes a retry.** The caller cannot know whether Odoo committed, so an automatic replay can duplicate a business action.
- **ACL success is mistaken for business intent.** A service user may be allowed to update a partner, but that does not prove an agent should perform this particular change now.

## Practical default

Start locally while learning the tool contract. Move capability into an addon only when it genuinely belongs to the Odoo deployment. Add a remote gateway when multiple clients, multiple instances, or centralized revocation make the extra service worth operating.

For a production path, use a dedicated least-privilege Odoo user, start read-only, make the instance explicit, and prove how to pause or revoke access. If writes are enabled, preview the exact target and payload and define what happens when the result is unknown.

## Limits

This is an implementation field note, not an independent performance or security certification. Network topology, data-residency requirements, Odoo customization, client support, and team operating capacity can reverse the recommendation. A remote gateway requires public reachability in ERPipe's current hosted beta; private-only instances need a different deployment decision.

## Sources and inspectable evidence

- MCP architecture and local/remote transport model: https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture
- MCP authorization boundary: https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization
- Odoo access rights, record rules, and security pitfalls: https://www.odoo.com/documentation/19.0/developer/reference/backend/security.html
- ERPipe open-source lineage: https://github.com/erpipe-org/mcp-odoo and https://github.com/erpipe-org/erpipe
- [Dated hosted tool catalog](/tools) and [compatibility matrix](/compatibility)

## Related

- [What is an Odoo MCP server?](/guides/what-is-odoo-mcp)
- [Odoo 19 AI Agents vs an external gateway](/guides/odoo-ai-agents-vs-mcp-gateway)
- [Build vs buy an Odoo MCP gateway](/compare/build-vs-buy-odoo-mcp)
- [Security boundary](/security)