MCP for Claude & ChatGPT

Write permissions

odoo_write_models

Destructive

Which Odoo models this workspace may write, and what each one allows: create, write, unlink, execute. action='get' returns one model's flags (all false when the model is not on the whitelist); 'list' returns the whitelist, or searches it with 'query' (an exact technical name returns only that model). Check the model you are creating or writing, not the models of its lines: lines sent as x2many commands inside that record ride its permission. Workspace admins also have 'save' (add a model or change its flags) and 'delete' (remove it: after that nothing in Tuqui can write to that model). 'pre_domain' narrows what may be touched (e.g. [["state","=","draft"]]); it is validated against your Odoo and the answer says how many records it matches. It scopes write, unlink and execute on existing records; it does NOT scope create, so never present a create grant as limited to some records. Do not add a line model to unblock a create. 'scoped': true in place of 'pre_domain' means only some existing records may be touched.

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": {
      "action": "<action>"
    },
    "name": "odoo_write_models"
  }
}

Input Schema

Name	Required	Description
`limit`	No
`model`	No	Odoo model technical name, e.g. 'sale.order'. Required except for 'list'.
`query`	No	On 'list': a model name or part of it. Without it, the whole whitelist.
`action`	Yes	REQUIRED. 'list' and 'get' read the whitelist; 'save' and 'delete' change it.
`offset`	No	On 'list': records to skip. Pass the previous page's 'next_offset'.
`can_write`	No	Allow updating records of this model.
`can_create`	No	Allow creating records of this model.
`can_unlink`	No	Allow deleting records of this model.
`pre_domain`	No	Odoo domain that narrows what may be written, e.g. [["state","=","draft"]]. Send an empty array with clear_pre_domain=true to remove it.
`can_execute`	No	Allow calling methods on this model.
`consent_token`	No	The approval a person gave for THIS call in Tuqui. Bound to these arguments and valid once.
`clear_pre_domain`	No	On 'save' of an existing model: remove the pre_domain entirely.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 6, 2026

changedInput schema / properties / action / enum

Previous value: -[
-  "list",
-  "get",
-  "save",
-  "delete"
-]New value: +[
+  "list",
+  "get"
+]

First observedNov 2, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Annotations declare destructiveHint=true and readOnlyHint=false; the description goes well beyond by explaining what delete actually destroys ('after that nothing in Tuqui can write to that model'), that save/delete require workspace admin, and that pre_domain scopes write/unlink/execute but not create, with an explicit warning never to present a create grant as record-limited. These are exactly the behavioral facts an agent needs before mutating permissions.

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

Conciseness4/5

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

Front-loaded with the core definition, then per-action behavior, then the critical pre_domain/create caveat. It is dense but nearly every clause carries a rule an agent could otherwise get wrong; the single unbroken block and the undefined 'scoped' reference are the only structural weak points.

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 12-parameter tool with no output schema, the description covers return shape for both read actions and the validation feedback for pre_domain, and it supplies the admin/consent context needed for the mutation path. The gap is the action enum, which admits only 'list' and 'get' while the description and field docs describe 'save' and 'delete' — an agent following the description may be blocked by the 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 92%, so the baseline is 3, and the description earns an upgrade by explaining pre_domain semantics the schema does not: it is validated against the caller's Odoo, the response reports the matching record count, and it does not scope create. It also distinguishes 'get' (false flags for non-whitelisted models) from 'list' with 'query'. The reference to "'scoped': true" names a field absent from the schema, which leaves that path slightly underspecified.

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

Purpose4/5

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

The opening sentence states the specific resource and scope: 'Which Odoo models this workspace may write, and what each one allows: create, write, unlink, execute.' This disambiguates it from the name's implication of writing records, and separates it in spirit from odoo_write/odoo_create. It never names a sibling tool explicitly, which keeps it just short of a 5.

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

Usage Guidelines4/5

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

Gives concrete usage rules: check the model you are creating or writing rather than its line models, and do not add a line model to unblock a create. These are real when/when-not constraints, but they are framed as policy rather than as routing to alternatives such as odoo_write or odoo_execute.

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

All MCP for Claude & ChatGPT tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.