Moving from reading to writing changes the nature of the tool: a wrong answer can be corrected, an applied write stays. No write permission is therefore granted by default.

What really bounds a write

Your permissions are the only server-side barrier

On every call, Aidoo checks that your key carries the required permission, that the model and fields are not blocked, and that the tool only calls the Odoo method bound to it. These checks run server-side: the assistant cannot bypass them. Everything else depends on your client and your attention.

Approval in the conversation. Claude or ChatGPT shows you the call and its arguments, and waits for your consent. It is your best checkpoint on the values, but it belongs to the client: set to Always allow, it disappears. See Connecting with Claude.

Hints, as a quality guardrail. If the target model carries a hint, the tool returns your instructions to the assistant instead of writing, and asks it to revisit its values. That is what makes a rule such as "every activity must be assigned to the customer's account manager, never to the current user" stick.

This steers the assistant, it does not constrain it

Returning hints lives in the MCP tool, not in the server: the assistant is the one deciding to confirm. Rely on it for correct values, never as a security barrier. What bounds the possible is permissions and model blocking.

aidoo_create

Creates one or several records.

Single: model + values
Batch: model + values_list, a list of dictionaries

In batch mode, everything goes out in one Odoo call. Faster, and above all more consistent: Odoo applies its constraints across the whole set.

Create the following three contacts in Odoo: Mary Dubois ([email protected]), Paul Martin ([email protected]) and Sophie Bernard ([email protected]), all attached to the company Example Ltd.

aidoo_write

Updates existing records.

Single: ids + values, the same values for every identifier
Batch: batch, a list of {ids, values}, each group gets its own values

Batch mode returns per-group detail: if the third one fails, you know which and why, and the first two remain applied.

Archive rather than delete

Setting active to false removes the record from views without destroying information or breaking the documents that reference it. In virtually every case, that is the right answer to "delete this contact".

aidoo_workflow

Triggers an Odoo business action: the buttons on your screens. Confirm a quotation, validate an invoice, receive a transfer.

Parameters: model, ids, action. Only methods prefixed action_ or button_ are accepted; the server rejects everything else.

Confirm quotation S00042.

The benefit over aidoo_write: the action triggers all the associated Odoo logic, accounting entries, stock moves, sequences, emails. Editing the state field by hand would do none of that and would leave your database inconsistent.

Never force a status through a direct write

If the assistant offers to set state to sale with aidoo_write, decline and ask for the business action. A quotation "confirmed" without the associated entries is an accounting time bomb.

aidoo_execute

Calls an arbitrary Odoo method: the escape hatch for what the other tools do not cover.

Parameters: model, method, args, kwargs.

Methods that would duplicate a dedicated tool are blocked: create, write, unlink, read, search_read, read_group, fields_get, export_data, load, import_data. Otherwise a key holding execute could work around the absence of create or delete.

It is the most powerful tool in the catalogue. It deserves a conscious decision, not a box ticked "just in case".

aidoo_delete

Deletes permanently (unlink). No recycle bin, no undo.

The one operation with no way back

Odoo often refuses to delete a record referenced elsewhere: that is a protection, not a bug. When it accepts, the information is gone. Keep this permission closed in production, and open it briefly for an identified cleanup operation.

Opening up writing without taking risks

Start on the staging environment

If you have a copy of your database, enable create and write on the staging environment only. Permissions are set separately per environment.

Write your business rules into the hints

Before opening up writing, document your conventions in the model's hint: mandatory fields, forbidden values, who must be assigned. These instructions are injected on every write attempt, before execution.

See Hints and learning.

Open model by model, not wholesale

Block sensitive models, accounting entries, payroll, users, even when the write permission is granted. Model blocking applies before the permission.

Read the log during the first week

The request log shows every write: who, what, when, with which values. It is the best way to see what the assistant actually does, before widening its scope.

Diagnostics

"Permission create is required"

The permission is not granted to your key on this environment. It is set under API keys.

Aidoo API keys page: one row per key, with its user, prefix, permissions and an Edit button. — Each key carries its own permissions, editable at any time.

If you cannot grant it, a saved workflow can perform the operation: validated once at creation, it then runs with the workflow permission.

"Access Denied" on the Odoo side

The Aidoo permission is there, but your Odoo account is not allowed to write on that model. The fix is in Odoo, not in Aidoo: add the missing group to your account.

The write succeeded but nothing changed in Odoo

Check the active company and your view's filters. A record created on another company does not appear on the current screen.

The assistant loops on a confirmation request

The model's hint contains an instruction the assistant cannot satisfy: a mandatory value it does not have, for instance. Open the hint and check it is applicable; it is often a rule written for an edge case and applied to everything.

Next step

Hints and learning: encoding your business rules
Security & permissions: blocking models and fields