Skip to main content
Glama
plgonzalezrx8

odoo-mcp

odoo-mcp

FastMCP-сервер с приоритетом Docker для интеграций с Odoo 19 через JSON-2.

Среда выполнения предоставляет общую фабрику серверов, используемую как для транспорта stdio, так и для HTTP. Инструменты, специфичные для Odoo, могут быть зарегистрированы в этой фабрике через odoo_mcp.tools.register_tools(server, config) или совместимый модуль реестра.

Быстрый старт

  1. Скопируйте шаблон окружения:

    cp .env.example .env
  2. Отредактируйте .env, указав адрес вашего Odoo и учетные данные.

  3. Запустите HTTP-сервер:

    docker compose up --build
  4. Проверьте локальную готовность:

    docker compose exec odoo-mcp uv run --no-sync odoo-mcp healthcheck

Конечная точка MCP по умолчанию: http://localhost:8000/mcp.

Related MCP server: odoo-mcp

Команды среды выполнения

Запуск через stdio для MCP-клиентов, которые запускают процесс сервера напрямую:

odoo-mcp stdio

Запуск через HTTP:

odoo-mcp http --host 0.0.0.0 --port 8000 --path /mcp

Просмотр очищенной конфигурации без раскрытия секретов:

odoo-mcp inspect-config

Проверка готовности локального процесса без обращения к Odoo:

odoo-mcp healthcheck

Конфигурация

Переменная

Назначение

ODOO_URL

Базовый URL для вызовов Odoo JSON-2. Требуется для инструментов API Odoo.

ODOO_DATABASE

Необязательное имя базы данных Odoo.

ODOO_USERNAME

Необязательное имя пользователя Odoo.

ODOO_PASSWORD

Необязательный пароль Odoo. Скрывается командой inspect-config.

ODOO_API_KEY

Необязательный API-ключ Odoo. Скрывается командой inspect-config.

JWT_SECRET

Необязательный секрет для будущего промежуточного ПО HTTP-аутентификации. Скрывается командой inspect-config.

MCP_HTTP_HOST

Хост для привязки HTTP. По умолчанию 0.0.0.0.

MCP_HTTP_PORT

Порт для привязки HTTP. По умолчанию 8000.

MCP_HTTP_PATH

Путь к конечной точке HTTP. По умолчанию /mcp.

MCP_LOG_LEVEL

Уровень логирования Uvicorn. По умолчанию info.

Разработка

Установка и запуск тестов с помощью uv:

uv sync
uv run pytest

Статические проверки, используемые в CI:

uv run ruff check .
uv run mypy

Docker является целевым путем развертывания, но локальный Docker не требуется для модульных тестов. Проверка работоспособности (healthcheck) Docker использует odoo-mcp healthcheck, которая проверяет подключение процесса сервера без выполнения внешних сетевых вызовов.

Точки интеграции

Общая фабрика — odoo_mcp.server.build_server(). Она всегда регистрирует локальный инструмент healthcheck, а затем пытается импортировать регистрацию инструментов из:

  • odoo_mcp.tools.register_tools

  • odoo_mcp.tools.registry.register_tools

  • odoo_mcp.tools.odoo.register_tools

Совместимые функции могут принимать аргументы (server) или (server, config). Это сделано для того, чтобы клиент Odoo, схема и рабочие инструменты могли добавляться независимо без изменения точек входа среды выполнения.

Available Tools

1 tool
healthcheckA

Return local server readiness metadata.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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. 1 tool updatev0.1.0
    • First observedhealthcheck

TDQS

A3.7/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of confusion between tools. The purpose of 'healthcheck' is clear and distinct.

Naming Consistency5/5

A single tool cannot be inconsistent with itself. The name 'healthcheck' is a reasonable single-word descriptor.

Tool Count1/5

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.

Completeness1/5

For an Odoo integration, a single healthcheck tool is severely incomplete, lacking any CRUD operations or domain-specific functionality.

Maintenance

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    Enables interaction with Odoo 18 (JSON-RPC API) via MCP, supporting model exploration, CRUD operations, and secure API key authentication.
    Apache 2.0
  • A
    license
    Not graded
    quality
    C
    maintenance
    Enables Claude to interact with Odoo through 12 MCP tools covering discovery, CRUD operations, and bulk import/export via XML-RPC.
    MIT
  • F
    license
    Not graded
    quality
    C
    maintenance
    Exposes 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.
    -
  • A
    license
    A
    quality
    B
    maintenance
    Enables 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.
    2
    MIT