Skip to main content
Glama
vincent2021

odoo-mcp-gateway

by vincent2021

odoo_mcp_sso — Team-gateway / Microsoft-SSO add-on for odoo-mcp-guard

This folder is a self-contained, extractable package (odoo_mcp_sso) that adds team-gateway mode (ADR-017) and Microsoft SSO login (ADR-018) on top of the odoo-mcp-guard core. Business users authenticate in their browser with their usual Odoo login through an OAuth 2.1 authorization-code + PKCE flow (the MCP-standard client flow); every tool call then executes against Odoo as that user — Odoo ACLs, record rules, and multi-company all apply per user, the policy file restricts on top, and audit lines are nominative.

Design: it consumes the MIT core, UNMODIFIED

The dependency is strictly one-directional: odoo_mcp_sso imports the core; the core never imports odoo_mcp_sso (enforced by an import-linter contract in the root pyproject.toml: "Core never imports the SSO package"). The core stays gateway-unaware — build_server resolves each request through a RequestContextResolver, and this package supplies a GatewayResolver for gateway mode while the core's default SingleUserResolver is untouched.

What this package consumes from the core (all public, unmodified):

  • odoo_mcp_guard.server.context.RequestContextResolver — the per-request seam. GatewayResolver (in odoo_mcp_sso.users) implements it structurally.

  • odoo_mcp_guard.server.identity — the identity contract (UserIdentity, UserSession, CredentialVault). These live in the core, not here, so the core can speak the contract without importing this package. odoo_mcp_sso re-exports them for its own consumers.

  • odoo_mcp_guard.server.unconnected.UnconnectedClient — the fail-closed base-profile placeholder. Lives in the core (depends only on errors + odoo.api, no gateway logic).

  • odoo_mcp_guard.odoo.session_client.SessionClient — stays in the core by design. It is a generic OdooClient over an Odoo web-session cookie with no gateway import; the core wires it via odoo.detect.make_session_client, and the SSO package consumes it through that core function (Microsoft SSO odoo_session auth method). It is NOT moved into this package.

  • odoo_mcp_guard.config (ProfileConfig, load_profile), odoo_mcp_guard.errors, odoo_mcp_guard.audit, and the odoo client/transport layer.

Related MCP server: MCP Odoo Bridge Server

Package contents

Module

Role

odoo_mcp_sso/auth.py

OAuth 2.1 AS + PKCE, /authorize browser login, /token, RFC 8414/9728 metadata, Microsoft-SSO relay (ADR-018), make_odoo_validator, make_ms_sso, mount_gateway, bearer/vault middleware

odoo_mcp_sso/users.py

UserClientPool (per-user client cache), GatewayResolver (the RequestContextResolver impl), GatewaySessionMissingError

odoo_mcp_sso/vault.py

InMemoryVault (TTL, never persisted — Rule 1 #7)

odoo_mcp_sso/types.py

GatewayConfig (gateway-mode wiring; identity types live in the core)

How it is wired today (in-tree)

This package is a uv workspace member of the core repo ([tool.uv.workspace] members = ["SSO_MICROSOFT"] in the root pyproject.toml). One uv sync --all-packages installs both the core and this add-on editable, so a single uv run python -m pytest from the repo root collects both core and SSO tests (SSO_MICROSOFT/tests is in testpaths).

The gateway is activated entirely from the core's serve.py on the --gateway path via function-local imports of odoo_mcp_sso (the only allowed core→sso edge, whitelisted in the import-linter contract):

# odoo_mcp_guard/server/serve.py (gateway path only)
from odoo_mcp_sso.users import GatewayResolver, UserClientPool
from odoo_mcp_sso.vault import InMemoryVault
from odoo_mcp_sso.auth import GatewayAuthApp, make_ms_sso, make_odoo_validator, mount_gateway
from odoo_mcp_sso.types import GatewayConfig

Extracting this into its own repository later

Because the dependency is one-directional and the core is consumed unmodified, lifting this out is mechanical:

  1. Move the folder out of the core repo into a new repository (SSO_MICROSOFT/ → the new repo root; odoo_mcp_sso/ is the package, tests/ are its tests).

  2. Replace the workspace dependency with a pinned core release. In the new repo's pyproject.toml, drop [tool.uv.sources] odoo-mcp-guard = { workspace = true } and pin a published odoo-mcp-guard version (PyPI release or git tag). Then pip install odoo-mcp-guard (or uv add).

  3. Wire serve in the new repo. The core's serve.py keeps only its two self-host transports (stdio + single-credential bearer HTTP). Move the --gateway flag and the _build_gateway_app / mount_gateway wiring into the new repo's own entrypoint, which calls odoo_mcp_guard.server.app.build_server( runtime, resolver=GatewayResolver(...)).

  4. SessionClient stays in the core — do not copy it. The new repo reaches it through odoo_mcp_guard.odoo.detect.make_session_client, exactly as it does in-tree.

Nothing in the core has to change to support the move: the seam, the identity types, and SessionClient are already in their permanent homes.

A
license - permissive license
-
quality - not tested
C
maintenance

Maintenance

Maintainers
Response time
Release cycle
Releases (12mo)
Commit activity

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/vincent2021/odoo-mcp-gateway'

If you have feedback or need assistance with the MCP directory API, please join our Discord server