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

With no annotations provided, the description carries full burden. It explains measures format but does not disclose whether the operation is read-only, requires specific permissions, or any side effects. It mentions the legacy replacement but not other behavioral aspects.

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?

The description is succinct, front-loads the purpose, and includes practical param hints without fluff. Four short clauses cover purpose, legacy context, and key parameter guidance.

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 has 4 parameters and no annotations. The description covers core aggregation and a date example, but omits domain usage, read-only confirmation, and edge cases. The presence of an output schema partially compensates, but overall it's minimal.

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 schema has zero descriptions, so the description's notes on `measures` as a JSON list and the date format example are valuable. However, it does not explain `domain` or `groupby` formats, leaving some parameters underdocumented.

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 clearly states the tool computes count and sum(s) grouped by a field ('Nombre et somme(s) par groupby'). It distinguishes itself by mentioning it replaces read_group and from siblings like odoo_count and odoo_search. However, it lacks an explicit verb like 'aggregates', using a nominal phrase.

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 description gives context that it replaces read_group, which is helpful for Odoo users. It implies usage for grouped aggregation but doesn't explicitly state when to use it over odoo_count or odoo_search, nor does it mention exclusions or prerequisites.

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?

Even though annotations are absent, the description discloses important behavior: credentials are kept in server memory only (never on disk), db is auto-deduced from subdomain when omitted, and allow_write should remain False. This adds meaningful context about credential safety and default behavior.

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?

The description is three concise sentences, front-loaded with the main purpose ('Se connecter'). Every sentence adds value: usage order, security behavior, and parameter guidance. No redundancy or filler.

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?

Given that an output schema exists, the description needn't explain return values. It covers essential context: first-call requirement, credential handling, db fallback, and allow_write recommendation. It's adequate for a connection tool, though it doesn't mention potential outcomes like session tokens or error conditions, which the output schema likely handles.

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 schema description coverage at 0%, the description must compensate. It clarifies the `db` parameter (deduced from subdomain if omitted) and `allow_write` (should be False). However, url, username, and api_key are left to their self-evident names, so coverage is partial.

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 begins with 'Se connecter' (Connect), clearly stating the tool's purpose as establishing a connection. The phrase 'a appeler en premier' (to call first) distinguishes it from all sibling odoo tools by establishing its role as the mandatory initial call.

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 description explicitly states when to use this tool: first, before any other odoo operation. It also names an alternative for write permissions ('voir odoo_enable_write'), giving clear guidance on when not to set allow_write to True.

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?

With no annotations provided, the description carries full responsibility for behavioral disclosure. It merely states the count action, without explaining return format, domain syntax, error behavior, or whether it is a read-only operation. It adds minimal value beyond the tool's name.

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?

The description is a single concise sentence with no wasted words. It is appropriately sized for a simple count operation and is front-loaded with the primary action and object.

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?

Despite the existence of an output schema, the description is incomplete for effective tool invocation. It fails to document the format of the domain parameter (essential for use), omits any usage context, and provides no behavioral details that would help an agent decide when to use this tool versus siblings like odoo_aggregate.

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 0%, so the description must compensate. It mentions 'domain' as a filter but does not explain its syntax or relationship to the model parameter. The model parameter is not described at all. The description provides only vague semantic context for the domain parameter.

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 'Compter les enregistrements correspondant au domaine' clearly states it counts records matching a domain, combining a specific verb and resource. This distinguishes it from siblings like odoo_search or odoo_read, which retrieve records rather than counting them.

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. It does not mention that it should be used instead of odoo_search or odoo_aggregate when only a count is needed, nor does it provide any exclusions or prerequisites.

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?

With no annotations, the description carries the behavioral burden. It discloses a critical behavior: operation is blocked until odoo_enable_write is invoked. It also provides an example of the values format. It doesn't mention success/return behavior, but an output schema exists, reducing the need to describe return values.

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 concise sentences, front-loaded with the purpose and example, followed by the prerequisite. No filler or redundant content.

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 purpose, parameter example, and prerequisite. With an output schema present, it needn't explain return values. Missing details like model naming conventions or error handling are minor given the simplicity of the tool.

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 coverage is 0%, so the description must compensate. It explains `values` as a JSON object with a concrete example, which adds meaning beyond the bare string type. The `model` parameter is not described, but its purpose is obvious from the name and context.

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 clearly states 'Créer un enregistrement' (create a record) with a verb and resource, and distinguishes itself from sibling write/update/delete tools by specifying creation. The example '{"name":"ACME"}' further clarifies the action.

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 description gives clear context: it creates a record and requires odoo_enable_write to have been called first. However, it does not explicitly mention alternatives like odoo_write or odoo_unlink, so it lacks explicit exclusions or 'when-not' guidance.

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?

With no annotations, the description carries the burden and does a good job: it discloses mutation/replacement behavior, live recalculation of charts, validation before writing (including read-only mode), and auto-creation of `rubrique`. It does not mention permissions or failure modes, but the disclosed behaviors are substantial and accurate.

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?

The description is compact and front-loaded with the purpose, then quickly gives an illustrative JSON payload and key behavioral constraints. Every sentence adds value, and the structure is easy to scan.

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 tool with a complex JSON parameter and an output schema, the description covers the essential format, replacement semantics, and validation behavior. Minor gaps (e.g., `sous_titre` semantics, exact return value) are partially offset by the output schema and the detailed example.

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 0%, so the description compensates well. It provides a detailed JSON schema for `graphiques`, explains value domains for `type`, `mesure`, and date grouping, and clarifies `dashboard_id` (replacement) and `rubrique` (auto-created). `sous_titre` is not explained, but the main complex parameters are covered.

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 uses a specific verb+resource ('Creer ... un tableau de bord') and clarifies that it can also replace an existing dashboard via `dashboard_id`. It clearly distinguishes this tool from dashboard listing/inspection siblings and generic Odoo create tools.

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 description gives clear operational context: create or replace a dashboard, with validation happening before write even in read-only mode. It does not explicitly name alternatives or exclusions, but the replacement and validation notes provide strong usage guidance.

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?

No annotations are provided, so the description carries full responsibility for disclosing behavior. It mentions the output is 'en clair' (plain language), but it does not state whether the operation is read-only, what happens if the dashboard_id is invalid, or any permission requirements. This is a significant gap for a tool with no annotation support.

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?

The description is a single, front-loaded sentence that immediately states the verb and resource. It is concise and contains no filler, earning a high score for efficiency.

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 only one parameter and an output schema present, the description provides a basic but adequate overview. However, it lacks context about prerequisites (e.g., the dashboard must exist) and what the plain-language output actually looks like. It is minimally complete for a simple inspection tool but leaves room for improvement.

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 0%, and the description does not mention the dashboard_id parameter at all. While the schema's title 'Dashboard Id' gives basic meaning, the description fails to explain how the parameter relates to the tool's function or provide any additional context about selecting a specific dashboard.

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 clearly states the tool describes a dashboard's content (charts, sources, filters) in plain language. The verb 'décrire' and resource 'tableau de bord' are specific. It implicitly distinguishes from siblings like odoo_dashboard_list and odoo_dashboard_create, though it does not explicitly name alternatives.

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 description offers no guidance on when to use this tool versus alternatives such as odoo_dashboard_list or odoo_dashboard_create. The usage context is only implied from the word 'inspect' in the tool name, not spelled out in the description.

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?

With no annotations, the description carries the full burden, but it only states the basic listing behavior. It adds the detail that sections are included, which is useful, yet it does not mention whether an active connection is required, how results are ordered, or any potential limitations. The read-only nature is implied by 'Lister' but not explicitly disclosed.

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?

The description is a single, front-loaded sentence with no redundant wording. Every word contributes to the tool's purpose, making it appropriately concise and easy to parse.

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 simple list tool with no parameters and an output schema, the description covers the core purpose, but it omits usage guidance relative to sibling tools and any caveats about scope or prerequisites. It is minimally viable but lacks context that would help an agent choose it confidently.

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 has zero parameters, so the schema already fully defines the input. The description correctly implies that no arguments are needed, and no additional parameter explanation is required. This matches the baseline for a parameterless 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?

The description clearly states the verb ('Lister' / list) and the resource ('tableaux de bord' / dashboards) plus their sections, which gives it clear scope. This distinguishes it from sibling tools like odoo_dashboard_inspect and odoo_dashboard_create, which imply inspection and creation respectively.

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 description provides no explicit guidance on when to use this tool versus alternatives such as odoo_dashboard_inspect or odoo_dashboard_create. Usage is only implied by the verb 'Lister' and the resource name, so an agent receives no context about appropriate scenarios or exclusions.

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?

With no annotations, the description discloses several behavioral traits: it audits multiple models, respects a per-model/per-field limit, signals truncation, and can neutralize addresses when corriger=true. However, it omits details about what defines a 'real address', whether correction is permanent, or any permission requirements. The bar is higher without annotations, and this is only partially met.

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?

The description is two sentences, front-loads the purpose, and uses no filler. Every sentence adds meaningful information, making it concise and well-structured.

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 key elements: models, limit, correction option, and truncation signal. However, it leaves ambiguous what exactly constitutes a 'real address' (physical vs. email) and which specific fields are checked. Since output schema exists, return format is not penalized. The gaps are notable for a tool that is meant to audit data.

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 coverage is 0%, but the description fully explains both parameters: 'au plus limit enregistrements par modele et par champ' defines limit, and 'Avec corriger, les adresses trouvees sont neutralisees' defines corriger. This exceeds the baseline and compensates completely for the lack of schema descriptions.

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 clearly states the tool's purpose: 'Verifier qu'aucune adresse reelle ne subsiste avant de demontrer' (verify no real address remains before demonstrating). It lists the specific models audited (res.partner, hr.employee, crm.lead, res.users), which distinguishes it from sibling Odoo tools that handle CRUD, search, or other operations.

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 'avant de demontrer' (before demonstrating) gives a clear situational context for when to use this tool. It doesn't explicitly name alternatives or exclusion conditions, but its distinct purpose relative to sibling tools implies a specific workflow niche.

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?

With no annotations, the description carries full behavioral responsibility. It discloses critical traits: demo bases are not neutralized (real emails sent), address rewriting details (left part preserved), domain must be unreachable, and real domains are refused. This goes beyond basic expectations and directly informs safe usage.

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?

The description is concise and front-loaded with the critical instruction, followed by essential safety warnings. Every sentence adds value, with no fluff or repetition of schema details. It is well-structured for quick comprehension.

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?

Given the tool is a safety toggle with two simple parameters, the description covers purpose, timing, side effects, parameter constraints, and usage restrictions. It is complete for an agent to correctly select and invoke the tool, and the output schema likely handles return values, so no further description is needed.

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 schema has 0% coverage in the description, but the description adds meaning for 'domaine' (must be unreachable, real domain refused) and implies 'actif' by saying 'Une fois actif' (once active). It does not explicitly define actif, but the boolean's purpose is clear from context. It compensates well for the schema's bare structure.

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 clearly states it is an email filter to activate before demo data generation, with a specific verb ('activer') and resource ('filet e-mail'). It explains the exact purpose—rewriting email addresses to a safe domain to prevent real emails—and distinguishes itself from sibling tools by focusing on this safety configuration.

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 description explicitly says 'a activer AVANT toute generation de donnees de demo' (to activate before any demo data generation), providing clear timing and context. It also warns about real email being sent if not activated, which is a strong usage signal. However, it does not mention alternatives or when not to use, so it is not a perfect 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?

With no annotations provided, the description fully carries the burden of behavioral disclosure. It discloses critical behavioral traits: the questionnaire must be presented verbatim including the preamble, missing answers must not be invented but signaled as hypotheses, and a plan must be validated before any writing. This is rich, specific guidance that goes far beyond a generic tool description.

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, purpose first, each sentence carries a distinct operational directive. There is no filler or redundancy; the description is economical and front-loaded.

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 provides a complete mini-workflow for the agent: present questionnaire, annotate assumptions, compose plan, validate before writing. Since an output schema exists, return values need not be described. For a zero-parameter tool, this is fully sufficient for correct usage.

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 has zero parameters, so the input schema is trivially complete. The description does not need to explain parameters, and the baseline for 0 parameters is 4. No parameter-related information is missing.

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 clearly identifies the tool as a qualification questionnaire for prospect demos, using a specific noun phrase and explicit instructions to present it as-is. This distinguishes it from sibling tools like odoo_demo_mode or odoo_presentation_guide, which serve different demo-related purposes.

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 explicitly states when to use this tool ('avant de batir une demo prospect') and provides a step-by-step workflow: present the questionnaire verbatim, flag missing answers as hypotheses, compose a plan, and get validation before writing. This is explicit and actionable, leaving no ambiguity about usage.

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?

No annotations are provided, so the description must disclose behavioral traits. It warns that deletions are irreversible and that user consent is required, which are key safety behaviors. It does not elaborate on the state change or persistence, but the warnings add valuable 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?

Two sentences, front-loaded with the action and followed by a critical safety warning. Every word contributes; no fluff.

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 simple toggle with an output schema, the description covers the essential use case and safety warning. It lacks detail on what 'write' encompasses, but the tool name and siblings compensate. Acceptable for a tool of this complexity.

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 schema has one boolean parameter 'enable' with 0% description coverage. The description's 'Activer (ou couper)' directly maps to true/false, providing some semantic interpretation. However, it doesn't explain the default or the exact effects of each value beyond enabling/disabling writing.

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/action ('Activer/couper') on a specific resource ('l'ecriture'), clearly indicating this toggles write mode. It is distinguishable from sibling tools like odoo_write and odoo_unlink, though it does not explicitly name them.

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?

Explicitly states when to call: only after showing the user what will be modified and obtaining consent. This is a clear usage condition. No alternative tools are mentioned, but the safety context is strong.

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?

With no annotations, the description carries full burden. It discloses the read-only whitelist mechanism and names blocked write methods (create, write, unlink, etc.), providing critical safety context. It does not mention return format or post-enable side effects, but the core mutability guard is well covered.

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?

The description is two sentences, front-loaded with the purpose and followed by an essential safety constraint. There is zero redundant wording, making it optimally concise.

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 broad and low-level, yet the description covers only the read/write gating and omits parameter syntax, examples, and guidance on when to choose this generic tool over dedicated siblings. The presence of an output schema mitigates return-value uncertainty, but for such a flexible tool the description remains incomplete.

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 input schema has 0% description coverage, so the description must explain the parameters. It only implies model and method but gives no guidance on the expected format for args and kwargs, which are strings (likely JSON). This leaves parameter usage ambiguous and uncompensated.

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 clearly states that the tool calls any method of an Odoo model via raw execute_kw, distinguishing it from specialized sibling tools like odoo_read or odoo_write. The verb 'Appeler' and resource 'méthode d'un modèle' are specific and unambiguous.

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 explains that in read-only mode a client-side whitelist applies, and write methods remain blocked until odoo_enable_write is called. This gives clear context for using the tool, though it does not explicitly mention when to prefer dedicated tools over this raw interface.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals key behaviors: output format, relation flattening, default field selection, and critical overwrite refusal with a forced override flag (ecraser=true). This is substantial, non-obvious behavioral context that helps the agent avoid data loss and understand transformations.

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?

The description is two short sentences. The first sentence states the purpose and key behavior; the second discloses the overwrite guard. Every sentence earns its place, and the description is front-loaded with the most critical information.

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?

Given the tool's complexity (7 parameters, no annotations) and the presence of an output schema, the description covers the essential aspects of export behavior: file format, flattening, default fields, and overwrite protection. It does not detail the formatting of `domain` or `order`, but these are common in the Odoo ecosystem. The output schema likely covers return values, so the description is sufficiently complete for core usage, though some gaps remain.

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 schema has zero description coverage, so the description must compensate. It explains the `fields` parameter (defaults to current fields) and `ecraser` (overwrite flag), but the remaining five parameters (model, path, limit, order, domain) are not described. While names imply some meaning, the description does not provide sufficient context for an agent to construct valid values, especially for `domain` and `order` which may require specific syntax.

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 clearly states the tool exports a search to a local .xlsx/.csv file, using a specific verb and resource. It distinguishes itself from sibling tools like odoo_import_file (inverse operation) and odoo_search/odoo_read (which return data in-conversation rather than to a file).

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 description implies when to use this tool: when a search result needs to be saved as a local spreadsheet file. It provides context about flatting relations and default fields, but does not explicitly name alternatives or state when not to use it. Given the clear purpose and distinct behavior, the usage context is evident, though exclusions are not 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?

With no annotations, the description carries full burden. It discloses the default compact output format with an example, warns that field names change between versions, and notes that the detailed form exceeds 20,000 tokens. These are valuable behavioral traits beyond what the schema provides.

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?

The description is concise, with three sentences that front-load the purpose, then provide a format example and usage caveats. Every sentence adds value with no redundancy.

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?

Given the low schema coverage and lack of annotations, the description covers most important aspects: output format, version sensitivity, and token size warning. The existence of an output schema reduces the need to explain return values, but the unmentioned writable_only parameter keeps it from being fully 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 0%, so the description must compensate. It explains the purpose of name_contains (filter) and detail (only for labels/selection values), and model is implied by the tool name/title. However, the writable_only parameter is not mentioned at all, leaving a gap in parameter understanding.

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 the tool returns 'Champs d'un modele' (fields of a model), which clearly identifies the resource. It distinguishes this from siblings by noting it should be consulted before any write operation, implying it provides field metadata. However, it lacks an explicit verb like 'list' or 'get', so it's slightly less than 5.

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 description explicitly says to use this tool 'AVANT toute ecriture' (before any writing), providing clear timing context. It also gives practical tips for filtering with name_contains and for using detail=true only for specific cases. It doesn't name alternatives, but the guidance is clear enough to know when to invoke it.

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?

No annotations are provided, so the description must carry the safety burden. It discloses critical behaviors: filename is sanitized (only last component, no '../') and existing files are never overwritten. This is useful context beyond a simple 'download' statement, though it omits potential error conditions or permission requirements.

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 sentences convey the main action, id-finding guidance, and two important safety warnings without any unnecessary words. The description is front-loaded with the primary purpose and maintains high information density.

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 simple download tool with an output schema, the description covers the essential context: what it does, how to find the id, filename sanitization, and no-overwrite policy. It does not explain error scenarios or return format, but the output schema handles return values. It is reasonably complete given the tool's simplicity.

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 0%, so the description must compensate. It explains how to obtain attachment_id via odoo_search with a concrete domain, and the overwrite warning implies that 'path' refers to a directory. However, the 'path' parameter itself is never explicitly defined, leaving some ambiguity about its exact format or default behavior.

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 uses the specific verb 'Telecharger' (download) and names the resource 'piece jointe (ir.attachment)', clearly distinguishing it from sibling tools like odoo_read or odoo_search. It also explains how to locate the attachment via odoo_search, reinforcing its purpose.

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 clear context by instructing to find the attachment_id via odoo_search with an example domain, and warns about overwrite behavior. However, it does not explicitly state when to prefer this over alternatives like odoo_read or odoo_export_file, though the download intent is unmistakable.

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?

No annotations are provided, so the description carries the full burden. It discloses important behavioral traits: no volume limit, atomic per batch, check mode validates without writing, run mode imports, and mapping to 'id' makes imports re-runnable without duplicates. It could mention permissions or error handling, but the core side effects are covered.

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?

The description is well-structured with a clear first sentence stating purpose, followed by mode explanations and a mapping example. The mapping JSON is long but essential for understanding the parameter. No fluff, though it could be slightly more concise without losing value.

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 don't need elaboration. The description covers the import workflow, modes, mapping semantics, atomicity, and re-run safety, providing sufficient context for a complex import tool. Missing parameter details for sheet/header_row are minor 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 0%, so the description must compensate. It explains the 'mapping' parameter with a concrete example and describes 'mode' values, but it leaves 'path', 'sheet', 'batch_size', and 'header_row' largely unexplained. The compensation is partial, justifying a 3.

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 clearly states the tool imports a local .xlsx/.csv file, which is a specific verb+resource. It distinguishes from sibling tools like odoo_create/odoo_write by emphasizing file-based import from disk, and it outlines three distinct modes (inspect/check/run) that clarify its purpose.

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 description provides clear usage context by explaining the chaining of modes and the mapping format, but it doesn't explicitly mention when to use this tool instead of alternatives like odoo_upsert or odoo_create. It gives workflow guidance without exclusions, earning a 4.

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?

With no annotations, the description is the only source of behavioral info. It adds one useful detail: `pourquoi` is a business justification carried as-is into the report. However, it does not disclose what happens on invocation, side effects, or prerequisites, leaving the tool's behavior largely opaque.

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?

The description is brief and easy to scan, with no irrelevant content. However, its brevity under-specifies the tool, making it less of a well-structured concise description and more of a minimal placeholder.

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?

Despite having an output schema, the description fails to provide context needed for tool selection: no action, no usage scenario, no prerequisites or effects. For a tool with no annotations, this level of vagueness is critically incomplete.

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 coverage is 0%, so the description must compensate. It explains `pourquoi` as a business justification used verbatim in the report, which adds useful semantics. But `nom` is left entirely to its schema title, providing no additional meaning beyond a generic 'name'.

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 defines a 'chapter' as a work step in the journal but never states the action the tool performs (e.g., create, add). It reads as a restatement of the tool name rather than a clear functional verb+resource specification.

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 explicit guidance on when to use this tool versus siblings like odoo_journal_start or odoo_journal_note. The phrase 'les operations suivantes y sont rattachees' implies grouping but does not clarify the intended usage context or exclusions.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It says 'Consigner' (record), implying a write action, but doesn't specify whether it creates a new note, appends to an existing journal, overwrites, or requires a session/connection. There's no mention of side effects, permissions, or failure behavior.

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?

The description is concise and front-loaded with the core purpose. It's a single substantive sentence followed by a category enumeration. No superfluous content. Slight deduction for using backticks and not formatting the categories as a clean list, but overall it's efficient.

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 simple note-taking tool, the description captures the main purpose and gives category options. However, it omits important context: it doesn't mention that this likely appends to the current journal session (given sibling tools like odoo_journal_start and odoo_journal_chapter) or any prerequisites. It also doesn't describe the output or result of the operation, though an output schema exists. The tool is straightforward, but the description leaves gaps about the workflow integration.

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 schema has two parameters (texte, categorie) with 0% description coverage. The description adds meaning to 'categorie' by enumerating allowed values (note|decision|alerte), which is valuable. However, 'texte' is not described beyond its schema title 'Texte', and the description doesn't explain how the parameters are used together. Some parameter semantics are provided, but the description doesn't fully compensate for the lack of schema descriptions.

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 clearly states the tool's purpose: to record items that are not accounting entries but need to be explained to the client ('Consigner ce qui n'est pas une ecriture mais merite d'etre explique au client'). It names the resource (journal note) and gives specific examples (arbitrage, anomalie, limite, sujet ecarte). While it doesn't explicitly differentiate from sibling journal tools, the purpose is distinct enough to avoid confusion.

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 description implies when to use the tool: for non-entry explanations to the client. It also provides category values (note|decision|alerte) to guide content type. However, it doesn't state when not to use it or mention any alternatives, and there's no reference to how it relates to other journal tools.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It adds context about the report structure and the meaning of journal_path (a past session), but does not disclose whether the tool is read-only, side-effect-free, or what happens if no journal_path is provided. It also does not describe the output schema or error behavior, leaving several behavioral aspects unknown.

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?

The description is extremely concise, consisting of two short sentences. It front-loads the core purpose, then lists parameter meanings. Every word contributes value, and there is no redundant information. This is a model of efficient description writing.

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 has an output schema and sits among journal-related siblings (journal_start, journal_chapter), but the description does not explain how this tool relates to those, nor does it clarify the `path` parameter. It lacks essential context such as whether a journal session must be active, how to obtain a journal_path, or the structure of the output. For a report-generation tool with three parameters, this is insufficiently 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?

Since schema description coverage is 0%, the description must compensate. It explains the `format` parameter (html|markdown|both) and `journal_path` (session passée), which adds meaning beyond the raw schema. However, it completely omits the third parameter `path`, which has no description in the schema either, leaving one parameter undefined.

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 clearly states the tool generates an intervention report presentable to a client, with synthesis, step-by-step breakdown, and before/after details. It specifies the output type and content, which is more specific than a generic 'report' tool. However, it does not explicitly differentiate itself from sibling tools like odoo_journal_note or odoo_journal_chapter, leaving some ambiguity about its unique role.

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 description implies usage when a client-facing report is needed ('presentable au client') and explains the format options (html, markdown, both) and that journal_path refers to a past session. It does not explicitly state when not to use it or suggest alternative tools, so the guidance is partially implied rather than explicit.

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?

With no annotations provided, the description carries full burden. It discloses that the tool traces each write with the state before modification, enabling the report, and mentions that titre and objectif appear in the header. However, it doesn't mention side effects, required permissions, or how the journal is stored/closed, leaving some behavioral gaps.

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?

The description is three concise, front-loaded sentences with no filler. Each sentence contributes: purpose, process, and parameter roles. It is efficiently structured and easy to scan.

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 tool's purpose, timing, and the role of two parameters. It doesn't need to explain return values because an output schema exists. However, it omits prerequisites (e.g., connection state) and potential misuse scenarios, which could be more complete given the lack of annotations.

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 0%, so the description must compensate. It adds meaning to 'titre' and 'objectif' by stating they appear in the report header, but 'path' is not mentioned at all. Thus, two of three parameters are semantically enriched, but the unexplained path keeps this from being a strong score.

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 clearly states the tool's function: 'Ouvrir un journal d'intervention' (open an intervention journal) and specifies it must be used before any writes. It distinguishes itself from sibling journal tools (chapter, note, report) by establishing its role as the starting point.

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 description explicitly instructs to use the tool 'AVANT toute ecriture' (before any writing), giving a clear temporal context for when to invoke it. It doesn't explicitly name alternative tools but implies the sequencing among journal tools, which is sufficient for most usage scenarios.

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?

No annotations are provided, so the description must convey behavioral traits. It only says 'Lister les modèles disponibles,' with no mention of read-only status, side effects, pagination, or potential performance implications. This leaves the agent without safety or behavioral 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?

The description is a single, concise sentence that front-loads the key information and includes no filler. It is efficiently structured for a simple tool.

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?

While the tool appears simple and has an output schema, the description omits parameter semantics and usage context. It covers only the core purpose, leaving the agent to infer how to use limit and name_contains and when to choose this tool over 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?

The input schema includes two optional parameters (limit, name_contains) with defaults but no descriptions, and the description does not mention them at all. With 0% schema description coverage, the description fails to explain how these parameters affect results, though the field names are somewhat self-explanatory.

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 clear verb ('Lister') and resource ('les modèles disponibles') with concrete examples (res.partner, sale.order), making the tool's purpose unambiguous. It differentiates itself from siblings like odoo_fields (which would list fields) and odoo_search (search 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?

The description implies the tool is used to discover available model names, but it provides no explicit guidance on when to use it versus sibling tools such as odoo_fields or odoo_search. There is no mention of prerequisites or whether it should precede other Odoo operations.

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?

With no annotations, the description carries the full burden, but it only mentions 'autocompletion Odoo' and id conversion. It does not disclose whether it returns a single ID or multiple, what happens if no match is found, whether it is read-only, or any other side effects.

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?

The description is a single, focused sentence that immediately states the purpose and includes an illustrative example. It is appropriately sized for its simplicity, though a bit more structure (e.g., separating the use case from the method) could enhance readability.

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?

Although an output schema exists (so return values are likely covered), the description lacks essential context for a tool with three parameters: no explanation of acceptable models, the meaning of 'limit', failure behavior, or how autocompletion works. It is too sparse for reliable agent invocation.

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 0%, and the description does not explain any of the three parameters (model, name, limit). The mention of 'par nom' relates to the name parameter, but model and limit are entirely undocumented, adding no value over the bare 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?

The description clearly states the tool's function: 'Retrouver par nom (autocompletion Odoo) — convertir "le client Polytec" en id.' It uses a specific verb (retrouver) and resource (name-to-id conversion), and the concrete example distinguishes it from sibling tools like odoo_read or odoo_search.

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 description implies the use case (when you have a name and need an ID) but does not explicitly state when not to use this tool or mention alternatives. There is no comparison with siblings, so the guidance is minimal and left to inference.

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?

With no annotations, the description carries the full burden. It describes the output content (menu paths, checkbox clicks, hook phrases) but not the tool's behavior such as whether it reads a journal, side effects, return format, or limitations. This is only a high-level product description without practical behavioral disclosure.

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?

The description is very short and front-loaded with the core idea, using two sentences. It's efficient and contains no fluff, though it's under-specified. The structure is clean, but the brevity contributes to the overall inadequacy.

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?

Given the tool has three undocumented parameters, no annotations, and relies on an output schema, the description is far too thin. It doesn't explain how the journal is used, what the path parameters do, or what output format to expect, making it incomplete for correct tool selection and invocation.

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 input schema has three parameters (path, format, journal_path) with zero descriptions, and the description doesn't mention any of them. The agent cannot infer what these parameters mean or how to populate them, so the description fails to compensate for the schema's complete lack of 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?

The description clearly indicates the tool provides a meeting demonstration sequence, screen by screen, inferred from prior actions, including exact menu paths and checkbox clicks. It identifies the resource and output, though it lacks an explicit verb like 'generate' and doesn't differentiate from sibling tools such as odoo_demo_questionnaire.

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 description implies usage for meetings ('a suivre en reunion') and mentions the sequence is derived from what has been done, suggesting it should be used after prior actions. However, it doesn't explicitly state when to use this tool vs alternatives, nor does it provide exclusions or prerequisites.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the core function (reading records) without detailing side effects, safety, or limitations. The read-only nature is implied by the verb, but no additional behavioral traits are disclosed.

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?

The description is a single, concise sentence that is front-loaded with the core action and includes a useful example for the key parameter. There is no wasted wording or unnecessary detail.

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 is incomplete for a tool with three parameters and no annotations or schema descriptions. It only addresses `ids`, leaving `model` and `fields` undefined, which is critical for correct invocation. The existence of an output schema does not compensate for this lack of basic usage context.

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 description adds meaning for the `ids` parameter by explicitly noting it is a JSON array and providing an example, which the schema does not convey. However, it does not explain the `model` or `fields` parameters, leaving them ambiguous despite 0% schema description coverage.

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 clearly states it reads records by identifiers, using the verb "Lire" (read) and specifying the resource (records) and scope (by IDs). This distinguishes it from sibling tools like odoo_search, though it does not explicitly reference them. The purpose is specific and unambiguous.

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 description provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It only states what the tool does, leaving the agent without context for selecting it over other read-related sibling tools.

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?

With no annotations provided, the description carries the transparency burden. It adds useful behavioral context by mentioning reliance on write_date/write_uid and visibility of interface changes by others. However, it does not disclose whether the operation is read-only, what kind of data is returned (e.g., changed records vs. a change log), or any limitations.

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?

The description is concise, consisting of two short sentences. It is front-loaded with the core purpose and adds a specific detail (seeing interface changes). No unnecessary filler, though the second sentence could be more informative if it described parameters or usage.

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 has 4 parameters, no annotations, and relies entirely on the description for context. The description gives a general idea but omits crucial usage details: the required 'model' parameter, the meaning of 'jours', the domain filter, and the output type (though an output schema exists). It fails to tell the user how to effectively invoke the tool.

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 schema has 0% description coverage for all 4 parameters, and the description does not mention any parameters. Parameter names like 'model', 'domain', 'jours', and 'limit' are somewhat self-explanatory in Odoo context, but the description fails to clarify their roles or required combinations, leaving significant ambiguity.

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 clearly indicates the tool's purpose: showing what changed recently in Odoo based on the native audit fields (write_date, write_uid). It differentiates from sibling tools by focusing specifically on audit-based recent changes rather than general search/read, though it lacks an explicit verb like 'list' or 'return'.

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 description implies a use case (tracking recent modifications, including interface changes by other users) but does not explicitly state when to use this tool over alternatives like odoo_read or odoo_search, nor does it mention any prerequisites or exclusions.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It mentions that 'partage' makes the analysis visible to all and that 'vue' can be pivot or graph, but it does not disclose whether this operation writes data, requires permissions, or has side effects. The core behavior (saving vs. reading) is ambiguous.

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?

The description is short and uses a line break to separate the main concept from parameter hints, which is somewhat structured. However, the first sentence is a definition rather than an action statement, and the content is under-specified. It is concise but not optimally effective.

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?

Given the tool has 7 parameters, 0% schema coverage, and no annotations, the description should provide more context about what the tool does, when to use it, and what parameters mean. It only partially covers two parameters and gives a vague comparison to dashboards. The output schema exists but the description does not clarify the tool's operation or return value.

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 0%, so the description must compensate. It adds meaning for 'vue' (pivot or graph) and 'partage' (visibility), but leaves five other parameters (nom, model, domaine, groupby, mesures) unexplained. This is partial compensation but insufficient for a 7-parameter 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?

The description is a definitional statement ('Favori Odoo : analyse que le client retrouve...') rather than an action verb. It does not explicitly state whether the tool creates, retrieves, or updates a saved analysis. The name suggests saving, but the description does not confirm. This is closer to tautology than a clear purpose.

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 'Plus leger qu'un tableau de bord' provides an implicit comparison to dashboards, hinting that this tool is for lightweight saved analyses instead of full dashboards. However, it does not name specific sibling tools or provide explicit when-to-use/when-not-to-use guidance, so it is only implied usage.

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?

With no annotations, the description carries the burden of behavioral disclosure. It discloses that the tool returns the domain total and that omitting 'fields' triggers default field selection. This adds useful behavioral context beyond the raw schema, though it does not detail pagination or error behavior.

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?

The description is brief and front-loaded, using two clear sentences plus a warning. Every sentence adds value: explains the action, distinguishes from odoo_count, gives examples, and highlights a critical usage note. No wasted words.

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 has a search/read operation with multiple parameters and an output schema. The description covers the core usage (domain, fields) and notes the total return value. It does not explain pagination parameters (limit, offset, order), but given the output schema and standard nature of these parameters, the description is reasonably 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 0%, so the description must compensate. It provides concrete JSON examples for 'domain' and 'fields', and warns about the default behavior of 'fields'. This adds significant meaning to the most complex parameters, though limit, offset, and order are left unexplained (but are relatively self-explanatory).

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 clearly states the tool's purpose: 'Rechercher et lire' (search and read), and distinguishes it from siblings by noting it returns the domain total, avoiding odoo_count. This makes the tool's function specific and differentiates it from related tools like odoo_read and odoo_count.

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 description provides context by indicating when to use this tool (when you need search results with a total count, avoiding a separate odoo_count). It also gives practical guidance on always specifying 'fields'. However, it does not explicitly mention when not to use it or directly compare with odoo_read.

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?

With no annotations provided, the description carries full burden for behavioral disclosure. It indicates the tool reads connection info, which implicitly suggests a non-destructive operation, but it does not explicitly state that it makes no changes, nor does it mention any prerequisites or error conditions. The lack of explicit safety language is a gap, though the 'status' wording helps.

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?

The description is one short, front-loaded sentence that immediately conveys the tool's purpose and key outputs. Every word adds value, with no filler or redundancy.

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 zero-parameter status check with an output schema present, the description lists the essential information it returns (database, user, version, read/write mode) and is complete given the tool's simplicity. The presence of an output schema means the description need not detail return values.

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 has zero parameters, so the baseline is 4. The description doesn't need to explain parameters and doesn't; the schema coverage is trivially 100% with an empty properties object. Nothing more is needed.

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 clearly states the tool reports the status of the current connection, listing specific attributes (database, user, version, read/write mode). This is a specific, resource-focused purpose that distinguishes it from siblings like odoo_connect or odoo_enable_write, which handle connection setup or write-mode changes.

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 description implies when to use this tool (to check connection status), but doesn't explicitly mention when not to use it or why it might be preferred over alternatives. There's no reference to related tools or exclusion of cases where another tool would be more appropriate, leaving the decision to the agent's inference.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states that the operation is IRREVERSIBLE, there is no trash/recycle bin, and a bulk confirmation is required beyond 50 records. These are critical safety traits for a destructive operation, making the description highly transparent.

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?

The description is three short, front-loaded sentences that immediately convey the most important warning (irreversibility) and then provide additional context. Every sentence earns its place with no wasted words.

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?

Given the destructive nature of the tool and the absence of annotations, the description covers the essential risks (irreversibility, no trash, bulk threshold) and suggests a safer alternative. It does not detail return values, but output schema is present, so that need is covered. It is fairly complete for a deletion tool, though it could mention permissions or side effects.

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 schema has zero description coverage (0%), so the description must compensate by explaining parameters. It only clarifies the `confirm_bulk` parameter's behavior (required beyond 50 records), but does not explain `model` or `ids`. While these may be inferred from context, the lack of explicit definitions leaves a significant gap for a low-coverage 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?

The description clearly states the tool's purpose: 'Supprimer definitivement' (delete definitively), indicating it permanently deletes Odoo records. It distinguishes itself from sibling tools like odoo_write (update) and odoo_archive by explicitly noting that archiving is often preferable, which implies this tool is for permanent deletion.

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 description provides explicit guidance on when to use this tool vs alternatives: it warns that archiving ({"active":false}) is often preferable, and it specifies that deletions beyond 50 records require the `confirm_bulk` parameter. This gives clear context for safe usage and alternative approaches.

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?

With no annotations provided, the description fully carries the transparency burden. It discloses the most critical behavior: without `confirm`, nothing is modified, but a count and before/after sample are returned. It also explains the role of `motif` in the report. This is excellent transparency for a mutation tool.

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?

The description is concise and front-loaded with the main purpose, followed by a clear explanation of the two-step confirm workflow. Every sentence contributes meaningful information with no fluff.

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?

Given the tool's complexity and the presence of an output schema (so return values need not be described), the description covers the essential workflow and safety mechanism. Missing details like domain syntax and value format are minor, but overall the context is sufficient for correct invocation.

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 0%, so the description must compensate. It adds meaning for `confirm` (dry-run vs actual write) and `motif` (justification in report), but does not explain the format/expected syntax for `domain`, `values`, or the purpose of `max_records`. Parameter names are self-explanatory, but the description is incomplete.

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 clearly states the tool's purpose: 'Modifier en masse les enregistrements d'un domaine' (mass modify records of a domain). This is a specific verb+resource+scope that distinguishes it from sibling tools like odoo_write (likely single-record update) and odoo_execute.

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 description provides explicit workflow guidance: first call without `confirm` to preview (dry-run), show results to the user, obtain consent, then call with `confirm=True`. It implies this tool is for bulk updates via the phrase 'en masse', but does not explicitly name alternatives or exclusions.

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?

With no annotations, the description carries the full burden. It discloses the core behavioral trait of idempotency ('Rejouable sans doublon') and the dual create/update action, which is valuable for a mutation tool. However, it does not elaborate on error handling, permission requirements, or the format of 'values', leaving some behavioral aspects implicit.

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?

The description is two concise sentences with no redundancy. It front-loads the primary action, includes a concrete example, and adds usage guidance, making every sentence valuable.

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 upsert concept and the intended use case, but it omits essential parameter semantics for 'model' and 'values' and does not explain the expected format or behavior in edge cases. Since an output schema exists, return values do not need description, but the overall description is minimally sufficient for an expert user, not fully complete for an AI agent.

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 description only adds semantics for the 'xmlid' parameter by providing an example format ('monprojet.client_acme'). The 'model' and 'values' parameters remain undocumented in both schema and description, and with 0% schema coverage, this is a significant gap. The description does not compensate for the missing parameter meaning.

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 clearly states the tool's function: 'Creer ou mettre a jour par External ID', a specific verb+resource. It also distinguishes from the sibling odoo_create by emphasizing the upsert semantics and the External ID mechanism, so the agent knows exactly when to select this tool.

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 explicitly recommends this tool over odoo_create for 'maquette et import' (mockups and imports), giving a clear usage scenario. It also highlights the replayability ('Rejouable sans doublon') as a key advantage, but does not explicitly mention when not to use it or alternatives like odoo_write, which prevents a perfect score.

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?

With no annotations, the description carries the full burden. It discloses the write-lock gating behavior and the modification nature, which is useful. But it omits other behavioral aspects like reversibility, permission requirements, or side effects on existing fields.

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 concise sentences front-load the action and include a necessary warning about the write lock. No wasted words; the structure is clean and easy to scan.

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?

Given the tool's complexity (3 required params) and the presence of an output schema, the description covers the core action and a key constraint. The `model` parameter is fairly obvious in an Odoo context, and the output schema handles return value details, making it sufficiently 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 coverage is 0%, so the description must compensate. It explains that `ids` is a JSON array and `values` is a JSON object, adding structure beyond the plain string schema. The `model` parameter is left undocumented, so only two of three parameters gain semantic clarity.

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 clearly states 'Modifier des enregistrements' (modify records), a specific verb+resource. It distinguishes from create/unlink but not from odoo_update_where, though the explicit `ids` parameter suggests a direct update by ID.

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 description provides an explicit prerequisite: blocked until odoo_enable_write is called. However, it gives no guidance on when to use this tool over odoo_update_where or odoo_upsert, so usage context is only partially covered.

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