MCP-сервер для Odoo 19, использующий подключение через JSON-2 API.
Данный проект разработан на основе полного руководства по использованию Odoo 19 JSON-2 API.
Python: 3.13
FastMCP: >=3.0.0,<4.0.0
odoo-client-lib: 2.0.1 (JSON-2 API)
Related MCP server: odxproxy-mcpserver
flowchart TB
subgraph Client["MCP Client"]
CC[Claude Code]
GC[Gemini CLI]
MI[MCP Inspector]
end
subgraph Server["MCP Server (FastMCP)"]
R[Resources<br/>odoo://models<br/>odoo://user<br/>odoo://company]
T[Tools<br/>search_records<br/>create_record<br/>update_record]
DI[Dependency Injection<br/>get_shared_client]
end
subgraph RPC["OdooJsonRpcClient"]
OL[odoolib<br/>json2/json2s protocol]
end
subgraph Odoo["Odoo Server"]
EP["/jsonrpc endpoint"]
end
Client -->|MCP Protocol<br/>stdio/http/sse| Server
R --> DI
T --> DI
DI --> RPC
RPC -->|HTTP/HTTPS| OdooХарактеристика | Ресурсы | Инструменты |
Назначение | Предоставление контекстной информации | Выполнение операций/действий |
Триггер | Управление клиентом (например, Claude Code) | LLM автоматически решает, когда вызвать |
Параметры | Нет (или параметры URI) | Есть (генерируются LLM) |
Аналогия | Справочник сотрудника (фоновые знания) | Набор инструментов (используется по мере необходимости) |
Аналогия HTTP | GET (чтение) | POST/PUT/DELETE (операции) |
Ресурсы — динамический контекст, фоновая информация, которую LLM знает с самого начала:
odoo://user → "我是誰"
odoo://company → "我在哪間公司"
odoo://models → "有哪些模型可用"Инструменты — операции, вызываемые только при необходимости:
search_records(model="res.partner", domain=[...]) → 搜尋
create_record(model="sale.order", values={...}) → 建立Способ | Default Prompt | Ресурс |
Источник данных | Жестко прописан в коде | Запрос к Odoo в реальном времени |
Время обновления | При развертывании | При каждом подключении |
Смена пользователя | Неверная информация | Автоматически корректная |
# ❌ Default Prompt（寫死）
SYSTEM_PROMPT = "當前用戶: Admin" # 換人登入就錯了
# ✅ Resource（動態）
@mcp.resource("odoo://user")
def get_current_user():
return client.read("res.users", [uid]) # 即時查詢Вывод: Ресурс — это «динамический контекст», а не статический текст.
См. также: MCP Resources | MCP Tools
Переменная | Описание | Значение по умолчанию |
| URL сервера Odoo |
|
| Имя базы данных | - |
| Аутентификация по API Key | - |
| Режим только для чтения (запрет записи) |
|
Создайте файл .env:
cp .env.example .envpip install -r requirements.txtfastmcp dev inspector odoo_mcp_server.pyДанный проект поддерживает три режима передачи MCP:
Режим | Описание | Сценарии использования |
| Стандартный ввод/вывод (по умолчанию) | Claude Desktop, Cursor IDE, локальная разработка |
| Протокол HTTP | Удаленные сервисы, n8n, интеграция с веб-приложениями |
| Server-Sent Events (устарело) | Обратная совместимость со старыми клиентами |
Ключевое различие между двумя режимами заключается в том, «кто запускает MCP-сервер» и «где выполняются вычисления»:
Режим stdio (локальные вычисления)
┌─────────────────────────────────────┐
│ 你的電腦 💻 │
│ │
│ Claude Desktop ──> MCP Server │
│ (使用本機算力) │
└─────────────────────────────────────┘Клиент (например, Claude Desktop) запускает MCP-сервер как дочерний процесс
MCP-сервер использует CPU/RAM вашего компьютера
Сервер запускается/завершается вместе с клиентом
Режим HTTP/SSE (удаленные вычисления)
┌──────────────┐ ┌──────────────────┐
│ 你的電腦 │ │ 雲端 ☁️ │
│ │ │ │
│Claude Desktop│ ──網路──>│ MCP Server │
│ (輕量) │ │ (使用雲端算力) │
└──────────────┘ └──────────────────┘MCP-сервер работает независимо в облаке или на удаленном хосте
Несколько клиентов могут подключаться к одному серверу одновременно
Подходит для командной работы, интеграции с n8n и промышленной эксплуатации
# stdio 模式（預設）
python odoo_mcp_server.py
# HTTP 模式
python odoo_mcp_server.py --transport http --host 0.0.0.0 --port 8000
# SSE 模式（已棄用，建議使用 HTTP）
python odoo_mcp_server.py --transport sse --host 0.0.0.0 --port 8000Пример Docker Compose:
services:
odoo-mcp:
build: .
ports:
- "8000:8000"
environment:
- ODOO_URL=http://odoo:8069
- ODOO_DATABASE=odoo19
- ODOO_API_KEY=your_api_key_here
command: ["python", "odoo_mcp_server.py", "--transport", "http", "--host", "0.0.0.0", "--port", "8000"]
restart: unless-stoppedНастройка клиента (claude) для использования URL-подключения:
claude mcp add --transport http odoo-mcp https://your-cloud-server.com:8000/mcp{
"mcpServers": {
"odoo-mcp": {
"type": "http",
"url": "https://your-cloud-server.com:8000/mcp"
}
}
}URI | Описание |
| Список всех моделей |
| Получение определений полей модели |
| Получение отдельной записи |
| Информация о текущем пользователе |
| Информация о компании текущего пользователя |
Инструмент | Описание | Только чтение |
| Список/поиск доступных моделей | Yes |
| Получение определений полей модели | Yes |
| Поиск записей | Yes |
| Подсчет записей | Yes |
| Чтение записи по ID | Yes |
| Создание записи | No |
| Обновление записи | No |
| Удаление записи (требует подтверждения) | No |
| Выполнение метода модели | Depends |
Файл конфигурации находится в ~/.claude.json:
claude mcp add odoo-mcp-server -- python odoo_mcp_server.py{
"mcpServers": {
"odoo-mcp-server": {
"command": "/bin/python",
"args": [
"odoo_mcp_server.py"
]
}
}
}Подходит для случаев, когда Odoo запущена локально:
claude mcp add odoo-mcp-server -- docker run -i --rm --add-host=host.docker.internal:host-gateway -e ODOO_URL=http://host.docker.internal:8069 -e ODOO_DATABASE=odoo19 -e ODOO_API_KEY=your_api_key_here odoo-mcp-server{
"mcpServers": {
"odoo-mcp-server": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"--add-host=host.docker.internal:host-gateway",
"-e",
"ODOO_URL=http://host.docker.internal:8069",
"-e",
"ODOO_DATABASE=odoo19",
"-e",
"ODOO_API_KEY=your_api_key_here",
"odoo-mcp-server"
]
}
}
}Использование сетевого режима хоста:
claude mcp add odoo-mcp-server -- docker run -i --rm --network host -e ODOO_URL=http://localhost:8069 -e ODOO_DATABASE=odoo19 -e ODOO_API_KEY=your_api_key_here odoo-mcp-server{
"mcpServers": {
"odoo-mcp-server": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"--network",
"host",
"-e",
"ODOO_URL=http://localhost:8069",
"-e",
"ODOO_DATABASE=odoo19",
"-e",
"ODOO_API_KEY=your_api_key_here",
"odoo-mcp-server"
]
}
}
}claude mcp add odoo-mcp-server -- docker run -i --rm -e ODOO_URL=https://example.com/ -e ODOO_DATABASE=odoo19 -e ODOO_API_KEY=your_api_key_here odoo-mcp-server{
"mcpServers": {
"odoo-mcp-server": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"ODOO_URL=https://example.com/",
"-e",
"ODOO_DATABASE=odoo19",
"-e",
"ODOO_API_KEY=your_api_key_here",
"odoo-mcp-server"
]
}
}
}docker build -t odoo-mcp-server .gemini mcp add --scope user odoo-mcp docker -- run -i --rm --add-host=host.docker.internal:host-gateway -e ODOO_URL=http://host.docker.internal:8069 -e ODOO_DATABASE=odoo19 -e ODOO_API_KEY=your_api_key_here odoo-mcp-server{
"mcpServers": {
"odoo-mcp": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"--add-host=host.docker.internal:host-gateway",
"-e",
"ODOO_URL=http://host.docker.internal:8069",
"-e",
"ODOO_DATABASE=odoo19",
"-e",
"ODOO_API_KEY=your_api_key_here",
"odoo-mcp-server"
]
}
}
}Установите READONLY_MODE=true для включения режима «только чтение», подходящего для производственных сред:
Инструменты записи (create_record, update_record, delete_record, execute_method) скрываются напрямую через теги FastMCP, поэтому LLM не будет их видеть.
delete_record имеет встроенный механизм подтверждения: LLM должна сначала вызвать его с параметром confirm=False для получения запроса на подтверждение, и только после согласия пользователя выполнить удаление с confirm=True.
В режимах HTTP/SSE предоставляется эндпоинт /health:
curl http://localhost:8000/health
# {"status": "healthy", "service": "odoo-mcp-server", "version": "1.0.0"}Подходит для Docker healthcheck, проверок Kubernetes, балансировщиков нагрузки. В режиме stdio не используется.
Apache 2.0
Count records in an Odoo model matching the domain.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Model name (e.g., 'res.partner') | |
| domain | No | Odoo search domain (list of conditions). Examples: - Simple: [["active", "=", True]] - Multiple (AND): [["is_company", "=", True], ["country_id", "=", 1]] - OR condition: ["|", ["type", "=", "contact"], ["type", "=", "invoice"]] - any (Odoo 19+): [["order_line", "any", [["product_uom_qty", ">", 5]]]] - Operators: =, !=, >, >=, <, <=, like, ilike, in, not in, child_of, any |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint. Description adds no further behavioral context beyond the count operation.
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?
Single sentence is direct and front-loaded, but could include minimal context like returning the count as an integer.
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?
For a simple read-only counting tool with full annotations and output schema, the description is completely adequate.
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?
Input schema covers 100% of parameters with descriptions. Description adds no additional parameter meaning beyond what schema already 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 clearly states it counts records in an Odoo model with a domain filter, distinguishing it from siblings like search_records or read_records.
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?
Description does not explicitly mention when to use this tool versus alternatives; usage is implied but not guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create new record(s) in an Odoo model.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Model name (e.g., 'res.partner') | |
| values | Yes | Dictionary of field values, or list of dicts for batch creation |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as idempotency, error handling, authorization requirements, or side effects beyond creation.
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 concise sentence, front-loaded with the key action. It is not verbose, but could benefit from mentioning batch creation capability briefly.
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?
For a creation tool with no annotations, the description is minimal. It does not mention required permissions, success response, or batch behavior, despite having an output schema that could cover returns.
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?
Schema description coverage is 100%, so the description adds no additional meaning beyond what the schema already provides for both parameters (model and values). Baseline 3 is appropriate.
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?
The description clearly specifies the action 'create' and the resource 'record(s) in an Odoo model', which is distinct from sibling tools like update_record or delete_record.
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?
No guidance on when to use this tool versus alternatives (e.g., update_record for modifications) or when not to use it. The description is silent on prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete records from an Odoo model. IRREVERSIBLE operation.
IMPORTANT: You MUST first call with confirm=False to show the user what will be deleted. Only set confirm=True AFTER the user explicitly approves the deletion. NEVER set confirm=True on the first call.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Model name (e.g., 'res.partner') | |
| ids | Yes | List of record IDs to delete | |
| confirm | No | Safety flag. Always call with False first, then True only after user approval. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by emphasizing the irreversibility and the required two-step confirmation process. It adds critical behavioral context that annotations alone (destructiveHint, idempotentHint) do not fully convey.
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 concise and well-structured, with the action stated first, followed by a clear warning and step-by-step instructions. Every sentence adds value without redundancy.
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 presence of an output schema and annotations covering destructiveness and idempotence, the description is complete. It provides all necessary safety protocol for a deletion operation, leaving no gaps in understanding.
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?
The input schema already fully describes the three parameters with 100% coverage. The description reinforces the confirm parameter's usage but does not add new meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
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?
Clearly states the action is deleting records from an Odoo model, using a specific verb and resource. The distinction from sibling tools like create_record and update_record is evident.
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?
Explicitly instructs to first call with confirm=False to preview deletion, then only set confirm=True after user approval. This provides clear when-to-use guidance and prevents misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute any method on an Odoo model.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Model name (e.g., 'res.partner') | |
| method | Yes | Method name to execute | |
| args | No | Positional arguments for the method | |
| kwargs | No | Keyword arguments for the method |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It only states 'Execute any method' but omits critical behavioral traits such as potential destructive side effects, required permissions, or whether the method is idempotent. This is a major omission for such a powerful tool.
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, but it is too brief for the tool's complexity. Conciseness is good, but it sacrifices necessary detail, making it borderline under-specified.
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?
Despite having an output schema, the description does not mention return values. More critically, it lacks warnings about executing arbitrary methods, which is a safety concern. The tool's complexity demands far more context.
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?
Schema description coverage is 100%, with clear descriptions for model, method, args, and kwargs. The description adds no additional meaning beyond the schema, earning a baseline 3.
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?
The description clearly states the verb ('Execute') and resource ('any method on an Odoo model'). It distinguishes from siblings like 'create_record' or 'delete_record' which are specific CRUD operations, making it unique.
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?
No guidance on when or when not to use this tool. It does not compare to alternatives like 'create_record' or 'update_record' or mention prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get field information for an Odoo model using ORM fields_get().
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Model name (e.g., 'res.partner') | |
| field_filter | No | Optional filter for field name (e.g., 'name' to find name-related fields) | |
| fields | No | Specific field names to retrieve (None = all fields) | |
| attributes | No | Field attributes to return (None = default attributes including type, string, help, required, readonly, store, selection, comodel_name, inverse_name, domain) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds that the tool uses the ORM's fields_get() method, but does not disclose additional behavioral traits like potential performance impact on large models or that it might return a large volume of data. Given the good annotation coverage, this is adequate but not exceptional.
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 that immediately communicates purpose and method. It contains no filler or redundant information, making it optimally concise and front-loaded.
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?
For a read-only metadata retrieval tool with 4 parameters, full schema documentation, and an output schema, the description is mostly complete. It lacks mention of error cases (e.g., invalid model name) but these are partially covered by the schema descriptions. Overall, it is sufficient for an AI agent to understand basic functionality.
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?
Schema coverage is 100% with all four parameters described in the input schema. The description does not add any parameter-specific semantics beyond what the schema provides. The mention of using ORM fields_get() is a general context, not parameter detail. Baseline 3 is appropriate.
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?
The description clearly states the action ('Get field information'), the resource ('for an Odoo model'), and the method ('using ORM fields_get()'). It accurately distinguishes this tool from siblings like 'read_records' (which retrieve data rows) and 'list_models' (which list models) by specifying it returns field metadata.
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 provides no guidance on when to use this tool versus alternatives, such as 'execute_method' for calling fields_get generically, or 'list_models' for getting available models. There are no usage conditions, exclusions, or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available Odoo models.
| Name | Required | Description | Default |
|---|---|---|---|
| name_filter | No | Optional filter for model name (e.g., 'sale' to find sale-related models) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint as true, and the description adds no additional behavioral details beyond the simple listing operation.
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 concise sentence with no extraneous information, efficiently conveying the tool's purpose.
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, one parameter, and existing annotations/output schema, the description adequately covers the essentials; minor gap in clarifying 'available models' scope.
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?
Schema description coverage is 100%, so the schema already explains the optional name_filter parameter; the main description adds no further parameter context.
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?
The description 'List all available Odoo models' uses a specific verb and resource, clearly distinguishing it from sibling tools that operate on records rather than models.
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?
No explicit guidance on when to use this tool versus alternatives, but the context implies its use when discovering available models; lack of exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read specific records by their IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Model name (e.g., 'res.partner') | |
| ids | Yes | List of record IDs to read | |
| fields | No | Fields to return (None = auto-exclude dangerous fields like binary/image/html) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and idempotentHint=true, so the description adds no new behavioral traits. It does not contradict annotations but also does not elaborate on what the tool returns or any side effects.
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?
Single sentence, front-loaded with key action and resource, no unnecessary words. Perfectly concise for a simple read tool.
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, annotations covering safety and idempotence, full schema documentation, and presence of output schema, the description is complete. No additional context needed.
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?
Schema has 100% description coverage, so the description adds little beyond 'by their IDs', which is already implied by the ids parameter. Baseline 3 applies as description is adequate but not enhancing.
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?
The description clearly states the verb 'Read' and resource 'records', specifying the mechanism 'by their IDs'. This distinguishes it from sibling tools like search_records and count_records.
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?
No explicit when-to-use or when-not-to-use guidance is provided. While the purpose is clear, it does not differentiate from alternatives like search_records or get_fields, leaving the agent to infer contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for records in an Odoo model.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Model name (e.g., 'res.partner') | |
| domain | No | Odoo search domain (list of conditions). Examples: - Simple: [["name", "=", "John"]] - Multiple (AND): [["is_company", "=", True], ["active", "=", True]] - OR condition: ["|", ["name", "ilike", "test"], ["email", "ilike", "test"]] - any (Odoo 19+): [["order_line", "any", [["product_uom_qty", ">", 5]]]] - Operators: =, !=, >, >=, <, <=, like, ilike, in, not in, child_of, any | |
| fields | No | Fields to return (None = auto-exclude dangerous fields like binary/image/html) | |
| limit | No | Maximum number of records | |
| offset | No | Number of records to skip | |
| order | No | Sort order (e.g., 'name asc', 'create_date desc') |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds no additional behavioral context (e.g., that results depend on model permissions or that it returns a list). Bar is lowered by good annotations, but the description does not add value beyond the schema.
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 that efficiently states the tool's core function with no wasted words.
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 rich input schema and annotations, the description is minimally adequate but lacks context about usage scope (e.g., domain filtering) and return behavior. Output schema exists but is not referenced.
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?
Schema coverage is 100%, so every parameter has a description. The tool description does not add any info beyond the schema; baseline 3 is appropriate.
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?
The description uses a specific verb ('Search') and resource ('records in an Odoo model'), clearly distinguishing it from sibling tools like 'read_records' (read by ID) and 'count_records'.
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?
No guidance is provided on when to use this tool versus alternatives such as 'read_records' or 'count_records'. The description does not mention context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update existing records in an Odoo model.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Model name (e.g., 'res.partner') | |
| ids | Yes | List of record IDs to update | |
| values | Yes | Dictionary of field values to update |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint: true. Description adds no extra behavioral context (e.g., what happens if record doesn't exist). It is adequate but does not go beyond the schema.
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?
Single sentence, no wasted words. Efficient, though could be slightly expanded with key usage details without losing conciseness.
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 output schema exists and input schema fully describes parameters, the brief description is nearly sufficient. Minor lack of info about behavior on invalid IDs or return structure, but overall complete.
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?
All 3 parameters have descriptions in the schema (100% coverage). The description adds no new meaning beyond what is already in the input schema.
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 clearly states 'Update existing records in an Odoo model' – a specific verb and resource, and implicitly distinguishes from sibling tools like create_record and delete_record.
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?
No explicit guidance on when to use or not use this tool vs alternatives. It is implied by context (update vs create/delete) but lacks explicit when-not-to-use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
count_records2 fields changedInput schema / properties / domain / descriptionAdded value: +"Odoo search domain (list of conditions). Examples:\n- Simple: [[\"active\", \"=\", True]]\n- Multiple (AND): [[\"is_company\", \"=\", True], [\"country_id\", \"=\", 1]]\n- OR condition: [\"|\", [\"type\", \"=\", \"contact\"], [\"type\", \"=\", \"invoice\"]]\n- any (Odoo 19+): [[\"order_line\", \"any\", [[\"product_uom_qty\", \">\", 5]]]]\n- Operators: =, !=, >, >=, <, <=, like, ilike, in, not in, child_of, any"Input schema / properties / model / descriptionAdded value: +"Model name (e.g., 'res.partner')"create_record2 fields changedInput schema / properties / model / descriptionAdded value: +"Model name (e.g., 'res.partner')"Input schema / properties / values / descriptionAdded value: +"Dictionary of field values, or list of dicts for batch creation"delete_record3 fields changedInput schema / properties / confirm / descriptionAdded value: +"Safety flag. Always call with False first, then True only after user approval."Input schema / properties / ids / descriptionAdded value: +"List of record IDs to delete"Input schema / properties / model / descriptionAdded value: +"Model name (e.g., 'res.partner')"execute_method4 fields changedInput schema / properties / args / descriptionAdded value: +"Positional arguments for the method"Input schema / properties / kwargs / descriptionAdded value: +"Keyword arguments for the method"Input schema / properties / method / descriptionAdded value: +"Method name to execute"Input schema / properties / model / descriptionAdded value: +"Model name (e.g., 'res.partner')"get_fields4 fields changedInput schema / properties / attributes / descriptionAdded value: +"Field attributes to return (None = default attributes including\n type, string, help, required, readonly, store, selection,\n comodel_name, inverse_name, domain)"Input schema / properties / field_filter / descriptionAdded value: +"Optional filter for field name (e.g., 'name' to find name-related fields)"Input schema / properties / fields / descriptionAdded value: +"Specific field names to retrieve (None = all fields)"Input schema / properties / model / descriptionAdded value: +"Model name (e.g., 'res.partner')"list_models1 field changedInput schema / properties / name_filter / descriptionAdded value: +"Optional filter for model name (e.g., 'sale' to find sale-related models)"read_records3 fields changedInput schema / properties / fields / descriptionAdded value: +"Fields to return (None = auto-exclude dangerous fields like binary/image/html)"Input schema / properties / ids / descriptionAdded value: +"List of record IDs to read"Input schema / properties / model / descriptionAdded value: +"Model name (e.g., 'res.partner')"search_records6 fields changedInput schema / properties / domain / descriptionAdded value: +"Odoo search domain (list of conditions). Examples:\n- Simple: [[\"name\", \"=\", \"John\"]]\n- Multiple (AND): [[\"is_company\", \"=\", True], [\"active\", \"=\", True]]\n- OR condition: [\"|\", [\"name\", \"ilike\", \"test\"], [\"email\", \"ilike\", \"test\"]]\n- any (Odoo 19+): [[\"order_line\", \"any\", [[\"product_uom_qty\", \">\", 5]]]]\n- Operators: =, !=, >, >=, <, <=, like, ilike, in, not in, child_of, any"Input schema / properties / fields / descriptionAdded value: +"Fields to return (None = auto-exclude dangerous fields like binary/image/html)"Input schema / properties / limit / descriptionAdded value: +"Maximum number of records"Input schema / properties / model / descriptionAdded value: +"Model name (e.g., 'res.partner')"Input schema / properties / offset / descriptionAdded value: +"Number of records to skip"Input schema / properties / order / descriptionAdded value: +"Sort order (e.g., 'name asc', 'create_date desc')"update_record3 fields changedInput schema / properties / ids / descriptionAdded value: +"List of record IDs to update"Input schema / properties / model / descriptionAdded value: +"Model name (e.g., 'res.partner')"Input schema / properties / values / descriptionAdded value: +"Dictionary of field values to update"v1.0.0count_recordscreate_recorddelete_recordexecute_methodget_fieldslist_modelsread_recordssearch_recordsupdate_recordScored across 9 tools
Each tool has a distinct purpose: count, create, delete, execute method, get fields, list models, read, search, update. No two tools overlap in functionality.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., count_records, create_record, list_models), making it predictable and easy to understand.
9 tools is well-scoped for an Odoo server, covering essential operations without being too few or too many.
The set includes CRUD operations, search, count, field introspection, model listing, and arbitrary method execution, providing comprehensive coverage for interacting with Odoo models.
MCP server for Product Management
MCP server for the Seline Analytics API
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.