Saw Rutger's thread on Odoo+MCP and wanted to share a different angle from the multi-tenant side.

We didn't start with "let's plug Claude into Odoo." We started with "let's build a real Claude connector with its own life" and then added Odoo as one of many possible client surfaces. April 2026 project — fresh, but the standalone-first decision has already proven its weight in production at BL Consulting.

Native Odoo AI app and this connector solve different problems — the native AI is in-DB RAG over your records (great for end-user "ask the data" workflows). This connector is an external Claude tool surface (filesystem, GitHub, OCA repo ops, Portainer, monitoring) for developers and integrators. Complement, not competitor.

What the standalone product looks like:

• MCP server — 188 tools (83 native + 105 proxied), 8 federated sub-servers (Odoo RPC, OCA, EE compatibility check (read-only), GitHub, Portainer, filesystem, Cloudflare, monitoring). Multi-tenant by design.
• Admin panel — backup management for the self-hosted MCP server (per-tenant isolated S3 buckets), filestore browser, user/key administration, Prometheus metrics, semver-pinned plugin lifecycle. Does not replace Odoo admin.
• Native GUIs — desktop connection manager (GTK4 on Linux, Qt6/PySide6 on Win/Mac) for managing Odoo connections, API keys, MCP profiles. Local fingerprint matches your residential IP, so consultant workflows work cleanly.
• Setup wizard — encrypted-ZIP onboarding (AES-256 + one-time password), 5 steps from "I have nothing" to "live tenant with green Anthropic / Qdrant / MCP test."
• Memory layer — Qdrant + Ollama for semantic search across composite-tokenized records. "Find the partner I spoke to last week about X" works.

That's the standalone surface. Runs in Docker, talks MCP to any Claude.ai connector, no Odoo required.

Then — Odoo as one client surface (optional):

Two AGPL Odoo addons embed the connector directly into the Odoo UI (terminal in chatter + list view + settings):

• l10n_bg_claude_terminal — Bulgarian localization version (l10n_bg_* aware: tax / customs / HR). Wizard already in v18 + v19. github.com/rosenvladimirov/l10n-bulgaria
• mcp_terminal — international generic version, no l10n dependency. github.com/rosenvladimirov/odoo-mcp-terminal

Both are AGPL-3 and mutually exclusive (excludes in manifest) — pick whichever fits your fiscal profile.

The AI layer — skills run the stack:

This is where most of the engineering effort went. Calling search_read from Claude is trivial; making the answers useful and consistent across tenants is not. Skills are the orchestration layer — Claude doesn't improvise business logic, it dispatches to a validated skill which runs the actual workflow against memory + tokenized context + posting engines.

• Skills — Anthropic-style skill manifests + injection engine (l10n_bg_ai_pipeline). Curated, validated workflows per-tenant: VAT close, customs declaration generation, payroll lock, opening journal, stock-initial import. Skills decide what tools to call, in what order, with what guardrails.
• Memory packs — versioned, swappable knowledge bundles (one Qdrant collection per pack per tenant). Install / upgrade like Odoo modules. Per-customer isolation by design — pack for tenant A never leaks to tenant B. Skills query packs, packs feed skills.
• Tokenization — composite document tokenizer that builds an AI-readable JSON over multi-model views (e.g. sale.order + lines + partner + invoice + delivery + payment as one unit). Cuts context size 5-10× vs. raw model dumps and gives Claude a coherent business object instead of fragmented records. Skills consume tokenized objects, not raw RPC dumps.
• Posting / accounting workflows — pre-built account.move generators wrapped as skills (Art. 117 reverse-charge protocols, customs DN+MRN matching, salary opening journal, stock-initial opening journal). Validated entries, not AI-improvised ones.

These sit on top of the actual l10n_bg fiscal stack — payroll (DOO / ZO / UPF / MOD), assets, MT940 banking, customs rates, Intrastat, NRA reports — ~30 modules giving Claude the BG-shaped data structures to reason over. Same principle applies if you build comparable l10n_xx depth for other jurisdictions.

l10n_bg ecosystem repos (data layer):

• EE-tier modules: github.com/rosenvladimirov/l10n-bulgaria-ee
• Expert modules (VAT protocols, customs DN+MRN, AI billing, AI pipeline): github.com/rosenvladimirov/l10n-bulgaria-expert

Why a decoupled connector: the engine runs as its own service, so you can drive it from a terminal, a CI pipeline, or another app. The Odoo addons are UI wrappers over the same engine — useful, but not the only entry point.

Source:

• MCP server: https://github.com/rosenvladimirov/odoo-claude-mcp
• Odoo BG modules (AGPL): github.com/rosenvladimirov/l10n-bulgaria
• Odoo international module (AGPL): github.com/rosenvladimirov/odoo-mcp-terminal
• Hosted endpoint + AGPL self-host comparison: www.mcpworks.net

Question for Odoo R&D / Apps Store team: with native AI shipping in 19.0 and multiple integrators (Pantalytics, OCA contributors, ourselves) starting to package skill libraries and memory bundles for it, would there be interest in a dedicated Apps Store category for AI Skills and Memory packs? The current Productivity → AI bucket already mixes three quite different things — AI-enabled end-user apps, skill libraries (logic), and memory packs (knowledge). A clearer taxonomy would help customers find what they need, and would let skill / memory authors version and distribute their work the way modules are versioned today. Happy to contribute a starter taxonomy proposal if there's appetite — and curious if other integrators see the same need.

— Rosen Vladimirov · OCA l10n-bulgaria maintainer · partner at BL Consulting (Odoo Silver Partner)