Loading ToolBench
Advanced MCP Server for Odoo with Multiple Transport Support (STDIO, SSE, HTTP)
The Odoo MCP server has 11 tools with a mix of well-defined and problematic definitions. Strengths: most tools have descriptions and visible schemas with type information; domain-specific naming is clear (search, read, create, write, unlink, execute). Critical weaknesses: (1) Parameter descriptions are often missing required constraints (e.g., `search` accepts 'multiple formats' for domain but lacks explicit enum/pattern guidance), (2) No output schemas documented for any tool, (3) Two tools (`execute` and `call_model_method`) are dangerously generic without safeguards, (4) Error handling is mentioned only at the tool registration level but not operationalized, (5) The `document_pattern` tool has an unusual write purpose (updating COOKBOOK.md) that conflates agent learning with API manipulation. The rubric requires 'output schema documented' (100% of A+ tools have this), 'every parameter needs a description' (failing here), and 'error guidance' (missing). Average per-tool score of 58 reflects solid naming and partial schemas, but significant gaps in parameter documentation, output specs, and error guidance.
Call a specific model method with a flexible signature
Create a new record in an Odoo model
Document a learned pattern in the COOKBOOK.md after successful discovery
Execute an arbitrary method on an Odoo model
Get all fields for an Odoo model
List all available Odoo models in the system
Read specific records by IDs from an Odoo model
No output schemas documented for any of 11 tools. Rubric requires '100% of A+ tools have documented return types.' LLMs cannot plan downstream calls or extract data without knowing response structure.
Two generic, high-privilege tools (`execute` and `call_model_method`) accept arbitrary method names and arguments with no allowlist, validation, or safeguards. Pattern:tool-composition requires each tool to do exactly one thing; these do everything. Pattern:secret-injection and pattern:tool-gateway require sanitization against injection attacks.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 13 | - | v1 |
Read the Learned Patterns section from COOKBOOK.md
Search for records in an Odoo model with flexible domain support
Delete records from an Odoo model
Update existing records in an Odoo model
Parameter descriptions lack actionable constraints. The `search` tool's 'domain' parameter says it accepts 'multiple formats' but does not show enum values, patterns, or examples of each format. LLMs cannot validate inputs without explicit constraints.
No error handling or recovery guidance in tool definitions. If a search fails, if a create violates model constraints, if unlink cascades unexpectedly, tools do not guide the LLM on what to do next. Pattern:recovery-guide requires error responses to tell the LLM what to do next.
Destructive tool (`unlink`) has no confirmation or dry-run option. Pattern:confirmation-request requires irreversible operations to support a confirm_before_execute step to prevent catastrophic errors.
`document_pattern` and `read_cookbook` are out-of-scope for an Odoo API server. They mutate local files and provide local knowledge management, conflating Odoo RPC with agent learning. These should be separate from the core Odoo tool set.
No pagination or result limiting documented in schemas for tools that return multiple records (search, list_models). Pattern:paginated-result requires page/offset/limit parameters and total counts to prevent context window exhaustion.