Loading ToolBench
Hybrid MCP server for Odoo ERP integration - supports both HTTP streaming and stdio modes for AI assistants
The server implements 9 Odoo-specific tools with HTTP transport and basic schema definitions. Tool naming follows verb_noun convention well (create_record, update_record, delete_record, get_record, search_records, execute_method, search_count, list_models, get_model_fields). Descriptions are present for all tools and most are reasonably informative (40-100 chars). However, several critical gaps limit the score: (1) Parameter descriptions are minimal, many lack context about expected formats, constraints, or dependencies. (2) Output schemas are entirely absent, the code explicitly removes outputSchema in _fix_tool_schema(), leaving LLMs unable to predict response structure. (3) Error handling is not documented, tools provide no recovery guidance or categorization. (4) Tool annotations (destructiveHint, readOnlyHint, idempotentHint) are not present despite the risk taxonomy (DESTRUCTIVE, WRITE, READ_ONLY) being implicitly tracked. (5) Parameter constraints are weak, search_records has min/max for limit but domain, order, and fields lack format documentation. (6) No mention of idempotency or retry behavior for write operations.
Create new records in Odoo
Delete records from Odoo (use with caution)
Execute custom methods on Odoo models
Get field definitions for a model
Get detailed information about specific records
Discover available models in your Odoo instance
Count records matching search criteria
Output schemas are explicitly deleted in _fix_tool_schema(). LLMs cannot predict response structure, field names, or types. This forces agents to infer output format from tool usage alone, increasing errors and context waste.
Parameter descriptions are sparse or missing format/constraint details. 'values' param in create_record is 'Dictionary of field values' with no guidance on required fields, data types, or field naming conventions. 'domain' in search_records lacks explanation of Odoo domain syntax. LLMs cannot construct valid requests without examples or constraints.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 49 | - | v1 |
Search for records in any Odoo model
Update existing records
Tool annotations (destructiveHint, readOnlyHint, idempotentHint) are not present. Risk taxonomy exists (DESTRUCTIVE, WRITE, READ_ONLY) but is not exposed to the LLM. Agents cannot distinguish safe vs. unsafe tools for retry logic or rollback planning.
No error handling documentation or recovery guidance. Tools provide no description of failure modes, validation errors, or next steps. An LLM encountering 'model not found' or 'invalid field name' has no indication of how to proceed or which tool to call next.
Parameter constraints are weak or missing. 'model' param accepts any string with no validation guidance. 'method' in execute_method lacks enum, pattern, or description of what methods are valid. 'domain' format (Odoo syntax) is not documented. LLMs will generate invalid inputs.
No pagination documented for search_records. Schema includes limit (max 1000) and offset, but result structure (total_count, has_more, next_offset) is not declared. LLMs cannot determine when to fetch next page or how many results exist.
Tool composition risk: execute_method is overloaded, accepts arbitrary methods, args, and kwargs. Agents could invoke private/dangerous methods. No safelist, validation, or description of what execute_method should be used for vs. specific tools like create_record.
Idempotency not declared. update_record and delete_record lack guidance on whether repeated calls with same params are safe (idempotent) or cause duplicate side effects. Agents retry on ambiguous failures, non-idempotent tools risk data corruption.