Odoo 19 MCP Server、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特性 | Resources | Tools |
用途 | コンテキスト情報の提供 | 操作/アクションの実行 |
トリガー | クライアント制御（Claude Codeなど） | LLM が自動的に呼び出しを判断 |
パラメータ | なし（または URI パラメータ） | あり（LLM による生成が必要） |
例え | 社員ハンドブック（背景知識） | ツールボックス（必要に応じて使用） |
HTTP の例え | GET（読み取り） | POST/PUT/DELETE（操作） |
Resources - 動的なコンテキスト、LLM が最初から知っている背景情報：
odoo://user → "我是誰"
odoo://company → "我在哪間公司"
odoo://models → "有哪些模型可用"Tools - 必要な時にのみ呼び出す操作：
search_records(model="res.partner", domain=[...]) → 搜尋
create_record(model="sale.order", values={...}) → 建立方式 | Default Prompt | Resource |
データソース | コードにハードコード | Odoo からリアルタイムでクエリ |
更新タイミング | デプロイ時 | 接続のたび |
ユーザー切り替え | 情報が誤る | 自動的に正確 |
# ❌ Default Prompt（寫死）
SYSTEM_PROMPT = "當前用戶: Admin" # 換人登入就錯了
# ✅ Resource（動態）
@mcp.resource("odoo://user")
def get_current_user():
return client.read("res.users", [uid]) # 即時查詢結論：Resource は「動的なコンテキスト」であり、静的なテキストではありません。
参考：MCP Resources | MCP Tools
変数 | 説明 | デフォルト値 |
| Odoo サーバー URL |
|
| データベース名 | - |
| API Key 認証 | - |
| 読み取り専用モード（書き込み操作を禁止） |
|
.env ファイルの作成：
cp .env.example .envpip install -r requirements.txtfastmcp dev inspector odoo_mcp_server.py本プロジェクトは3つの MCP トランスポートモードをサポートしています：
モード | 説明 | 適用シナリオ |
| 標準入出力（デフォルト） | Claude Desktop、Cursor IDE、ローカル開発 |
| HTTP プロトコル | リモートサービス、n8n、Web アプリ統合 |
| Server-Sent Events（非推奨） | 旧版クライアントとの下位互換性 |
両モードの重要な違いは、「誰が MCP Server を起動するか」および「計算リソースがどこで実行されるか」です：
stdio モード（ローカル計算）
┌─────────────────────────────────────┐
│ 你的電腦 💻 │
│ │
│ Claude Desktop ──> MCP Server │
│ (使用本機算力) │
└─────────────────────────────────────┘クライアント（Claude Desktop など）が MCP Server をサブプロセスとして起動
MCP Server があなたのコンピュータの CPU/RAM を使用
サーバーはクライアントの起動/終了に合わせて動作
HTTP/SSE モード（リモート計算）
┌──────────────┐ ┌──────────────────┐
│ 你的電腦 │ │ 雲端 ☁️ │
│ │ │ │
│Claude Desktop│ ──網路──>│ MCP Server │
│ (輕量) │ │ (使用雲端算力) │
└──────────────┘ └──────────────────┘MCP Server がクラウド/リモートホスト上で独立して動作
複数のクライアントが同時に同じサーバーに接続可能
チーム共有、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 8000Docker 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 | 説明 |
| 全モデルの一覧表示 |
| モデルのフィールド定義を取得 |
| 単一レコードの取得 |
| 現在ログイン中のユーザー情報 |
| 現在のユーザーが所属する会社情報 |
Tool | 説明 | 読み取り専用 |
| 利用可能なモデルの一覧表示/検索 | 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 ヘルスチェック、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.