Skip to main content
Glama

MCP for Claude & ChatGPT

Run Odoo actions

odoo_execute
Destructive

Invoke an arbitrary public method on an Odoo model or set of records (e.g. action_confirm on sale.order, action_process on ai.video). Take the method from the model's operations (odoo_fields_get with with_operations=true), never from a field name or by analogy: a guessed one fails in Odoo. The model must be on the workspace's write whitelist with can_execute=true. Internal methods (starting with ) and dedicated-tool methods (create, write, unlink, sudo, with_user, with_company, with_env, invalidate, flush) are always blocked, and so is messaging (message_post and family, WhatsApp sends): post with odoo_message_post. Hard limit of 200 ids per call. For @api.model methods, pass ids=[]. Default timeout is 300s; pass timeout (in seconds, max 600) for slower methods. On timeout the tool returns a structured error with code='timeout' instead of raising.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "model": "<model>",
      "method": "<method>"
    },
    "name": "odoo_execute"
  }
}

Input Schema

NameRequiredDescriptionDefault
idsNoRecord IDs to invoke the method on (max 200). Empty list for @api.model methods.
modelYesOdoo model technical name.
kwargsNoKeyword arguments forwarded to the method.
methodYesPublic method name (no underscore prefix).
contextNoOptional Odoo context.
timeoutNoPer-call timeout in seconds. Default 300, hard cap 600. Bump it for methods that take longer (transcription, batch posting). Returns code='timeout' if exceeded.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedInput schema / properties / confirm
      Removed value: -{
      -  "default": false,
      -  "description": "Set to true to skip the preview and invoke. For the methods that take two turns it only invokes after the user replied to the preview (Tuqui's rule, not Odoo's).",
      -  "type": "boolean"
      -}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the destructive and open-world annotations, the description discloses blocked internal methods, blocked dedicated-tool methods, blocked messaging methods, the 200-id cap, and timeout behavior with a structured error code. This is exactly the behavioral context an agent needs for a potentially destructive generic executor.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but well organized, starting with the core action and examples before moving to sourcing rules, restrictions, limits, and timeout behavior. Every sentence carries operational value and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex and potentially destructive generic tool, the definition covers the key prerequisites, restrictions, limits, and timeout behavior. It does not explain what successful return values look like for arbitrary methods, which is a minor gap given the absence of an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful guidance for the method parameter by requiring it to come from odoo_fields_get operations. It also reinforces ids semantics for @api.model calls and timeout limits, though most parameter details are already present in the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: invoking an arbitrary public method on an Odoo model or record set, with concrete examples such as action_confirm on sale.order. It clearly distinguishes this generic execution tool from dedicated siblings like odoo_message_post, odoo_create, and odoo_write.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit sourcing guidance for the method parameter, requiring values from odoo_fields_get with with_operations=true and warning against guessing. It also names alternatives for blocked operations, especially messaging via odoo_message_post, and states the workspace whitelist prerequisite.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.