The Odoo MCP server has 11 tools with complete input schemas and descriptions, but inconsistent quality across dimensions. Naming is clear and action-oriented (search_*, read_*, create_*, update_*, delete_*, count_*, get_*). Descriptions are present for all tools and most parameters, though some are brief. Output schemas are not documented in the visible source code, responses are wrapped in {success, data/error} but the structure of 'data' for each tool is inferred from Odoo RPC docs, not declared. Error handling returns structured {success, error} tuples but lacks recovery guidance (no actionable next steps for LLMs). Parameter descriptions are generally adequate but some lack format/constraint details. The execute_method tool is dangerously generic, it accepts any Odoo method on any model with arbitrary args/kwargs, creating a security and composability risk. Tools are well-separated (no 'and' in names) and follow verb_noun convention. Pagination is handled via limit/offset with clear defaults. No tool accepts passwords or secrets as parameters (good). However, credentials are required as environment variables, which is correct for server-side injection, but the tool error messages reference 'Check credentials' without providing remediation steps.

• Remove or replace the execute_method tool. It is too generic and unsafe. Instead, provide specific, documented method wrappers for common workflows (e.g., action_confirm for sales orders, action_validate for invoices). Each wrapper should have a clear name, bounded input, and documented output.
• Document the output schema for every tool. For each tool, explicitly state what fields are in the response. E.g., 'search_records returns {success: bool, data: [int]} on success.' Use a schema definition language or JSON Schema inline in the tool registration.
• Add recovery guidance to all error responses. When a tool fails, include a suggested next step. E.g., 'Authentication failed. Check credentials. If correct, the Odoo instance may be unreachable.' instead of just 'Authentication failed.'
• Implement a confirmation step for delete_record. Before deleting, return a confirmation prompt (input_required in MRTR) that shows the record IDs and count, asking the LLM to confirm. This prevents accidental bulk deletions.
• Register tool annotations with FastMCP. Mark delete_record with destructiveHint=true, read-only tools with readOnlyHint=true, and idempotent tools with idempotentHint=true. This enables clients to surface appropriate UI warnings.
• Tighten parameter constraints. For 'domain', document valid operators (=, !=, <, >, <=, >=, in, not in, ilike, like, child_of). For 'limit', specify the valid range (e.g., 1 - 1000, default 10). For 'order', specify sort syntax ('field_name asc|desc, field2 asc|desc').