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 explains the core action (setting active=False) and the return values, but does not disclose whether the operation is reversible, idempotent, or what prerequisites (e.g., permissions) are needed. Some transparency, but gaps remain.

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 plus a tip, which is reasonably concise. The tip is front-loaded, which is helpful. However, the emoji and general advice could potentially be trimmed without losing essential 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 absence of annotations and output schema, the description covers the main purpose and return format but lacks parameter details. The sibling tools include many CRUD operations, but the description does not position this tool relative to them. Adequate but not comprehensive.

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. However, it does not describe the parameters 'model' or 'record_id' beyond their names. It does not provide guidance on valid values for 'model' or the format of 'record_id'. Minimal added value beyond the schema.

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

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

The description clearly specifies the verb 'Archive (deactivate)' and resource 'a record', and explains the mechanism (setting active=False). It distinguishes this tool from general update or delete operations by focusing on deactivation, and explicitly states the prerequisite (model must have an active field).

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 a helpful tip to check for canonical recipes before multi-step work, and states the precondition (only works on models with active field). However, it does not explicitly mention when not to use this tool or compare it to alternatives like delete or update.

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 must cover behavioral traits. It mentions defaults merging, action_id for context, and return format ({id, display_name} or {error}), but does not clarify side effects (e.g., that it modifies state) or prerequisites (e.g., required permissions). This is adequate but not comprehensive 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 reasonably concise, with a key usage hint at the beginning and clear parameter explanations. It uses an emoji to draw attention, and no sentences are wasted. Could be slightly shorter but is well-organized.

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 4 parameters, no output schema, and no annotations, the description covers the return format and parameter semantics adequately. However, it does not explain error conditions beyond '{error}', and lacks details on the 'model' parameter or any limitations. For a simple create tool, it is minimally complete but could be improved.

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 adds significant value. It explains that 'values' are form-view fields only, 'context' is for wizard models, and 'action_id' includes action context. The 'model' parameter is not described but its role is implied. This substantially compensates for the missing 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?

Description clearly states 'Create a new record,' which is a specific verb+resource. The note about checking find_skill/list_workflows helps differentiate from recipe-related tools, but the purpose is generic and does not distinguish between record types.

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 a usage hint to check find_skill/list_workflows before multi-step work, but does not explicitly state when to use this tool versus siblings like update or archive. It implies usage for simple record creation with optional context parameters.

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 and does well: it discloses the created state (unpublished), the URL-uniqueness behavior, and the add_menu side effect on the main menu. It omits permission/auth requirements and rate limits, which keeps it short of a 5.

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

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

A single dense paragraph, front-loaded with the workflow tip and then the core create semantics. Every sentence earns its place, though the tip and the create mechanics are slightly crammed together.

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 3-param mutation tool with no annotations and no output schema, the description covers the created state, side effects, parameter meanings, and even the return shape ({page_id, view_id, url, menu_id?}). Nothing essential for correct invocation 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?

Schema coverage is 0%, so the description must compensate, and it does: add_menu is explained ('also add it to the main menu') and website_id is explained ('target website, default: the current one'). The required name parameter's uniqueness behavior is implied via the URL note but not directly documented.

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

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

States a specific verb+resource ('Create a website page') and goes further to explain the mechanism: a view from the default page template plus the page, with a URL made unique from the name. This clearly distinguishes it from siblings like set_page_visibility and get_page_arch.

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

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

Gives clear context: the page is created unpublished and must be published via set_page_visibility, and the opening tip routes the agent to find_skill/list_workflows before multi-step work. It names alternatives but doesn't state explicit when-not conditions for create_page 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?

With no annotations, the description carries full burden. It discloses key behaviors: the binary is decoded and written to disk, no base64 in context, and returns a structured result. It doesn't detail overwrite behavior, error handling beyond returning an error object, or any authorization requirements, but covers the core behavioral traits adequately.

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 highly concise with three sentences. The first sentence states the core action, the second adds key behavioral detail, and the third provides usage guidance and return format. No unnecessary words 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?

Despite no output schema, the description fully describes the return value format. The tool has only 4 simple parameters (no enums or nested objects), and the description covers the main usage scenario. No additional information seems necessary for effective 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?

Schema description coverage is 0%, meaning the JSON schema provides no parameter descriptions. The tool description only mentions the parameter names (model, record_id, field, dest_path) without adding any semantics, constraints, or examples. This is a significant gap; the agent must infer meaning solely from names.

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 downloads a binary field from an Odoo record to a local filesystem path. It uses specific verbs ('download') and resource ('binary field value from an Odoo record'), and distinguishes itself from siblings like 'upload_binary' by specifying the direction of data flow.

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 explicit usage context: it's intended as the source step in a cross-instance binary migration, paired with 'upload_binary'. It also notes that no base64 passes through AI context, indicating a constraint. However, it does not explicitly state when not to use it or list alternative tools for different 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?

With no annotations, the description carries the full burden and does so well: it discloses dispatch semantics (object-type buttons vs. server actions), the refusal behavior for state-hidden buttons, and the return shapes (Odoo action result, {success: true}, or {error}). An agent knows the failure mode and the response form before invoking.

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?

Dense but efficient: every clause adds information about naming, dispatch, refusal, or return values. The leading tip is useful but front-loads a recommendation to other tools before stating what this tool does, which slightly dilutes the opening.

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 3-required-param mutation-style tool with no annotations and no output schema, the description covers naming, dispatch, refusal, and return values. It stops short of stating permission/auth requirements or how the action result should be interpreted, but is otherwise self-sufficient.

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 so thoroughly for the 'action' parameter, explaining it is a method name or label with concrete examples. model and record_id are left self-evident rather than explicitly defined, which is a minor gap given the zero schema 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?

States a specific verb and resource: 'Execute a button or server action on a record.' It clearly distinguishes this from siblings like update, create, and archive, and even names the two execution paths (view buttons calling the method directly vs. server actions via ir.actions.server.run).

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

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

Provides real routing guidance: check find_skill/list_workflows before multi-step work, and consult get_model_actions to obtain valid action names. It also states when the tool will not work (a button hidden in the record's current state is refused), but it does not explicitly contrast when to prefer this over update or other mutating siblings.

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 exist, so the description carries the full burden and does well: it discloses that no binary passes through AI context, that in-place replacement keeps the same ID with no arch update, that Odoo rejects non-image files when is_image is set, and the exact return shape. It omits permission/auth requirements and any size or rate limits.

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

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

Front-loads the skill-check tip and the core operation, then layers behavior and return details compactly. Dense but each clause earns its place; only the leading skill pointer is arguably tangential to the tool itself.

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 no output schema, the description supplies the return contract ({id, src} and the /web/image vs /web/content URL forms). It is complete for the transfer and replace flows, but the unexplained res_model/res_id/name/public parameters leave a gap for an agent trying to attach to a specific record.

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% across 7 parameters, so the description must compensate. It explains source, attachment_id, and is_image well, but says nothing about name, public, res_id, or res_model (default ir.ui.view) — the parameters that govern how the attachment is linked, which is the operationally tricky half.

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?

Names a precise verb+resource pair ('Load a file from a URL or local absolute path and store it as an Odoo ir.attachment') and adds the distinguishing detail that the MCP server handles the transfer, which separates it from upload_binary/download_binary siblings. An agent can tell what it does without opening the schema.

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

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

Gives clear conditional guidance: pass attachment_id to replace in-place, omit it to create new, and set is_image true for images vs false for JS/CSS/HTML/JSON/fonts. It also routes to find_skill/list_workflows for canonical recipes, though it never explicitly contrasts against the upload_binary/download_binary siblings.

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 that the tool returns full skill records with body and an empty array if no matches, but does not explicitly state whether the tool is read-only, requires authentication, or has any 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 two sentences: the first states the purpose, the second explains filtering and return value. It is front-loaded and contains 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 tool has three optional parameters, no output schema, and no annotations, the description covers the basic functionality and return value, but lacks details on default behavior when no parameters are provided, allowed parameter values, and the exact structure of the returned records.

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 lists the three parameters and states they filter against 'applies_to', but does not explain each parameter's meaning, valid values, or behavior when multiple are combined. This provides minimal additional meaning beyond the schema.

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

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

The description clearly states the tool finds skills matching a situation by filtering on model, field_type, and operation. It uses specific verbs and resources, but does not differentiate from sibling tools like list_skills or get_skills, which could also return skills.

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 filtering by model, field_type, and/or operation is needed, but does not provide explicit guidance on when to use this tool versus alternatives, nor does it 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 provided, so the description carries the full burden and does so well on behavior: it discloses that invisible conditions are evaluated with the web client's own evaluator, results reflect the record's current field values, and it enumerates the return shape. It omits permission/auth requirements and rate-limit behavior, which keeps it short of a 5.

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

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

Three sentences, front-loaded with the core purpose, then the evaluation mechanism, then the return fields. Efficient overall; the return-field enumeration is worth its space given no output schema exists.

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 no output schema and no annotations, the description usefully explains the return fields and the evaluation semantics, which an agent needs to interpret results. It remains incomplete on parameter semantics and usage routing, but the behavioral coverage is solid for a read 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?

Schema description coverage is 0% across three parameters, so the description must compensate and largely does not. 'A specific record' loosely implies record_id, but model and the optional action_id are never explained—action_id in particular is entirely opaque in both schema and description.

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

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

States a specific verb ('Return') and resource ('buttons and actions') with a clear scope qualifier ('for a specific record right now, based on its current field values'). An agent can distinguish this record-scoped action query from the model-level get_model_actions, though the description never names that sibling explicitly.

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

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

Describes what the tool mirrors but gives no when-to-use guidance, no prerequisites, and no exclusions relative to alternatives like get_model_actions, get_record, or execute_action. The agent must infer the usage context from the description alone.

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

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

No annotations provided, so description carries burden. It explains parameter effects but does not mention idempotency, read-only nature, or potential errors.

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, no wasted words, purpose front-loaded. Every sentence earns its place.

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

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

Adequate given no output schema: explains input parameters and their effects. Could mention return format or default handling, but not critically missing for common 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?

With 0% schema description coverage, the description fully compensates: explains model as target, action_id for action context, context for wizard models, adding meaning beyond type-only 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 returns default field values for a model, akin to pre-fill on 'New' action. It distinguishes from siblings like get_model_actions or list_records by focusing on default values.

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 specific guidance on when to use action_id vs context dict, but does not explicitly state when to use this tool over alternatives or provide 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 that the tool returns field metadata and specifies the output structure, but it does not mention any read-only behavior, required permissions, or potential side effects. The transparency is adequate but minimal.

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: two sentences with no fluff. The first sentence states the purpose and scope, the second adds parameter details and return format. It is front-loaded and every word is necessary.

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 no output schema, the description provides a clear picture of the return structure (list of objects with specific keys). It covers both parameters adequately. Minor improvement would be to note any ordering or limits, but it is nearly complete for a straightforward metadata 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 description coverage is 0%, so the description must compensate. It explains the 'model' parameter implicitly by context, and explicitly describes 'view_type' with valid values and default. It adds value beyond the raw schema by explaining the return 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 the tool's function: returning metadata for all fields visible in a model's form or list view. It specifies the key parameter (view_type) and the return format, distinguishing it from siblings like get_model_actions which deal with actions rather than fields.

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 using this tool when you need field metadata for a specific view type, but it does not explicitly state when to avoid it, mention prerequisites, or compare with alternatives such as get_model_interface. This leaves room for ambiguity.

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 alone must disclose behavior. It indicates a read operation (Return) but lacks details on side effects, performance, or authorization needs. The description is adequate but minimal.

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 two sentences: the first states the purpose, the second adds UI context. No extraneous information, and the key action is 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?

Given the tool's simplicity (2 parameters, no output schema), the description covers the basic purpose and context. However, it does not describe the return structure or provide complete parameter guidance, leaving some gaps for an 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 input schema has 2 parameters (model, action_id) with 0% schema description coverage, yet the description provides no additional meaning for these parameters. It does not clarify 'model' or 'action_id', making it unhelpful for correct parameter use.

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 'Return' and the resource 'saved filters and favourites', which is distinct from sibling tools like get_model_actions or get_available_actions. It precisely conveys what the tool does.

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 mentions the context (model's list view dropdown in Odoo UI), implying when to use the tool. However, it does not explicitly state when not to use or name alternatives, which keeps it from a 5.

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

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

With no annotations provided, the description carries the full burden. It does disclose meaningful return-content behavior (which action types are returned, that invisible conditions are included, and that CRUD access flags for the current user are returned), which implies a read-only, permission-scoped operation. However, it never explicitly states that it is side-effect-free, what permissions are required, or how results are scoped, so the behavioral picture is only partially painted.

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 content is delivered in a single front-loaded sentence with no wasted preamble, and the primary output categories come first. It is somewhat dense with parentheticals (Python expression / Odoo 15/16 domain) but each detail earns its place by explaining return semantics.

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?

There is no output schema and no annotations, so the description must cover both safety and returns; it handles the return side reasonably well but omits any explanation of the two parameters and the read-only safety profile. The combination of 0% param coverage and absent annotations leaves a meaningful gap for a model-introspection 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 description coverage is 0% across two parameters. The description never mentions 'model' or 'action_id', so the agent gets no help on whether 'model' is a technical name, what 'action_id' narrows the result to, or whether it is optional. With two undocumented parameters and a bare schema, the description fails to compensate for the coverage gap.

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 ('Return') and resource ('all actions available on a model') and enumerates the exact categories returned (server actions, report actions, form-view buttons, invisibility conditions, CRUD flags). This is far more specific than the name alone. It does not, however, differentiate itself from the close sibling get_available_actions or explain its relationship to execute_action, leaving some routing ambiguity.

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 when-to-use guidance and no alternatives named. An agent must infer from context whether this introspection tool is meant to precede execute_action or how it differs from get_available_actions, which is a near-identical sibling name.

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

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

No annotations provided; description does not disclose behavioral traits like read-only nature, idempotency, or side effects. Only describes return content, not safety or authorization 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?

Two sentences, front-loaded with purpose and value. No wasted words; efficient and clear.

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 one parameter and no output schema, the description sufficiently covers its primary function. However, lacks parameter details and behavioral transparency, leaving some completeness 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?

Only one parameter ('model') with 0% schema coverage. Description adds no meaning beyond the schema—no format, example, or constraint details. Should at least indicate it's the model 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 uses specific verbs ('returns') and clearly defines the resource (form-view field metadata, model actions, CRUD flags). It distinguishes from siblings like get_fields and get_model_actions by offering a combined single-call helper.

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 use ('before creating or editing records') and the alternative ('separate get_fields + get_model_actions round trips'). Provides clear context for selection.

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 fully carries the burden. It correctly indicates a read-only operation (listing models) with no side effects. However, it does not mention any authentication requirements or limitations like pagination.

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 sentence that efficiently conveys two distinct usage patterns. No wasted words; front-loaded with the primary 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?

Given no output schema and no annotations, the description is adequate but could be improved by mentioning the return format (e.g., list of model names or objects) and any relevant behavior like empty results.

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 only defines 'base' as a string with no description (0% coverage). The tool description fully explains the parameter's purpose: to specify a base model for listing relational models reachable via form-view fields. This adds high value.

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 lists primary models via menus or relational models with a base parameter. It differentiates from sibling tools like get_fields or get_model_actions by specifying the context (menus and form-view fields).

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 explains two usage modes (without and with base parameter), which implies appropriate contexts. However, it does not explicitly state when not to use this tool or suggest alternatives among siblings.

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. It discloses the return format (view_id, arch_db) and that the AI is responsible for reading/editing the XML. It does not mention permissions, rate limits, or 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 two sentences, front-loaded with purpose, and contains no unnecessary words. Every sentence adds 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?

For a simple retrieval tool with one parameter and no output schema, the description covers the essential aspects: what it returns, where to get the input, and how to handle the output. Could mention error cases but not required.

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 compensates by stating page_id comes from list_pages. This adds meaning beyond the schema, but does not explain the parameter further (e.g., valid range or format).

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 returns raw arch_db XML of a website page's view, using a specific verb and resource. It distinguishes from sibling tools like 'set_page_arch' (write) and 'list_pages' (list).

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 tells the agent to pass page_id from list_pages, which is a prerequisite. However, it does not explicitly state when to use this tool versus alternatives or 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?

With no annotations, the description must fully convey behavior. It explains return content and context effects but omits key aspects: whether the operation is read-only (likely, but not stated), error handling for missing records, permission requirements, or potential performance implications. The example helps but leaves 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?

Three sentences: first defines purpose, second covers fields parameter, third covers context with example. Each sentence adds value without redundancy. No fluff, front-loaded with main purpose.

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 4 parameters, no output schema, and nested objects, the description is partially complete. It explains input parameters adequately but fails to describe the return format (e.g., structure of form-view field values). Without an output schema, this omission hinders complete understanding.

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 adds significant meaning. It explains 'fields' (subset selection) and 'context' (control read behavior with example). It does not detail 'model' or 'record_id', but these are self-explanatory. Overall, it fills the gaps well.

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 'Return form-view field values for a single record', specifying the verb ('return'), resource ('form-view field values'), and scope ('single record'). This distinguishes it from sibling tools like list_records (multiple records) and search_records (search 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 proper usage: use when you need field values for one record. It explains optional parameters for subsetting (fields) and controlling read behavior (context). However, it does not explicitly contrast with alternatives like get_fields or list_records, which would strengthen 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 burden. It discloses partial success with error objects and the inclusion of back-references, providing useful behavioral context beyond a simple fetch.

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, front-loaded sentences with no redundant information. Every word adds 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?

Given one parameter and no output schema, the description covers input semantics, output format (full skill data with specific fields), and error handling. Lacks explicit structure of frontmatter but is adequate.

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 add meaning. It explains that the array can hold one or more names and that missing names return error objects, adding value beyond the schema's type definition.

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 returns skills with full details (frontmatter, markdown body, used_in back-references). This distinguishes it from siblings like list_skills (which likely returns summaries) and find_skill.

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 specifies that a single name or array of names can be passed and explains partial success behavior for missing names. It does not explicitly contrast with alternatives, but the usage pattern is clear.

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. It discloses that the tool returns {key, name, html} or {error}, indicating a read operation. It does not cover edge cases like rate limits or idempotency, but is sufficient for a simple fetch.

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 with no unnecessary words. The description is front-loaded and every sentence adds 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?

For a low-complexity tool with 1 required parameter and no output schema, the description covers the purpose, input example, and return structure. It is 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 adds value by providing an example of the key format ('website.s_text_image'). This compensates for the lack of schema documentation.

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 'Fetch' and the resource 'HTML for a website building-block snippet', distinguishing it from siblings like list_snippets.

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: when needing the HTML for a specific snippet key. It does not explicitly state when not to use or mention alternatives, but the context is clear.

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?

Despite no annotations, description discloses key behaviors: partial success for missing names, optional expansion of skills, and requirement for names. No mention of auth or rate limits, but adequate for a read 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?

Four concise sentences, each with a clear purpose: purpose, basic usage, optional parameter, error behavior. No redundant 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?

Covers core functionality well given no output schema, but slight lack of detail on exact return structure (e.g., fields returned). Still sufficient for most use cases.

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 coverage, description adds meaning for both parameters: names accepts single or multiple, expand_skills includes skill bodies, and error handling for missing names.

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?

Clearly states 'Return one or more workflows in full' with specific details on content (frontmatter + markdown body) and distinguishes from siblings like list_workflows by focusing on full content retrieval.

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?

Usage is implied through description of parameters and behavior, but no explicit guidance on when to use this tool over siblings like list_workflows or 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?

Discloses key behavior: returns metadata only, never binary data, and src field is usable as URL. With no annotations, this is sufficient for a read-only search tool. Could add more about pagination or rate limits.

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 with no wasted words. Information is front-loaded: first sentence gives purpose, second clarifies behavior, third provides usage 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?

No output schema, so description should detail return format—it only mentions metadata and src. Does not explain relationship to sibling tools like search_records. Adequate but incomplete for a search 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?

Description does not explain any of the 4 parameters (name, limit, res_id, res_model). Schema coverage is 0%, so description should compensate but fails to do so. Only implies model and ID filtering indirectly.

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?

Clearly states it searches ir.attachment records for any model, specifies it returns metadata only (never binary), and distinguishes from upload/download tools. The use case is explicitly mentioned.

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 says to use for finding existing files before uploading duplicates. Does not explicitly state when not to use, but the behavior distinction is clear. Could mention alternatives like search_records for other models.

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, description carries burden. States it returns specific fields but does not disclose if it is read-only, potential performance implications, or behavior when website_id is omitted. Adequate but not thorough.

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?

Extremely concise: two sentences with no redundancy. Front-loaded with verb and resource, efficiently listing output fields.

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?

Adequate for a simple listing tool but missing parameter clarification and usage context. With many siblings, more specificity about when to use would improve completeness.

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%, yet description does not explain the role of the optional website_id parameter. Only mentions it in returned fields, not that it filters pages. Agent must infer from parameter 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?

Clearly states the tool lists website pages and enumerates returned fields: id, name, url, is_published, view_id, website_id. Distinguishes from siblings as no other tool lists pages.

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 on when to use this tool versus alternatives or any conditions. Just a brief description with no context on 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 supplied, so the description carries the full burden, and it does substantial work: it discloses pagination, the default column selection, the effect of context keys like {lang} and {active_test}, and an ordering pitfall (many2one ordering following the related model). It stops short of stating access/permission requirements or explicitly framing the operation as read-only.

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

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

Front-loaded with purpose, then parameter semantics, then the return shape, with no filler sentences. It is dense and slightly long, but each clause adds information an agent needs to call the tool correctly.

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 9-parameter tool with nested objects, no annotations, and no output schema, the description covers the hard parts — return shape is spelled out as {total, offset, limit, records[]}, and the ambiguous parameters are explained. Gaps are minor: model and the limit/offset defaults are left to the schema.

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 only 11%, so the description must compensate, and it does: it defines domain syntax with an example, explains fields and its default, describes context behaviour with two concrete keys, gives an order example plus a many2one caveat, and clarifies how action_id interacts with domain. limit/offset are only implied by 'paginated' and the defaults live in the schema, so it is not fully exhaustive.

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

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

States a specific verb and resource ('Return a paginated list of records') and anchors it with a concrete analogy ('as the list view or the Export dialog would show them'). It does not, however, distinguish itself from the very close sibling search_records or read_group, which an agent must choose between.

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?

Usage is only implied through parameter semantics — it explains how domain is ANDed with an action's domain and what context keys do, which hints at when the tool is appropriate. There is no explicit when-to-use/when-not guidance or any pointer to search_records or read_group as alternatives for the same model.

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 exist, so the description carries the burden. It discloses the output fields and that no body is returned, but does not explicitly state read-only nature or any other behavioral traits. It adds value beyond the empty schema.

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 purpose, no wasted words. Every sentence adds 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?

Low complexity (no params, no output schema). Description explains what the tool returns and how to get full details, making it complete for an 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?

There are no parameters, and schema coverage is 100%, so the description does not need to add parameter details. Baseline 4 is appropriate as the description is sufficient.

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 lists all atomic skills, specifies the returned fields (name, summary, hint, applies_to, used_in), and distinguishes from get_skill for full text. It uses specific verbs and resources, differentiating from sibling tools like get_workflows.

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

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

Provides guidance to use 'get_skill' for full text, implying this tool is for overview. While not exhaustive with siblings, it gives clear context for when to use this tool vs alternatives.

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

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

Describes search behavior (substring, case-insensitive) and return format with specific keys. No annotations provided, so description carries full burden; covers query characteristics and output structure adequately.

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 purpose. Every sentence provides value: tool purpose, parameter behavior, return structure, sibling reference. No redundant text.

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?

Fully covers purpose, parameter usage, return shape, and relationship with sibling. Given simple input schema and no output schema, description leaves no gaps for an agent to invoke 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?

The sole parameter 'search' is explained: 'filters by any substring of the key or name (case-insensitive)'. Schema has 0% description coverage, so this adds essential meaning beyond the schema.

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

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

Clearly states 'List available website building-block snippets' with a specific verb and resource. Distinguishes from sibling 'get_snippet' by positioning this as the listing 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?

Explicitly explains when to use (list all or filter) and directs to 'get_snippet(key)' for fetching injectable HTML, providing clear alternative.

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 burden. It discloses that the tool returns a summary (name, summary, applies_to, skills) and not the full text, which is sufficient for a read-only list 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?

Two sentences, front-loaded with the action, and every word adds value. No waste.

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 or output schema, the description is complete: it states the action, the returned fields, and references get_workflow for more detail.

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, and schema description coverage is 100%. Baseline for 0 params is 4, and no additional param info 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 'List all multi-step workflows' and specifies the returned fields (name, summary, applies_to, skills). It differentiates from get_workflow by indicating that tool provides full text.

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 context for when to use this tool (to get a list/summary) and when to use get_workflow (for full details). While it doesn't explicitly list exclusions, the guidance is sufficient.

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 present, the description carries the full burden and does reasonably well: it discloses the mail.thread prerequisite, that HTML is rendered as literal text rather than markup, the delivery semantics of each message_type (emailed to followers vs silent internal log), and the return shape ({message_id} or {error}). It does not cover permissions or whether the post is reversible, which keeps it short of a 5.

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

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

Three tightly packed sentences, front-loaded with the action and prerequisite, followed by the formatting caveat and the mode distinction. No sentence is redundant and the return shape is appended compactly.

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 4-parameter mutation tool with no annotations and no output schema, the description covers the prerequisite, the input semantics, and the return contract explicitly. Only permission requirements and the exact meaning of model/record_id are left unstated.

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 largely does: it explains body formatting behavior, defines both enum values of message_type, and frames model/record_id via 'on a record.' The two identifier parameters are still only implied rather than named, so it falls short of full 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 opens with a specific verb+resource+scope: 'Post a plain-text message or internal note on a record.' This is clearly distinguishable from the generic create/update siblings, and the parenthetical prerequisite (requires mail.thread) sharpens what kind of record is eligible.

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 a usable decision rule for the message_type parameter ('comment' sent to followers vs 'note' internal, not emailed), which is genuine usage guidance. However, it never contrasts the tool with sibling write paths such as create or update, so the agent must infer when posting a message is the right call.

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 behavioral burden and does disclose the return contract in detail — an array of {<groupby>: value, __count, <aggregate>: value} with many2one and date-group representations — which is real added value. It stops short of stating read-only nature, result limits, or pagination for large groupings.

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?

Dense and front-loaded: purpose first, then per-parameter syntax, then return shape. Every clause carries information, though the single unbroken paragraph and stacked parentheticals make it slightly heavy 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?

No output schema exists, and the description compensates by specifying the result shape, so an agent knows what it will get back. Remaining gaps are the unexplained model/context parameters and any limits on group cardinality or result size.

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 only 17%, so the description must compensate, and it does for the key parameters: groupby syntax including date granularity values (day|week|month|quarter|year), aggregates 'field:agg' specs with named functions, and domain's filter-first semantics. model and context remain unexplained, leaving some gap.

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

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

States a specific verb and resource — 'Count and aggregate records per group' — and anchors it to a familiar analogue ('as the list view grouped by a field shows them'), which cleanly separates it from list_records/search_records in the sibling set.

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?

Usage is implied rather than stated: 'empty for one total' hints at the single-total case and the list-view analogy implies grouping intent, but there is no explicit when-to-use vs. list_records/search_records, no when-not, and no 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. It mentions required parameters and return format but does not disclose side effects, idempotency, permissions required, or whether scheduling affects the record state or triggers notifications.

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 action. It efficiently lists parameters and return format without extraneous words, though a more structured format 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?

For a tool with 7 parameters, no output schema, and no annotations, the description covers most parameters and return format. However, it misses explaining 'model' and 'record_id', and lacks context about side effects or system impact, leaving 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 explain all parameters. It provides examples and format for activity_type, deadline, summary, note, and assigned_user_id, but omits 'model' and 'record_id', which are required and undocumented in both schema and description.

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 'Schedule an activity on a record' with a specific verb and resource. It lists all key parameters and distinguishes this tool from siblings like 'create' and 'update' by focusing on activity scheduling.

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 on when to use this tool versus alternatives, such as 'create' or 'execute_action'. There is no mention of prerequisites, when not to use it, or how it differs from similar 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, and it does disclose real behaviour: what is matched (display name plus per-model keys like reference, email, code), how context alters results (active_test:false surfaces archived; lang changes matching and display_name language), and the return shape. It omits auth/permission requirements and any rate or error behaviour, so it is strong but not complete.

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

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

Front-loaded with the core intent, then progressively adds scoping, alternative routing, context examples, and return shape. Dense but every sentence adds information; it is slightly long, with parenthetical asides, but nothing is wasted.

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 7-parameter, nested-object tool with no output schema, the description supplies the return format ([{id, display_name}] up to limit), matching semantics, and context effects — covering most of what an agent needs. It leaves permission/auth behaviour and the precise semantics of domain/action_id unstated.

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 only 14%, so the description must compensate and largely does: it defines semantics for query (name matching), model (per-model name keys), domain/action_id (narrowing), and context (with two worked examples). The limit and output_path parameters carry no explanation in the description, but output_path is documented in the schema and limit's 'up to limit' hints at pagination.

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

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

States a specific verb and resource ('Find records by name') and pins the exact intent with the quoted phrasing 'which record is called X'. It also explicitly distinguishes itself from the sibling list_records, so an agent can route correctly without opening a schema.

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

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

Names the alternative and the condition that selects it ('For filtering by field values use list_records'), and explains what domain/action_id are for (narrowing) and what context is for (search-time behaviour, with concrete examples). Conditions for the main branch points are all 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 must fully disclose behavior. It mentions the caller is responsible for valid XML but omits details on mutation, idempotency, permissions, error conditions, or return value. The warning is insufficient for a write operation.

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 with two sentences and a tip, front-loading the usage hint. Every sentence adds value, though the emoji is unnecessary. It is efficient 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?

Given the lack of output schema and annotations, the description is incomplete. It does not explain return behavior, error cases, or whether the write is immediate or queued. A more comprehensive description is needed for a mutating 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 coverage is 0%, so the description must add meaning. It links view_id to get_page_arch and arch to XML, but does not explain constraints, formats, or required relationships. This provides minimal value beyond the schema.

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

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

The description clearly states it writes arch_db XML to an ir.ui.view, which is a specific verb-resource pair. It distinguishes from sibling get_page_arch (read) and set_page_visibility (different action) by advising to use view_id from get_page_arch.

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 includes a tip to check for canonical recipes before multi-step work, implying this tool is for writing XML pages. However, it does not explicitly state when not to use it or provide alternatives, leaving room for ambiguity.

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 provided; description only says 'Publish or unpublish' implying state change, but does not disclose required permissions, side effects, or reversibility. For a mutation tool, this is insufficient transparency.

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, no redundancy. The first sentence is a tip not directly about the tool, but the core message is concise. Could be more focused.

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 tool, the description provides minimal context. No output schema means no need to document return values, but missing any mention of errors, idempotency, or behavior when already published/unpublished.

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 the parameters page_id or is_published. Despite self-explanatory names, the description adds no value beyond the schema, failing to compensate for the low 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?

Description states 'Publish or unpublish a website page' which is a specific verb-resource pair. It distinguishes from sibling tools like list_pages and get_page_arch, but lacks nuance like 'set visibility'.

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 includes a generic tip about checking recipes before multi-step work, but provides no guidance on when to use this tool versus alternatives (e.g., when to publish vs unpublish). No context on prerequisites or limitations.

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 fully carries the behavioral transparency burden. It discloses integrity flags (suspect_source, nonempty_base), truncation behavior with max_list and _truncated flag, and return format ({passed, summary, results} or {error}). This comprehensively informs the agent about tool effects and outputs.

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 dense and front-loaded with the core purpose, then details parameters and behavior. It is well-structured but slightly verbose; some details like data types could be inferred from the schema. However, every sentence adds value, and the length is justified by the tool's complexity.

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

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

Given no output schema and 6 parameters (3 required), the description is remarkably complete. It explains what the tool returns, the meaning of integrity flags, truncation behavior, and default language handling. No gaps remain for an agent to understand how to invoke and use 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?

Schema coverage is 0%, so the description must add meaning for all 6 parameters. It explains that record_id and field_name accept single values or arrays, base_lang defaults to 'en_US', target_langs defaults to all non-base languages, and max_list caps term lists with a truncation flag. This provides essential context beyond the schema.

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

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

The description clearly states the tool audits translation coverage and integrity for translatable fields across records. It uses specific verbs like 'audit' and 'reports', and distinguishes itself from sibling tools like translation_get and translation_update by focusing on auditing rather than retrieval or modification.

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 recommends using the tool to 'verify a bilingual push in one call and to catch source corruption early', providing clear use cases. It explains flexible parameter acceptance (single value or array) and defaults for base_lang and target_langs. However, it does not explicitly state when not to use it or mention alternatives, though context implies it's for auditing rather than fetching single translations.

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 adequately details the read-only behavior, including batch processing, optional filtering, and return format variations. It lacks explicit mention of side effects or authentication needs, but for a read tool this is sufficient.

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 moderately long but well-structured, front-loading the purpose. Every sentence adds value, though slightly more brevity could improve conciseness.

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

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

Given no output schema, the description thoroughly covers input variations, batch behavior, and return formats (single vs array). It accounts for complexity and is complete enough 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 coverage is 0%, so the description fully explains each parameter: record_id and field_name accept single values or arrays, langs is optional, model is required. This adds significant meaning beyond the schema types.

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 all language translations for a translatable field on a record. It specifies the action (read), resource (translations), and scope (for a translatable field), distinguishing it from sibling tools like translation_update and translation_audit.

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 when to use the tool (to read translations), mentions batch reading and optional language filtering. While it does not explicitly state when not to use or provide alternatives, the usage context is clear enough for appropriate selection.

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 structure of translations for char vs html fields, the requirement that the target language be installed, and the return formats for different input forms. It does not mention permissions or side effects but covers essential behavioral traits.

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-organized with clear separation of forms and bullet points for examples. It is front-loaded with the purpose and the initial note about find_skill/list_workflows. While somewhat lengthy, every sentence is informative.

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 no output schema, the description adequately explains return values for different input forms. It covers error cases with {error} and mentions language installation. Minor gaps exist, such as not clarifying partial batch failures or the error for missing language, but overall it is fairly 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%, but the description explains all parameters in context, including examples for translations objects and the difference between single and batch forms. The model parameter is mentioned as required but not elaborated; overall, it adds significant meaning 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 explicitly states 'Write translations for translatable field(s)' and distinguishes two forms: single/same-map and batch. It specifies the resource (translatable fields on a model) and clearly differentiates from sibling tools like translation_get (reading) and translation_audit (auditing).

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 guidance on when to use each form (single vs batch) and suggests checking find_skill/list_workflows before multi-step work. However, it does not explicitly exclude alternatives or explain when not to use this tool compared to other update tools like create or update.

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 and does so well: it discloses that both form-view and hidden model fields are written, that context controls write behavior (lang for translate=True fields, mail_notrack suppressing chatter), and the return shape. It omits permission/auth requirements and reversibility, keeping it short of a 5.

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

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

Dense but each clause earns its place, moving from purpose to values syntax to context to return value. The leading 💡 recipe hint is slightly off-topic as an opener and the sentence is long, but nothing is 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?

For a 4-param mutation tool with nested objects, no annotations, and no output schema, the description covers values semantics, context behavior, and return shape adequately. The main gap is the undocumented `model` and `record_id` params and absent auth/permission 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?

Schema coverage is 0%, so the description must compensate, and it does for the hardest params: the `values` format and Odoo Command tuple syntax for one2many/many2many, plus detailed `context` semantics. `model` and `record_id` are left unexplained, which prevents a 5.

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

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

States a specific verb and resource ("Update fields on an existing record") that cleanly distinguishes it from the sibling `create` and read tools like `get_record`/`list_records`. The scope (existing record, form and non-form fields) is 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?

Gives a conditional trigger ("Before multi-step work, check find_skill / list_workflows for canonical recipes") and implicitly scopes to existing records. However it never explicitly contrasts with `create` or names when NOT to use it, so it stops short of full when/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 reveals key behaviors: reads file from absolute path on server filesystem, encodes, writes via ORM, and returns success/error. It also notes that no base64 appears in AI context, enhancing transparency for a write operation.

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 paragraph that front-loads a helpful tip, then states the primary action, migration use case, and return format. Every sentence adds value, 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 4 parameters, no output schema, and no annotations, the description covers the main use case and return format, but lacks details on error handling, file limitations, or parameter constraints. It references sibling download_binary but not fetch_and_upload.

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 parameter names are self-explanatory. The description adds context for source_path (absolute path on server) and field (binary field), but does not detail model or record_id. This partially compensates 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 uploads a local file into an Odoo record's binary field, distinguishing it from siblings like download_binary and fetch_and_upload. It specifies the verb 'upload' and resource 'file into Odoo record's binary field', with additional context about reading from source_path and encoding.

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: check find_skill/list_workflows for recipes, and use this as the target step in a cross-instance binary migration with download_binary. It does not list when not to use it, but the migration context clearly distinguishes from alternatives.

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