odoo-mcp
Provides tools for interacting with Odoo's JSON-2 API, enabling AI agents to manage Odoo records and perform operations on Odoo instances.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@odoo-mcplist all open sales orders"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
odoo-mcp
Docker-first FastMCP server for Odoo 19 JSON-2 integrations.
odoo-mcp exposes Odoo as an MCP server over both HTTP and stdio. It uses the
Odoo 19 external JSON-2 API only:
POST /json/2/<model>/<method>
Authorization: bearer <ODOO_API_KEY>
X-Odoo-Database: <optional database>Legacy XML-RPC and JSON-RPC are intentionally out of scope.
Status
This is an early implementation with a strong v1 foundation:
FastMCP
3.2.4Docker Compose first
HTTP and stdio transports
lazy Odoo credential loading so MCP discovery works before secrets are present
guarded write operations with
confirm=Truegeneric Odoo tools
comprehensive CRM tool pack
resources and prompts for safe Odoo work
pytest, ruff, mypy, and GitHub Actions CI
Related MCP server: Odoo MCP Server
Quick Start With Docker
Copy the environment template and edit the Odoo values:
cp .env.example .envRequired for real Odoo calls:
ODOO_URL=https://your-odoo-host.example.com
ODOO_API_KEY=your-odoo-api-key
ODOO_DATABASE=your-database-if-neededStart the HTTP server:
docker compose up --buildThe default MCP endpoint is:
http://localhost:8000/mcpCheck local process readiness:
docker compose exec odoo-mcp uv run --no-sync odoo-mcp healthcheckLocal Development
Install dependencies:
uv syncRun the full gate:
uv run pytest
uv run ruff check .
uv run ruff format --check .
uv run mypy srcRun HTTP locally:
uv run odoo-mcp http --host 0.0.0.0 --port 8000 --path /mcpRun stdio locally:
uv run odoo-mcp stdioInspect sanitized config:
uv run odoo-mcp inspect-configMCP Client Config
Stdio example:
{
"mcpServers": {
"odoo": {
"command": "uv",
"args": ["run", "odoo-mcp", "stdio"],
"env": {
"ODOO_URL": "https://your-odoo-host.example.com",
"ODOO_API_KEY": "your-odoo-api-key",
"ODOO_DATABASE": "your-database-if-needed"
}
}
}
}HTTP clients should connect to /mcp. If the server is exposed beyond a trusted
network, set MCP_AUTH_MODE=static or MCP_AUTH_MODE=jwt.
Configuration
Variable | Purpose |
| Base URL for Odoo 19 JSON-2 calls. |
| Odoo API key sent as |
| Optional Odoo database header. |
| HTTP timeout for Odoo calls. Defaults to |
| Comma-separated allowlist for otherwise blocked generic methods. |
| Comma-separated optional CRM features to expose. |
|
|
| Bearer token for |
| JWKS URL for |
| Public key alternative for JWT verification. |
| Optional expected JWT issuer. |
| Optional expected JWT audience. |
| Optional comma-separated JWT scopes. |
| HTTP bind host. Defaults to |
| HTTP bind port. Defaults to |
| MCP endpoint path. Defaults to |
| HTTP server log level. Defaults to |
Tool Catalog
Generic Odoo tools:
odoo_search_readodoo_readodoo_createodoo_writeodoo_unlinkodoo_actionodoo_call_methododoo_current_userodoo_model_fieldsodoo_list_models
CRM tools:
leads and opportunities:
crm_list_leads,crm_get_lead,crm_create_lead,crm_update_lead,crm_assign_leadpipeline:
crm_list_pipeline_stages,crm_move_lead_to_stage,crm_pipeline_reportwon/lost lifecycle:
crm_mark_won,crm_mark_lost,crm_restore_lead,crm_list_lost_reasonsconversion and merge:
crm_convert_lead_to_opportunity,crm_merge_opportunitiesactivities:
crm_schedule_activity,crm_mark_activity_done,crm_list_activities,crm_list_activity_types,crm_activity_reportteams and scoring:
crm_list_teams,crm_update_lead_scoreoptional features:
crm_enrich_lead,crm_list_scoring_rules,crm_recurring_revenue_report
Optional CRM tools are registered only when their feature key is listed in
ODOO_CRM_OPTIONAL_FEATURES.
Resources And Prompts
Resources:
odoo://server/infoodoo://user/contextodoo://model/{model}/fieldsodoo://crm/pipeline/summary
Prompts:
odoo_safe_operationodoo_crm_pipeline_reviewodoo_record_change_plan
Safety Model
Odoo remains the final authorization layer through its access rights and record rules. The MCP server adds local guardrails:
mutating Odoo client calls require
confirm=Truegeneric dangerous methods such as
call_kwandexecute_kware blocked unless explicitly allowlistedHTTP MCP auth is separate from the server-side Odoo API key
inspect-configredacts secretsOdoo API errors redact configured secret values
Use MCP_AUTH_MODE=static for simple private HTTP deployments:
MCP_AUTH_MODE=static
MCP_STATIC_TOKEN=change-meUse MCP_AUTH_MODE=jwt with JWT_JWKS_URI or JWT_PUBLIC_KEY for production
identity-provider-backed deployments.
Extending
Add module packs under src/odoo_mcp/tools/ and register them from
src/odoo_mcp/server.py. Prefer typed, curated tools for business workflows and
leave odoo_call_method as the explicit escape hatch.
When adding new Odoo workflows:
Write tests first with mocked Odoo JSON-2 behavior.
Prefer single-call Odoo methods like
search_readbecause each JSON-2 call is its own transaction.Require
confirm=Truefor writes, actions, posting, validation, archive, and delete operations.Add focused README entries for new tools and optional feature flags.
Available Tools
1 toolhealthcheckA
Return local server readiness metadata.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only operation returning metadata, which is typical for a healthcheck. However, without annotations, the description does not explicitly confirm non-destructive behavior or other traits like rate limits or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words, efficiently conveying the tool's purpose. It earns its place without any filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no siblings), the description is nearly complete. The presence of an output schema reduces the need to detail return values, though 'metadata' is somewhat vague. It covers the essential purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, the baseline is 4. The description adds value by specifying the returned content ('readiness metadata'), which is beyond what the empty schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states the tool returns 'local server readiness metadata,' using a specific verb ('return') and a clear resource. No sibling tools exist, so differentiation is not needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a health check for monitoring server readiness, but provides no explicit when-to-use or when-not-to-use guidance. The lack of siblings reduces the need for alternatives, but the description misses contextual cues like frequency or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
With only one tool, there is no possibility of confusion between tools. The purpose of 'healthcheck' is clear and distinct.
A single tool cannot be inconsistent with itself. The name 'healthcheck' is a reasonable single-word descriptor.
The server is named for Odoo, a full-featured ERP system, but provides only a single health check endpoint. This is an extreme mismatch between scope and tool count.
For an Odoo integration, a single healthcheck tool is severely incomplete, lacking any CRUD operations or domain-specific functionality.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Let AI agents query data and act across all your business apps via MCP.
Automate 1,000+ services from any MCP-compatible AI agent: build Applets, run actions and queries.
Unified MCP Server is a remote MCP connector for AI agents and vertical AI products that provides access to 22,000+ authorized SaaS tools across 400+ integrations and 24 categories directly inside LLMs (Claude, GPT, Gemini, Cohere). Tools operate only on explicitly authorized customer connections, enabling agents to safely read and write against live third-party systems.
Free public MCP for AI agents — 193 tools, 44 workflows. No API key.
Related MCP Servers
- AlicenseAqualityDmaintenanceEnables AI assistants to interact with Odoo data using natural language to search, read, create, and update records. It acts as a secure bridge between MCP clients and Odoo instances version 17.0 through 19.0.11Apache 2.0
- AlicenseNot gradedqualityDmaintenanceBridges AI agents to Odoo ERP via MCP, enabling CRUD operations, model introspection, and report generation with secure API key and connection management through a web admin UI.4GPL 3.0
- AlicenseNot gradedqualityDmaintenanceEnables AI agents to interact with Odoo ERP to perform sales tasks such as searching clients and products, and creating and confirming quotations via the MCP protocol.2MIT
- AlicenseNot gradedqualityDmaintenanceEnables interaction with Odoo 18 (JSON-RPC API) via MCP, supporting model exploration, CRUD operations, and secure API key authentication.Apache 2.0
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/plgonzalezrx8/odoo-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server