Odoo MCP by bancada

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavior: it performs no Odoo operation at all, only reads connector-level usage, and the reported window is 'este mes'. That scoping detail is useful context beyond the annotations.

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

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

Front-loaded statement of what is measured, followed by the not-Odoo caveat and then illustrative user questions. Three sentences carry little waste, though the quoted example phrasings are somewhat redundant with the opening sentence.

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

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

With an output schema present, return values need not be explained. Given zero parameters and read-only annotations, the description covers everything an agent needs: what is counted, the monthly window, and that no Odoo call is involved.

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

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

The tool takes zero parameters, so per the baseline there is nothing for the description to disambiguate. The description correctly adds no parameter talk, which is appropriate for a no-argument tool.

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

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

States a specific verb and resource: reports how many Odoo MCP connector calls have been consumed and how many remain this month. It also explicitly separates itself from the odoo_* siblings by declaring 'No toca Odoo — solo consulta el uso del propio conector', so an agent can route correctly without opening any schema.

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

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

Gives clear context for use: answer '¿cuánto llevo gastado?' or '¿cuánto me queda?' directly, without first performing an operation on Odoo. It does not name set exclusions or point at a specific alternative tool, but the scope of intended questions is unambiguous.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false, which is consistent with discarding a pending action. The description adds the semantic context that the user declined, but does not say what happens to the discarded action, whether it is reversible, or whether the pending code becomes invalid.

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

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

A single short sentence with the trigger condition front-loaded and zero filler. Every element earns its place.

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

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

With an output schema present and full parameter documentation, the description only needs to convey intent and trigger. It does so adequately for a one-parameter tool, though the relationship to odoo_confirm could be made explicit.

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

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

Schema description coverage is 100% and the single 'code' parameter is already documented as the pending action's identifier. The description adds no syntax, format, or sourcing detail beyond the schema.

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

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

States a specific verb (descarta) and resource (acción pendiente de confirmación), making the operation unmistakable. It does not name the sibling odoo_confirm, so the sibling differentiation is only implicit via the 'user said no' condition.

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

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

The parenthetical 'el usuario ha dicho que no' gives an explicit triggering condition for when to call this tool rather than confirm. It stops short of naming odoo_confirm as the alternative, so no explicit exclusion is provided.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the bar is lower, and the description still adds two valuable non-annotation facts: it requires explicit human confirmation in chat, and the pending action expires after 30 minutes. It does not say what happens if the code is invalid or expired (error behavior), which keeps it from a 5.

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

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

Three short sentences, zero filler, with the core action stated first and the critical confirmation constraint immediately after. Every sentence earns its place.

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

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

For a destructive two-phase confirmation tool with an output schema and covering annotations, the description supplies the essential missing piece — the human-confirmation requirement and the 30-minute TTL. Only the failure/expiry error behavior is left unstated, a minor gap.

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

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

With a single parameter at 100% schema description coverage ('Código de la acción pendiente (6 caracteres)'), the schema fully documents the input and the description adds nothing about it. Baseline 3 is appropriate when the schema does all the work.

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

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

The description states a specific verb+resource: it executes a write that was left pending confirmation ('Ejecuta una escritura que quedó pendiente de confirmación'). This clearly differentiates it from the generic write/execute siblings, though it never names a sibling (e.g. odoo_cancel) to sharpen the contrast.

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

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

It gives an explicit and forceful when-to-use ('LLÁMALA SOLO cuando el usuario haya confirmado explícitamente en el chat esa acción concreta') plus a when-not ('nunca por iniciativa propia'), which is exactly the gating an agent needs for a two-phase commit. It stops short of naming the rejection alternative (odoo_cancel), so it isn't fully complete on alternatives.

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

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

Annotations only declare readOnlyHint=false and destructiveHint=false. The description adds substantive behavioral context the annotations lack: the returned payload {model, id} and the two-step confirmation flow where a pending code may come back instead of a created record, requiring odoo_confirm. It does not mention permissions or whether the create is reversible.

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

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

Three short front-loaded sentences: what it does, what it returns, and the conditional next step. No filler, and the most important routing information (the confirmation branch) is not buried.

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

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

An output schema exists, so return-value documentation is not required, yet the description still flags the pending-code case, which is the key edge behavior. With annotations covering the safety profile and a complete schema, the definition is nearly self-sufficient; only permission/error semantics are unaddressed.

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

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

Schema description coverage is 100%, so both parameters (model, values) are already documented in the schema. The description adds no syntax or format guidance for 'values' beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb and resource ('Crea un registro') and notes the return payload shape {model, id}, which is enough to distinguish it from read/write siblings. It never explicitly contrasts itself with odoo_write, but 'create' vs 'write' is unambiguous for an agent.

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

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

Gives a concrete routing rule: if the account requires write confirmation and a pending code is returned, ask the user and call odoo_confirm. That is a real when-to-use-this-vs-sibling instruction, though it only covers the confirmation branch and says nothing about when to prefer this over odoo_write for existing records.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, and the description adds genuinely new behavioral context: the confirmation flow that returns a pending code and the required hand-off to odoo_confirm. It stops short of saying what gets mutated or whether calls are reversible, but the confirmation disclosure is valuable beyond the annotations.

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

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

Two tight sentences with the core action front-loaded and the confirmation caveat second. No filler, though the parenthetical examples are the only place scope is clarified.

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

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

With an output schema present and annotations covering safety, the description needn't explain return values; it supplies the key non-obvious behavior (pending-code confirmation). The remaining gap is guidance on preferring specific CRUD siblings over this generic executor.

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

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

Schema description coverage is 100%, so args/kwargs/model/method are already documented in the schema; the description only reinforces 'method' via examples. Baseline 3 is appropriate since the schema does the heavy lifting and the description adds no format or constraint detail.

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

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

States a concrete verb and resource ('llama cualquier método del modelo') and grounds it with examples (confirmar pedidos, validar facturas). It is clearly the generic method-invocation escape hatch, but it never contrasts itself with the specific CRUD siblings (odoo_write, odoo_create, odoo_unlink), so an agent must infer when the generic path is preferred.

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

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

Gives one real routing rule: if the account returns a pending code, ask the user and use odoo_confirm. However, it offers no guidance on when to use this generic executor versus the dedicated odoo_write/odoo_create/odoo_unlink tools, which is the primary ambiguity for this sibling set.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that - no note about what the field metadata contains, whether it is cached, or how it relates to model discovery.

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

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

A single short sentence with zero filler, front-loading the action and resource. It is efficient, though its brevity borders on under-specification rather than true conciseness.

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

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

An output schema exists, so return values need not be described, and annotations cover the safety profile. What remains missing is sibling differentiation and any usage context, leaving the definition minimally viable but not complete for the tool's role in a 12-tool suite.

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

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

Schema description coverage is 100%, so both parameters ('model' and 'attributes') are documented in the schema itself. The description adds no syntax or format detail beyond what the schema provides, making the baseline 3 appropriate.

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

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

The description names a specific verb ('Inspecciona') and resource ('los campos de un modelo'), so the agent knows it retrieves field metadata for a given model. However, it offers no differentiation from the sibling odoo_list_models, which an agent could easily confuse with it.

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

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

There is no guidance on when to use this tool versus alternatives such as odoo_list_models or odoo_read, nor any mention of prerequisites or context. The agent must infer usage entirely from the name.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered by structured data. The description contributes nothing further — no mention of pagination behavior, result volume, or what a "model" listing contains.

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

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

A single short sentence with no filler and the resource stated immediately. It is efficient, though it is so terse that it sacrifices useful detail rather than being an exemplar of well-structured completeness.

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

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

An output schema exists, so return values need not be explained, and the read-only annotations cover safety. What remains missing — when to prefer this over other discovery tools and how large the result set may be — is minor for such a simple tool, leaving it adequate but not rich.

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

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

Schema description coverage is 100%: 'limit' (max models, default 100, cap 500) and 'filter' (by technical name or label) are fully documented in the schema. The description adds no syntax or formatting detail beyond that, so the baseline 3 applies.

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

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

The description names a clear verb ("Descubre") and resource ("modelos disponibles en Odoo"), so an agent understands it enumerates the Odoo models. It does not, however, differentiate itself from adjacent metadata tools such as odoo_fields_get, which also probes model structure.

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

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

There is no explicit guidance on when to call this versus siblings like odoo_fields_get or odoo_execute. Usage (e.g. discovering a model before reading its fields) is left entirely to inference, and no exclusions are stated.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond that — no notes on batch-size limits, behavior for missing IDs, or permission requirements. It discloses no trait that the annotations and schema do not already provide.

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

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

It is a single short, front-loaded sentence with no filler, so it is not verbose. However, the sentence is essentially redundant with the title, so its brevity reflects under-specification rather than disciplined editing.

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

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

The tool is low-complexity, an output schema exists (so return values need no explanation), and the annotations cover safety — but the description still omits the one thing that matters most for selection: how this differs from odoo_search_read and when to prefer reading by ID over searching. It is not adequate to route an agent reliably.

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

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

Schema description coverage is 100%, so the schema already documents every parameter (ids, model, fields) with its own description and defaults. The prose adds no meaning on top of the schema, which establishes the baseline of 3 for high-coverage schemas.

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

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

The description "Lee registros por ID" is a near-verbatim restatement of the tool title "Read records by ID", with no added scope or distinguishing detail. It does not differentiate this tool from the sibling odoo_search_read, which is presumably the other way to retrieve records.

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

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

There is no when-to-use guidance, no mention of prerequisites (e.g. valid model names, record permissions), and no reference to alternatives such as odoo_search_read or odoo_fields_get. The agent must infer usage entirely from the name.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description usefully adds that records are not downloaded (a lightweight/aggregate behavior), but says nothing about permissions, the cost of large domains, or the shape of the returned count — though an output schema exists to cover returns.

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

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

A single five-word sentence with zero waste, front-loading the verb and the key differentiator ('sin descargarlos'). Nothing is padded or redundant.

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

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

With annotations covering safety and an output schema covering the return value, the description needs only to establish purpose and routing. It covers purpose minimally but omits the routing signal to odoo_search_read that an agent with 11 sibling Odoo tools would need, leaving the definition adequate rather than complete.

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

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

Schema description coverage is 100% — 'model' and 'domain' are both documented as 'Modelo Odoo.' and 'Dominio de búsqueda.' — so the schema carries parameter meaning. The description adds nothing about the model string format or domain filter syntax, so baseline 3 applies.

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

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

States a specific verb (count) and resource (records), and the clause 'sin descargarlos' implicitly separates it from odoo_search_read, which returns full records. It never names the sibling it is contrasted with, so the differentiation is inferable rather than explicit.

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

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

The phrase 'sin descargarlos' hints at the use case (need a number, not the data), but there is no explicit when-to-use statement or reference to odoo_search_read as the alternative for retrieving records. Usage must be inferred from the description's implication.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description is consistent with them. It adds one behavioral trait beyond the annotations — the combined search+read in a single call — but omits pagination defaults, limit behavior, and any auth or rate-limit context.

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

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

A single front-loaded sentence with no filler or redundancy. It is perhaps too terse for a six-parameter tool, but conciseness itself is strong.

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

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

With an output schema, full schema descriptions, and safety annotations, the description needn't explain returns or safety. However, it omits routing guidance against odoo_read and odoo_search_count, leaving a gap for an agent choosing among siblings.

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

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

Schema description coverage is 100%, with all six parameters documented in the schema (model, domain, fields, limit, offset, order). The description adds no parameter meaning beyond that, so the baseline of 3 applies.

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

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

States a specific verb+resource: 'Busca y lee registros de Odoo' (searches and reads Odoo records). The phrase 'en una sola llamada' implicitly distinguishes it from separate search/read siblings like odoo_read and odoo_search_count, but no sibling is named explicitly.

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

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

No when-to-use guidance, no conditions for choosing this over odoo_read or odoo_search_count, and no prerequisites or exclusions. The agent must infer usage from the name alone.

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

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

Annotations already declare destructiveHint=true, so 'DESTRUCTIVO' is largely redundant. However, the description adds genuinely new behavior: deletion is permanent and irreversible, and the tool may return a pending-confirmation code requiring a user prompt and a follow-up odoo_confirm call. That deferred-execution behavior is not visible in the annotations.

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

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

Three short sentences, front-loaded with the destructive action and its consequence, then the fallback flow. The 'DESTRUCTIVO' fragment duplicates the destructiveHint annotation and is the one piece of the text that does not earn its place.

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

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

An output schema exists, so return values need no explanation beyond the one exceptional case (pending code), which the description does cover. Combined with the destructive annotation and full schema coverage, an agent has what it needs to call this correctly; only edge cases like cascade effects on related records are unaddressed.

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

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

Schema description coverage is 100% for both parameters (ids and model), so the schema already carries the meaning. The description adds nothing about id format, model naming, or batching limits, so the baseline 3 applies.

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

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

States a specific verb and resource ('Elimina registros permanentemente') and makes the permanence explicit, which distinguishes it from reversible siblings like odoo_cancel. It does not directly contrast itself with odoo_write or odoo_search_read, so sibling differentiation is only partial.

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

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

Gives a concrete conditional flow: if the account requires confirmation the tool returns a pending code, in which case the agent should ask the user and call odoo_confirm. That names an alternative and the condition that selects it. There is no guidance on when deletion is inappropriate (e.g. records with dependencies), so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so safety is covered. The description adds valuable behavioral context: it discloses that a pending confirmation code may be returned and directs the agent to ask the user and call odoo_confirm, which is not captured by annotations.

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

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

Two sentences with no wasted words. The purpose is front-loaded, followed immediately by the critical confirmation workflow. Appropriately sized for the tool's complexity.

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

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

The description covers the core operation and the confirmation edge case. With an output schema present, return values need not be explained further. It does not mention permission requirements beyond confirmation or batch update behavior, but annotations and schema cover most other gaps.

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

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

Schema description coverage is 100%, and all three parameters (ids, model, values) are documented in the schema. The description adds no parameter-specific meaning beyond the schema, so the baseline score of 3 applies.

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

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

States a specific verb and resource: 'Actualiza registros existentes' (updates existing records). It distinguishes the tool from creation or deletion implicitly by specifying existing records, but does not explicitly contrast with siblings like odoo_create or odoo_unlink.

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

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

Provides a clear usage condition: if the account has write confirmation enabled, a pending code is returned, and the agent should ask the user and use odoo_confirm. It lacks explicit guidance on when to prefer odoo_write over other write-related siblings, but the confirmation workflow is well covered.

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