odoo-safe-mcp

odoo_approval_status

Destructive

Check a pending Odoo write approval status; approved writes execute once and return the result, while rejected or expired requests leave Odoo unchanged.

Instructions

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.

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": {
      "intent_id": "<intent_id>"
    },
    "name": "odoo_approval_status"
  }
}

Input Schema

Name	Required	Description	Default
`intent_id`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv3.0.0Oct 22, 2026

TDQS

A3.5/5.0

Behavior4/5

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

Adds real value beyond the annotations by disclosing the one-shot side effect: an approved write is executed exactly once at check time and the result returned, while a rejected or expired intent leaves Odoo untouched. This makes the destructiveHint=true annotation concrete. It does not mention permissions, expiry timing, or whether repeated polling after execution is safe.

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?

Three short sentences, front-loaded with purpose followed immediately by the branching behavior; every sentence carries information about what happens on approval vs. rejection/expiry.

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

Completeness3/5

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

Return values are covered by the output schema, so omitting them is fine, and the approve/reject/expire branches are described. However, for a non-idempotent tool with a destructive side effect, the missing guidance on obtaining the intent_id and on the one-shot semantics of repeat calls leaves a meaningful gap.

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

Parameters2/5

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

Schema description coverage is 0% for the single required parameter intent_id, and the description does not explain where the intent_id comes from (presumably the write response) or its format. It refers to 'a write that is waiting' but never ties that to the parameter, so the agent gets no help from the prose.

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?

States a specific verb and resource: check the approval status of a pending write, and describes the two outcomes precisely. It is clearly distinct from the read-only siblings (odoo_search, odoo_read, odoo_count, etc.) without naming them explicitly.

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

Usage Guidelines3/5

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

'Check a write that is waiting for human approval' implies the trigger condition (a prior write returned a pending approval), but the description never says so explicitly, nor does it name an alternative tool or state when not to call this one.

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

Deploy Server