odoo-safe-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ODOO_DB | Yes | Odoo database name | |
| ODOO_URL | Yes | URL of your Odoo instance, e.g. https://your-company.odoo.com | |
| ODOO_API_KEY | Yes | Odoo user API key used to connect to Odoo | |
| ODOO_DRY_RUN | No | Set to true to test and simulate YELLOW and RED policies locally with zero risk to your database. | false |
| ODOO_USERNAME | Yes | Odoo username/email for the AI bot user | |
| ODOO_SAFE_GUARD_KEY | No | Optional Pro license key for guarded write access. Without it, the server runs in Strict Read-Only Mode. |
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 |
|---|---|
| odoo_searchA | Search Odoo records and return their fields (search_read). Read-only. Args: model: Technical model, e.g. 'res.partner', 'sale.order', 'account.move'. domain: Odoo domain, e.g. [["state", "=", "sale"], ["amount_total", ">", 1000]]. fields: Fields to return. Use odoo_describe_model to discover them; omit for all. limit: Max records (default 20, max 200). offset: Records to skip, for pagination. order: Sort, e.g. 'date_order desc'. |
| odoo_readB | Read specific Odoo records by id. Read-only. |
| odoo_countC | Count Odoo records matching a domain. Read-only. |
| odoo_aggregateA | Aggregate records (read_group): totals and counts grouped by fields. Read-only. Example: model='sale.order', groupby=['state'], fields=['amount_total:sum']. |
| odoo_describe_modelA | Describe a model's fields (label, type, relation, required, readonly). Use before writing. |
| odoo_list_modelsB | List installed business models (technical name and label), optionally filtered by text. Read-only. |
| odoo_execute_kwA | Safely execute any Odoo ORM method (execute_kw) through the firewall. Reads run immediately. Draft creations (sale.order, purchase.order, crm.lead) run under the guarded-draft policy. Critical operations (write, unlink, confirm, post...) wait for a human approval on Slack/Teams and are executed here only after a signed decision. Args: model: Odoo technical model name (e.g. 'sale.order', 'res.partner', 'account.move'). method: ORM method name (e.g. 'search_read', 'create', 'write', 'action_confirm'). args: Positional arguments (domains, record ids, value dictionaries). kwargs: Keyword arguments (e.g. {'fields': ['name'], 'limit': 10}). justification: One honest sentence on why (shown to the approver, marked as unverified). |
| odoo_approval_statusA | Check a write that is waiting for human approval. If it has been approved, it is executed now (once) and the result is returned. If rejected or expired, nothing is changed in Odoo. |
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
Dedicated read/search/count/aggregate and metadata tools are clearly separated, and execute_kw is framed as the generic write/ORM path. Some overlap remains because execute_kw can also perform reads and approval_status both checks and may execute a pending write, but the descriptions make intended use fairly clear.
All names use the odoo_ prefix and snake_case, with predictable verb/resource ordering in describe_model, list_models, approval_status, and execute_kw. A few names are verb-only (search, read, count, aggregate) rather than full verb_noun, but the set remains readable and consistent.
Eight tools is well within the appropriate range for a general-purpose Odoo server. The split between read helpers, metadata discovery, approval handling, and generic execution is purposeful and each tool earns its place.
The surface covers discovery, querying, aggregation, and writes through execute_kw, including an approval workflow for critical operations. There are minor gaps such as no explicit pending-approval listing and CRUD being indirect via execute_kw, but the core lifecycle is reachable.