odoo-mcp
odoo-mcp
Servidor FastMCP orientado a Docker para integraciones con Odoo 19 JSON-2.
El tiempo de ejecución expone una fábrica de servidores compartida utilizada tanto por transportes stdio como HTTP. Las herramientas específicas de Odoo pueden registrarse en esa fábrica desde odoo_mcp.tools.register_tools(server, config) o un módulo de registro compatible.
Inicio rápido
Copie la plantilla de entorno:
cp .env.example .envEdite
.envcon su endpoint y credenciales de Odoo.Inicie el servidor HTTP:
docker compose up --buildInspeccione la disponibilidad local:
docker compose exec odoo-mcp uv run --no-sync odoo-mcp healthcheck
El endpoint MCP predeterminado es http://localhost:8000/mcp.
Related MCP server: odoo-mcp
Comandos de tiempo de ejecución
Ejecutar sobre stdio para clientes MCP que lanzan el proceso del servidor directamente:
odoo-mcp stdioEjecutar sobre HTTP:
odoo-mcp http --host 0.0.0.0 --port 8000 --path /mcpInspeccionar la configuración saneada sin exponer secretos:
odoo-mcp inspect-configComprobar la disponibilidad del proceso local sin contactar con Odoo:
odoo-mcp healthcheckConfiguración
Variable | Propósito |
| URL base para llamadas JSON-2 de Odoo. Requerido por las herramientas de la API de Odoo. |
| Nombre opcional de la base de datos de Odoo. |
| Nombre de usuario opcional de Odoo. |
| Contraseña opcional de Odoo. Redactada por |
| Clave de API opcional de Odoo. Redactada por |
| Secreto opcional para futuros middleware de autenticación HTTP. Redactado por |
| Host de enlace HTTP. Por defecto |
| Puerto de enlace HTTP. Por defecto |
| Ruta del endpoint HTTP. Por defecto |
| Nivel de registro de Uvicorn. Por defecto |
Desarrollo
Instale y ejecute pruebas con uv:
uv sync
uv run pytestComprobaciones estáticas utilizadas por CI:
uv run ruff check .
uv run mypyDocker es la ruta de despliegue objetivo, pero no se requiere Docker local para las pruebas unitarias. La comprobación de salud de Docker utiliza odoo-mcp healthcheck, que valida la conexión del proceso del servidor sin realizar llamadas de red externas.
Puntos de integración
La fábrica compartida es odoo_mcp.server.build_server(). Siempre registra una herramienta healthcheck local, y luego intenta importar el registro de herramientas desde:
odoo_mcp.tools.register_toolsodoo_mcp.tools.registry.register_toolsodoo_mcp.tools.odoo.register_tools
Las funciones compatibles pueden aceptar (server) o (server, config). Esto tiene como objetivo permitir que el cliente de Odoo, el esquema y los trabajadores de herramientas se implementen de forma independiente sin cambiar los puntos de entrada del tiempo de ejecución.
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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.1.0- First observed
healthcheck
TDQS
Scored across 1 tool
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
Related MCP Connectors
Let AI agents query data and act across all your business apps via MCP.
Connect any AI agent to 1,000+ apps and 27,000+ actions through one remote MCP server (OAuth).
Connect AI to Odoo ERP 14-20: search, create, update and manage records in natural language.
185
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables interaction with Odoo 18 (JSON-RPC API) via MCP, supporting model exploration, CRUD operations, and secure API key authentication.Apache 2.0
- AlicenseNot gradedqualityCmaintenanceEnables Claude to interact with Odoo through 12 MCP tools covering discovery, CRUD operations, and bulk import/export via XML-RPC.MIT
- FlicenseNot gradedqualityCmaintenanceExposes Odoo 19 ERP as MCP tools, enabling AI agents to query and act on CRM data (leads, semantic search) via natural language without custom integration.-
- AlicenseAqualityBmaintenanceEnables interaction with Odoo 19 databases through the External JSON-2 API, allowing model operations such as search, read, create, write, and unlink via MCP tools.2MIT