Odoo Developer Assistant MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| analyze_odoo_errorB | Analyze an Odoo error and suggest troubleshooting steps. Args: error_text: The error message or traceback to investigate. |
| inspect_odoo_moduleB | Inspect an Odoo addon manifest and check dependencies across multiple addons directories. Args: addon_path: Absolute path to the addon directory. addons_directories: Absolute paths to directories containing Odoo addons, such as standard, enterprise, and custom addons. |
| validate_odoo_manifestB | Validate an Odoo addon's manifest and declared data/demo files. Checks manifest syntax, important fields, and whether files declared in 'data' and 'demo' exist inside the addon directory. Args: addon_path: Absolute path to the Odoo addon directory. |
| analyze_odoo_xml_viewB | Analyze an Odoo XML data or view file for structural errors, suspicious references, and common issues. Args: xml_path: Absolute or relative path to the XML file. addon_path: Optional path to the containing addon directory to enforce sandboxed file access. |
| analyze_odoo_python_modelA | Analyze an Odoo Python model file for structural errors, missing attributes, decorator misconfigurations, and common mistakes using AST. Args: python_path: Absolute or relative path to the Python file. addon_path: Optional path to the containing addon directory to enforce sandboxed file access. |
| analyze_odoo_securityA | Analyze an Odoo security file (ir.model.access.csv or security XML data) for syntax mistakes, invalid headers, missing model prefixes, and misconfigured rules. Args: file_path: Absolute or relative path to the security file (.csv or .xml). addon_path: Optional path to the containing addon directory to enforce sandboxed file access. |
| check_odoo_addon_healthA | Run a comprehensive static health audit for an entire Odoo addon directory, evaluating the manifest, dependencies, XML views, Python models, and security rules. Args: addon_path: Absolute or relative path to the Odoo addon directory. addons_directories: Optional list of directory paths containing other addons to check module dependencies against. |
| verify_odoo_live_metadataA | Connect to a running Odoo instance via read-only XML-RPC to dynamically verify whether models, model fields, and external XML IDs exist in the active database. Args: url: URL of the Odoo instance (e.g. 'http://localhost:8069' or 'https://myodoo.example.com'). db: Name of the Odoo database. username: User login name / email. password: User password or API key. models_to_check: Optional list of model names to verify (e.g. ['sale.order', 'res.partner']). fields_to_check: Optional mapping of model names to lists of field names to verify (e.g. {'sale.order': ['partner_id', 'custom_ref']}). xml_ids_to_check: Optional list of external XML IDs to verify (e.g. ['base.group_user', 'sale.action_orders']). timeout: Network timeout in seconds (default: 10). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
The per-file analyzers (XML, Python, security) are clearly distinct, but inspect_odoo_module, validate_odoo_manifest, and check_odoo_addon_health all take the same addon_path argument and examine manifest/dependency concerns, with health subsuming the other two. An agent must read descriptions carefully to choose between inspect vs validate vs the full health audit.
Every tool follows a predictable verb_odoo_noun snake_case pattern (analyze_*, inspect_*, validate_*, check_*, verify_*) and uses 'odoo' as the consistent domain token. No mixed conventions or casing irregularities.
Eight tools is well within the sweet spot and each maps to a distinct artifact type or workflow stage (manifest, XML, Python, security, error, aggregate audit, live verification). Nothing feels padded or missing at the count level.
The surface covers static analysis across the major addon artifact types plus an aggregate health audit and live XML-RPC verification, which is strong lifecycle coverage for a developer assistant. Gaps remain: no scaffolding/module creation, no JS/OWL asset analysis, no automated fix application, and no i18n or test-related checks.