Loading ToolBench
Model Context Protocol server for Odoo integration. Supports both modern JSON-2 API (Odoo 19+) and legacy JSON-RPC (Odoo 18 and earlier). Provides tools for CRUD operations, workflow actions, report generation, and more.
The server exposes 22 well-named Odoo CRUD tools with consistent naming (verb_noun pattern: search, read, create, write, unlink, etc.). All tools have descriptions and input schemas are visible. However, schemas lack detailed constraints (enums, min/max bounds), parameter descriptions are generic, and output schemas are not documented. Error handling guidance is minimal. Tools mix concerns (e.g., execute is overly generic) and the generic 'context' object parameter on most tools is underdescribed. No enum constraints on fields like operation in check_access. The server would benefit from richer parameter validation, explicit result limits, and clearer error recovery paths.
Check access rights for a user on specific models and operations
Duplicate a record with optional field overrides
Create a new record with the given values and return the ID of the created record
Create multiple records in a single batch operation
Perform database cleanup operations to remove orphaned records and unused data
Perform deep cleanup of database including cascading deletions and constraint resolution
Get default field values for creating a new record
Generic 'context' parameter on 18+ tools lacks specificity. No description of what context keys are valid, when to use it, or expected structure. LLMs cannot determine when/how to construct context objects.
'execute' tool is overly generic (custom method invocation with arbitrary args/kwargs). Lacks enumeration of callable methods, parameter documentation, and guidance on which methods are safe vs. destructive. Invites hallucinated method names and unsafe operations.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract chaining IDs (e.g., what does create return? Is it {id: int} or {id: int, name: string, ...}?). Missing output structure breaks tool composition.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 39 | 2025-11-05+ | v1 |
Execute a custom method or function on a model
Generate a report from a report definition with optional parameters
Get metadata information about an Odoo model including fields, methods, and structure
List all available Odoo models in the instance
Get the name of records by their IDs
Search for records by name with optional domain and limit
Trigger onchange handlers to compute dependent field values
Read specific fields from records by their IDs with optional context
Read and group records by specified grouping fields with aggregation functions
Search for records in an Odoo model with optional domain filtering, limit, offset, order, and context parameters
Count records matching a search domain filter
Search for records and retrieve specified fields in a single operation with optional domain, fields, limit, offset, order, and context
Delete records by their IDs
Execute a workflow action on a record
Update records with the given values by their IDs
Destructive tools (unlink, database_cleanup, deep_cleanup) have no dry-run or confirmation step. Agents can trigger irreversible deletions without user approval. No error guidance on recovery.
Parameter constraints missing. 'limit' and 'offset' have no min/max bounds. 'operation' in check_access lacks enum (read|write|create|unlink). 'fields' arrays and 'domain' structures lack format documentation. LLMs pass unconstrained values.
Result limits not enforced or documented. search, search_read, read_group, and list_models have no stated defaults or caps. Returning 1000+ records wastes tokens and risks context exhaustion.
Error handling is silent. No documented recovery guidance. What does the LLM do if create() fails? Is it retryable? Should it ask the user? Should it call a different tool? Agents lack actionable error signals.