MCP Server for Odoo ERP — connect AI assistants to Odoo via XML-RPC
Server has 8 tools with consistent naming (verb_noun pattern: search_, read_, create_, update_, delete_, get_). All tools have descriptions (avg ~80 chars, baseline 194). Input schemas are present with type definitions and parameter descriptions. However, output schemas are not explicitly documented in the visible code, only inferred from result classes. Error handling exists but lacks actionable recovery guidance. No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels. Missing parameter constraints (enums, ranges) for critical fields like 'model' and 'domain'. Descriptions are functional but brief, lacking WHEN/WHY context that LLMs need for tool selection.
Create a new record in an Odoo model with the provided field values
Delete a record from an Odoo model by ID
Get available options for a selection field in an Odoo model
Get field definitions and metadata for an Odoo model
Get list of available Odoo models that the user has access to
Read records from an Odoo model by IDs and return their field values
Search for records in an Odoo model using domain filters and return matching record IDs
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite explicit risk levels. create_record, update_record, delete_record are marked WRITE/DESTRUCTIVE but lack MCP annotations to signal this to clients.
Output schemas not documented in visible code. Result classes (SearchResult, CreateResult, etc.) exist but their field definitions are not shown. LLMs cannot plan downstream calls without knowing what fields are returned.
Parameter 'model' (string) lacks enum constraint or validation guidance. Odoo model names are from a known set (res.partner, sale.order, etc.). Free-form strings invite hallucinated model names. Should reference get_models() or provide enum.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | <=2025-11-25 | v2 |
Update an existing record in an Odoo model with new field values
Descriptions lack WHEN/WHY context. E.g., 'Search for records in an Odoo model' does not explain when to use search_records vs read_records, or what domain syntax is expected. Descriptions should guide tool selection and usage.
Error handling visible in code (AccessControlError, ValidationError, NotFoundError) but error responses not documented. No guidance on retryability, user-fixable vs fatal, or recovery steps. Errors should tell LLM what to do next.