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 states the core creation behavior but does not mention side effects, permission requirements, idempotency, duplicate handling, or any operational nuance. This is a thin description 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 purpose, followed by a clean structured Args list. Every sentence earns its place and there is no irrelevant 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?

The tool is simple and has an output schema, and all parameters are described. However, without annotations, the lack of behavioral guidance such as expected side effects, prerequisites, or errors leaves it only minimally complete for a create operation.

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%, but the description compensates by documenting all six parameters with meaningful Spanish semantics, including the required field, the type_ values, and the optional revenue/contact fields. It adds value beyond 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 identifies the action ('Crea un nuevo lead u oportunidad') and the resource ('CRM de Odoo'). This distinguishes it from siblings like odoo_crm_update_lead and odoo_crm_list_leads by specifying creating a new record.

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 is implied that this tool should be used when creating a new lead or opportunity, but no explicit alternatives or exclusion conditions are mentioned. The description does not contrast it with odoo_crm_update_lead or list 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?

No annotations are provided, so the description carries the behavioral disclosure burden. The verb 'Lista' clearly indicates a read-only operation, so there is no hidden mutation risk. However, the description does not mention any additional behavioral traits such as field selection, sorting, or potential limits of the listing beyond the explicit 'limit' parameter, leaving the agent to assume 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 compact and well-structured: one opening sentence states the purpose, followed by a bullet-like 'Args' block that lists each parameter with its meaning. Every sentence contributes useful information, there is no filler, and the content is front-loaded with the primary action.

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 a simple listing operation with all four parameters documented, an output schema present to describe return values, and no annotations needed for safety because the intent is obviously read-only. The only minor gap is the absence of any statement about default ordering or implicit filters, but the description is otherwise complete for effective 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 0% description coverage, but the tool description fully compensates by explaining each parameter with a concise line: stage by stage name with examples, salesperson by assigned seller name, only_opportunities as a boolean filter, and limit as max records with default. This gives the agent enough semantic information to set each argument correctly without opening the schema.

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

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

The description clearly states the verb ('Lista') and the resource ('leads/oportunidades de CRM (crm.lead) en Odoo'), so an agent can tell this is a listing operation. The sibling tools include create/update lead operations and other list tools, but the description makes the target resource unambiguous. It doesn't explicitly contrast with sibling list tools, but that is not critical for purpose identification.

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: call this tool to retrieve CRM leads or opportunities. It provides no explicit guidance on when to use this instead of related tools like odoo_crm_create_lead or odoo_crm_update_lead, and no exclusions or prerequisites. The context is reasonably clear but entirely inferred from the verb and resource.

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 only says 'updates fields', but does not state whether the update is partial or full replacement, whether it validates field names, what permissions are required, whether changes are reversible, or what the response contains. For a mutation tool, this is a significant transparency gap.

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, front-loaded with the purpose, and then uses a clean Args block for parameters. Every sentence is useful and there is no redundant text. The structure makes it easy to parse quickly.

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 two-parameter update tool, the core invocation details are covered, and an output schema exists to describe return values. However, the description lacks behavioral context such as error handling, idempotency, permissions, and what happens when invalid fields are passed. It is adequate for making a call but not complete for fully understanding the tool's behavior.

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 compensate. It does: lead_id is defined as the ID of the crm.lead record to modify, and values is defined as a field->value dictionary with a concrete example. This goes beyond the schema's bare type/title information and gives an agent enough to construct a valid call.

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 ('Actualiza' = updates) and a specific resource ('campos de un lead/oportunidad existente' = fields of an existing lead/opportunity). The word 'existente' clearly distinguishes it from creating a new lead, and the tool name reinforces the update operation. This is enough to differentiate it from sibling tools like odoo_crm_create_lead and odoo_crm_list_leads.

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 no explicit guidance on when to use this tool versus alternatives. It does not mention 'use odoo_crm_create_lead for new records' or provide any exclusion criteria. The only implied usage is that an existing lead is required, but no context is provided about when to choose this update tool over other CRM 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?

No annotations are provided, so the description must carry the behavioral burden. The verb 'Lista' plus the explicit filter semantics ('solo trae productos con qty_available <= 0', partial search) disclose the tool's read-only query behavior well. It does not mention authorization or explicit read-only status, but for a simple list operation this is a minor gap.

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 tool's purpose, followed by concise parameter definitions. Every sentence carries useful information, and there is no filler or repetition.

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 an output schema, the description covers purpose, all optional parameters, filter behavior, and defaults. The existence of the output schema removes the need to document return values, and no critical information is missing.

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 offers 0% description coverage, but the description explains all three parameters with meaningful semantics: name filters by name/internal reference with partial matching, only_low_stock filters by qty_available <= 0, and limit sets the maximum records with a default. This fully compensates for the schema's silence.

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 'Lista productos y su disponibilidad en stock (product.product)', a specific verb, resource, and model. This clearly distinguishes it from the CRM, sales, purchase, and project siblings, none of which list product stock.

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 makes the inventory context clear and no competing sibling tool lists products, so an agent can infer when to use it. It does not explicitly name alternatives or exclusions, but the product/product.product scope provides sufficient 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 the full behavioral disclosure burden. It discloses that the tool checks connectivity and returns the Odoo version, which is useful. However, it does not mention failure behavior (e.g., what happens if the instance is unreachable), error types, or whether the operation has any side effects. For a simple ping, this is adequate but not richly 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 a single, front-loaded sentence with no wasted words. It communicates the action (verify connectivity) and the expected return (version) efficiently.

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 tool with no output schema, the description is complete: it states what the tool does and what it returns (the Odoo version). There is no additional context an agent needs to invoke this tool correctly. The only possible additions would be failure behavior details, but these are not essential for a simple ping.

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 adds no parameter-specific meaning because there are no parameters to document. It correctly implies a call with no arguments, which is consistent with the empty 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 with specific verb and resource: 'Verifica conectividad con la instancia Odoo configurada' (verifies connectivity with the configured Odoo instance). It also distinguishes itself from siblings by being the only connectivity/health-check tool among a set of CRUD/list operations. The added 'devuelve su versión' (returns its version) further clarifies its output.

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 does not explicitly state when to use this tool vs alternatives. However, the purpose is self-evident: it is a connectivity check with no parameters, so usage is implied for verifying connection before other Odoo operations. There is no explicit guidance on when not to use it 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?

No annotations are provided, so the description must carry the behavioral burden. It only states the create action and offers no information about permissions, side effects, reversibility, or failure behavior. Like a bare 'create' statement, it leaves the write operation under-specified.

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: purpose first, then a short usage note, then a clean Args list. Every sentence earns its place and no filler is present.

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 all six parameters with enough semantics for correct invocation, and the output schema exists for return value details. It is slightly incomplete only in behavioral areas such as permissions and failure handling, but for a create task tool this is a minor gap.

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

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

With 0% schema description coverage, the description fully compensates by explaining each parameter's meaning, including the required name, project_id usage, responsible user semantics, deadline format (YYYY-MM-DD), and priority values ('0'/'1', default '0'). This adds substantial value beyond the raw 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 starts with a specific verb and resource: 'Crea una tarea (project.task) dentro de un proyecto Odoo.' This clearly identifies the action and target model, and the create orientation distinguishes it from the sibling odoo_project_update_task.

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 provides a clear use case: 'Útil para que una tarea programada de Cowork registre trabajo pendiente directamente en Odoo.' This tells the agent when the tool is relevant, though it does not explicitly name alternatives or state when not to use 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 present, so the description carries the behavioral disclosure burden. It does add useful behavior: name filtering is a partial search, and limit caps the number of returned records with a default of 20. However, it does not mention ordering, pagination, empty-result behavior, or explicitly state read-only semantics beyond the word 'Lista'.

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 front-loaded with the operation, followed by a compact Args list. Every sentence adds value; there is no repetition 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?

For a simple list tool with two optional parameters and an output schema, the description covers the core call behavior and parameter semantics sufficiently. Return-value explanation is not needed because an output schema exists. The only notable gap is usage-vs-alternatives guidance, which is already scored separately.

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 JSON schema has no descriptions, so the parameter semantics fall entirely on the tool description. It compensates by explaining that name is a partial project-name filter and limit is the maximum records to return. It adds meaning beyond the bare schema types, though the default of 20 is already present in the schema.

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

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

The description opens with 'Lista proyectos (project.project)', which clearly states the action (list) and the resource (Odoo project model). It is distinct from sibling tools like odoo_project_list_tasks, odoo_crm_list_leads, and odoo_sales_list_orders because the resource is explicitly projects.

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 about when to use this tool versus alternatives such as odoo_project_list_tasks or the CRM/sales list tools. It only states what the tool does and describes its parameters. There are no prerequisites, exclusions, or explicit use-case 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?

There are no annotations, so the description must carry the behavioral disclosure burden. It does disclose filter semantics and the default limit, which is useful. However, it does not mention whether the operation is strictly read-only, how results are ordered, whether archived or inactive tasks are included, or what happens when no filters are provided.

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 opens with a concise one-line purpose and then lists parameters in a compact structured format. Every line adds value, and the examples for stage ('In Progress', 'Done') improve clarity without bloat.

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 there is an output schema, the description does not need to explain return values. It covers all input parameters and the default limit. It is slightly incomplete regarding default behavior when no filters are supplied and regarding ordering or visibility of archived tasks, but these are minor gaps for a straightforward list operation.

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 compensates fully by defining every parameter: project_id is an exact ID, project_name is a partial-search alternative, assignee is the responsible person's name, stage references a Kanban column, and limit caps results at 30. This is far beyond the raw schema and gives practical meaning for each argument.

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 and resource: 'Lista tareas (project.task) de Odoo, opcionalmente filtradas.' It clearly identifies what the tool does and the underlying model. However, it does not explicitly differentiate itself from siblings, though the model and action are distinct enough from odoo_project_list_projects and odoo_project_update_task.

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 guidance is provided about when to use this tool versus alternatives such as odoo_project_list_projects or odoo_project_update_task. The description only says tasks are optionally filtered; it does not mention prerequisites, exclusions, or scenarios that favor this tool over others.

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 explains that the tool updates fields and gives an example, but does not state whether unspecified fields are preserved, whether the update is partial, what happens with an invalid task_id, or any permission requirements. For a mutation tool with no annotations, more is needed.

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 primary action, followed by a clear Args section. Every sentence adds useful information and there is no filler or repetition of schema details.

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 parameter semantics are well covered and an output schema exists, so return values do not need explanation. However, with no annotations, the missing behavioral details such as partial update semantics, error behavior, and permissions leave the description somewhat incomplete for safe autonomous use.

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 and only exposes types, so the description adds essential meaning: task_id is the project.task ID and values is a field->value dictionary. The example {'stage_id': 3} clarifies the intended usage well, though valid field names are not enumerated.

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 action and resource: 'Actualiza campos de una tarea existente'. It also gives a concrete example of changing stage/state, which distinguishes it from sibling create/list tools like odoo_project_create_task and odoo_project_list_tasks.

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 'tarea existente' makes clear this tool is for modifying already-created tasks, providing a clear usage context. However, it does not explicitly name alternatives or state when not to use this tool.

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 reveals that the tool creates a purchase.order, but it does not mention side effects, required permissions, validation behavior, idempotency, or what happens on failure. For a mutation tool, this is a notable transparency gap.

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: the first sentence states the core action, and the second section documents parameters without filler. Every sentence provides useful information, and the parameter examples are directly actionable.

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 bare schema and absent annotations, the description supplies the essential input semantics needed to call the tool correctly. It does not mention prerequisites like the supplier needing to exist or product validation, but an output schema exists and the described inputs are sufficient for a basic creation call.

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 provides only parameter names and types with 0% description coverage, but the description fully compensates. It documents supplier_id as the res.partner provider ID and order_lines as a list of dicts with product_id, product_qty, and price_unit, including type hints for each field.

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 ('Crea') with a specific resource ('orden de compra (purchase.order)') and explicitly states it creates the order with its lines. This clearly distinguishes it from listing tools like odoo_purchase_list_orders and creation tools in other domains like odoo_sales_create_order.

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 states what the tool does but does not explicitly say when to use it versus alternatives or when not to use it. The tool name and sibling list imply it is for creating purchase orders, but no exclusionary guidance or alternative routing is provided in the description itself.

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 burden. It does disclose key behaviors: filters by supplier and state, and defaults to 20 records via limit. It does not mention ordering, pagination, or explicitly state the read-only nature beyond the 'Lista' verb.

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, front-loaded with the core purpose, and uses a clear argument list. Every sentence adds useful information and there is 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 listing tool with an output schema and three well-documented parameters, the description is largely complete. The main gap is lack of explicit guidance on when to select this tool over sibling list tools.

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%, but the description documents all three parameters meaningfully: supplier filters by name, state lists all allowed values, and limit specifies the maximum records with default 20.

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 'Lista órdenes de compra (purchase.order)', which clearly identifies the verb and resource. It does not explicitly differentiate from sibling tools, but the resource and name make the purchase domain obvious.

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 through the purchase.order context and filter arguments, but it does not explicitly state when to use this tool versus sibling listing tools like odoo_sales_list_orders or odoo_crm_list_leads.

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 present, so the description carries the behavioral burden. It clearly states that the tool creates a sale.order with its lines, but it does not disclose the resulting order state (e.g., draft vs confirmed), permission requirements, or other side effects. The core mutation is transparent, but the broader behavioral context is thin.

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, front-loaded with the purpose, and followed by a compact Args block that only includes necessary parameter details. There is no fluff or repetition of schema 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?

For a tool with two required parameters, no enums, and an output schema available, the description covers the essential invocation details. It could be more complete with a note on the order state after creation or explicit usage routing, but nothing critical is missing for calling the tool correctly.

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 0% schema description coverage, the description fully compensates by defining customer_id as the res.partner client ID and by giving the exact per-line structure with product_id and product_uom_qty. This adds essential meaning that the bare input schema does not provide.

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 ('Crea') and resource ('cotización/pedido de venta (sale.order)') and mentions order lines, clearly distinguishing this from the purchase, project, and CRM creation siblings. It identifies both what the tool creates and the key included content.

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

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

There is no explicit guidance about when to use this tool versus alternatives, no conditions for use, and no exclusions. The tool name and sibling list imply the sales domain, but the description itself does not route the agent toward this tool over odoo_purchase_create_order or the CRM/project creation 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?

There are no annotations, so the description carries the behavioral burden. It does disclose filtering behavior and valid states, and 'Lista' implies a read-only operation, but it does not mention return format, pagination beyond limit, or any side-effect guarantees.

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, starts with the core purpose, and uses a clean Args list. No filler or redundant content appears.

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, low-complexity list tool with no required parameters, the description covers the essential call semantics. It is complete enough to invoke correctly, though explicit usage guidance relative to siblings would make it 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, and it does: each parameter is explained with meaningful guidance. Customer is tied to partner name, state lists valid values, and limit documents its default and meaning. This adds real value beyond 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 action ('Lista') and the resource ('cotizaciones y pedidos de venta (sale.order)'). It is easy to distinguish from siblings like odoo_sales_create_order and odoo_crm_list_leads because it names the exact model and operation.

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 this is the tool to use for listing sales quotations/orders, and the sibling list shows a separate create tool. However, it does not explicitly state when to prefer this over related tools or provide any exclusion criteria.

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