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

Annotations already declare destructiveHint=true, so the description's repetition of 'destructive' adds limited value. However, it introduces the behavioral nuance that 'the default ceiling refuses it and says what would not', which tells agents that the tool may be blocked and explains why. This is useful context beyond the annotation, but the phrase 'following the wizard it returns' remains cryptic.

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

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

The description is short but not clear or well-structured. The first sentence is technical ('through `action_cancel`'), and the second sentence is confusing ('says what would not'). Conciseness without clarity is counterproductive.

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

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

The tool has 2 required parameters, a destructive annotation, an output schema, and 18 sibling tools. The description fails to cover how the parameters affect behavior, what the output contains (despite having an output schema), or how this tool fits into the broader workflow. It is grossly insufficient for an agent to use 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 input schema has 0% description coverage, so the description must explain all parameters. It does not: neither 'model' nor 'record_id' are described. The description contains zero parameter guidance, leaving the agent to guess what values are expected or valid.

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 'Cancel a record' but fails to specify what kind of record, in which domain, or how it differs from sibling tools like 'write_record' or 'run_action'. The phrase 'through `action_cancel`' is jargon and doesn't clarify the scope, making the purpose vague and poorly communicated.

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

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

The description provides no guidance on when to use this tool versus alternatives. While it mentions 'destructive' and a 'default ceiling refuses it', it does not explain which scenarios warrant cancellation or when a non-destructive alternative (like 'write_record') would be more appropriate. The context is entirely absent.

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 transparency burden. It discloses behavioral traits (e.g., refuses certain domains, counts per company), but does not mention side effects, performance, or immutability. The description adds value beyond what annotations would provide, but lacks a complete behavioral profile.

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 front-loaded with purpose, uses bullet points for clarity, and is efficient. However, the bullet points could be slightly condensed; some phrases (e.g., 'A count is only as honest as its domain') add style but length. Overall well-structured and concise.

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

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

Given the complexity (counting with domain pitfalls), 3 parameters, and presence of an output schema, the description covers key usage scenarios and edge cases. It lacks details on return value (though output schema exists) and specific error conditions, but is largely complete for effective agent 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%, so the description must compensate, and it does so excellently. The docstring explains each parameter's semantics, providing examples or clarifying defaults (e.g., 'omit to count everything' for domain, and company_ids for multi-company). It adds meaningful context beyond the schema's type definitions.

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

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

The description uses a clear verb 'count' with the resource 'records matching a domain' and explicitly links it to the Odoo `search_count` method. It clearly distinguishes from siblings like `search_read` (which returns records) and establishes its scope as a counting 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 provides explicit guidance on when and when not to use the tool, including warnings about mixing `move_type`, confusing count with sum, and multi-company instances. It effectively helps the agent avoid common mistakes by specifying exclusions and context.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states that the activity appears in a To-Do list and turns overdue, and that activity type resolution is fuzzy (substring match, fallback to first available). The mutation nature (scheduling) is evident, though it could mention if this a destructive action (e.g., cannot be undone) or any permission requirements.

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

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

The description is compact, front-loaded with a clear purpose, and uses a concise bullet-style list for parameters. Every sentence adds distinct value—no filler, no redundancy, easy to scan.

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

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

Despite having an output schema, the description does not explain what the tool returns (e.g., the created activity ID). However, for a creation tool, the primary concern is correct invocation, which the description handles well. The lack of return value explanation is a minor gap, but the tool's purpose is still fully actionable.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the purpose of each parameter in a sentence, adding context beyond the schema titles (e.g., 'deadline offset', 'the one-line title the assignee will read', 'substring of an activity type name'). This gives the agent sufficient guidance for correct invocation.

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 specifies the verb 'schedule' and the resource 'activity' with a clear distinction from a 'chatter note'. It highlights the unique characteristic (deadline) that differentiates it from other notification tools, giving the agent a precise sense of what this 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 explicitly contrasts an activity with a chatter note (sibling notify_user), explaining when to use this tool over a passive notification. However, it does not explicitly list other sibling tools as alternatives or state when not to use it beyond that one distinction.

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?

The description adds substantial context beyond annotations: the search-and-return behavior of unique_on, the lack of Odoo idempotency keys, and multi-company visibility nuances. This complements the readOnlyHint and idempotentHint annotations without contradiction.

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 efficiently structured with front-loaded purpose, followed by essential behavioral and usage details. Every sentence contributes meaningfully, avoiding unnecessary verbosity.

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 existence of an output schema, the description appropriately focuses on input semantics and behavioral traits. It covers idempotency, dedup, and multi-company scenarios, which are critical for correct tool invocation. No gaps remain for the intended 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 compensates well for unique_on (list of field names, dedup logic) and values (company_id guidance). Only the model parameter lacks explicit description, but its purpose is clear from context.

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

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

The description clearly states the verb 'Create' and the resource 'record', and immediately highlights the key deduplication feature with unique_on. This distinguishes it from sibling tools like write_record (update) and read_record (read).

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?

Guidance is provided on when to use unique_on (to avoid duplicates) and when retries cause duplicates due to lack of idempotency key. Multi-company handling is explained. However, explicit comparison to write_record or when not to use the tool is missing.

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

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

No annotations are provided, so the description carries the full burden. It discloses key behaviors: saving to disk, including chatter files, returning saved/skipped lists, and platform-specific temp directory behavior. It does not mention file overwrite policy or permissions, but for a download tool this is reasonably transparent.

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

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

The description is efficiently structured: first sentence states purpose and key nuance, second paragraph explains return format with a useful warning about skipped files, third paragraph details each parameter. Every sentence adds necessary information without 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?

Given the tool's three parameters and no annotations, the description covers purpose, parameter details, return format, and important edge cases. The output schema is not shown but the description describes it adequately. The tool is fully explained for an AI agent to use 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 description coverage is 0%, so the description must compensate. It provides clear meanings for all three parameters: model (with example), record_id (purpose), and dest_dir (default behavior and Windows caveat). This adds significant value beyond the bare schema.

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

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

The description clearly states the verb-resource combination: 'Save every document of a record to disk — chatter files included.' It is specific about including chatter files, which distinguishes it from any sibling tool that might handle documents differently.

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

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

The description provides context on when the tool is relevant by explaining edge cases of skipped documents (database restore without filestore) and the default behavior of dest_dir. However, it does not explicitly define 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 disclose behavioral traits. It mentions actions (writes reference document vs. ranks) but does not clarify side effects (e.g., does 'generate' modify the system?), read vs. write nature, or required permissions. This leaves significant ambiguity for a tool that appears to produce artifacts.

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 front-loaded with a clear purpose sentence, followed by a structured parameter block. Each parameter gets a concise explanation. No redundant information. Could be slightly more compact but remains efficient.

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

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

An output schema exists but the description neither references nor explains return values (especially for 'list' action). It covers parameter behavior adequately but omits error conditions, prerequisites (e.g., is the module installed?), and the structure of the generated document. Some gaps remain despite reasonable param coverage.

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 description must compensate. It explains module_name is a slug and ignored on 'list', actions define output behavior, and models provides comma-separated overrides. This adds essential meaning beyond the schema's bare defaults and 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 the tool discovers a module's structure by interrogating the live instance, with specific actions (generate/list). This distinguishes it from sibling tools like list_known_modules which likely only lists module names, though it could be more precise about 'structure' meaning.

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

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

No explicit guidance on when to use this tool versus alternatives, such as comparing with search_read or list_known_modules. The description does not advise on choosing between 'generate' and 'list' actions beyond defining them, and omits any when-not-to-use 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 provided, the description carries the full burden of behavioral disclosure. It reveals that already rendered PDFs are reused, that the print/send wizard can trigger document sending (a side effect), and that the tool is classified as a state change (L3_STATE_CHANGE) rather than a read. It also notes a cross-platform directory default. Missing are details about error handling or what happens if the wizard fails, but the disclosed traits are significant and useful.

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 (about 100 words) and well-structured. It opens with a clear one-sentence summary, then adds necessary context about reuse, permissions, and side effects, and closes with a bullet-style parameter list. Every sentence adds value, with no redundancy or filler.

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

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

Given the tool's complexity (3 parameters, potential side effect, no annotations), the description is remarkably complete. All parameters are explained, the behavioral nuance (caching, sending, permission gate) is disclosed, and the output schema exists to cover return values. The description does not leave obvious gaps for an agent to misuse the tool.

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

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

The input schema has 0% description coverage, so the description must wholly compensate. It does so admirably with an 'Args' section: 'model' is explained with an example ('account.move'), 'record_id' is described as the ID to print, and 'dest_dir' is given a default behavior and a cross-platform warning ('/tmp does not exist on Windows'). This adds critical meaning beyond the bare schema.

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

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

The description clearly states the tool's purpose: 'Render the PDF of a record and return where it was saved.' It uses a specific verb ('render'), identifies the resource ('PDF of a record'), and the outcome ('return where it was saved'). This uniquely distinguishes it from sibling tools which are mainly CRUD operations, so there is no confusion.

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

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

The description provides context on when to use the tool: to obtain a PDF of a record, with the caution that the underlying wizard can also send the document, so it is gated on a specific permission. It implies usage for PDF retrieval but does not explicitly state when not to use it or list alternatives. However, given no sibling PDF tools, 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 provided, the description carries full burden for behavioral disclosure. It clearly discloses caching behavior (cached per instance, keyed on live client not environment variable), performance characteristics (first call costs ~1 second, subsequent calls free), and a detailed edge case about instance misidentification when `ODOO_DB` is unset. It also reveals that the report carries a timestamp. The only gap is that it doesn't state whether the tool is read-only or has any side effects beyond building the cache.

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 front-loaded with a summary sentence, which is good. However, the explanation of the caching edge case, while valuable, is verbose and could be tightened. It runs to several paragraphs where two well-structured paragraphs might suffice. Every sentence earns its place in terms of content, but the prose could be more compact.

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 complexity of this tool (caching behavior, potential for misidentification, performance profile, drill-down rules) and the richness of the output schema (indicated by 'has output schema: true'), the description covers all necessary ground: what it does, how the cache works, when to refresh, and how to interpret numbers. The output schema likely documents the return shape, so no further explanation is needed there. This is a complete, self-contained description.

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 single parameter `refresh` has 0% schema description coverage (the schema provides only type and default), so the description must compensate. It does so excellently: it explains that `refresh=True` rebuilds the profile from the instance instead of reusing the cache, and implicitly clarifies the default behavior (cached reuse). This adds far more meaning than the bare schema provides.

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 clear verb ('Summarise') and specifies the resource ('connected instance') along with a detailed list of what it covers: version, companies, volumes per area, in-house modules, anomalies. This fully distinguishes it from siblings like 'explore_module' or 'search_read', which operate on different scopes.

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 explains when to use this tool (anytime you need an overview of the connected instance) and provides crucial contextual advice: use `refresh=True` after the instance changes, and mentions the cost profile (first call is expensive, subsequent calls free). It also gives rules for drilling into figures (filter `account.move` by `move_type`, sum `amount_total_signed`). However, it does not explicitly state when NOT to use it or name alternatives among the given 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 provided, the description carries full burden. It accurately signals this is a read-only, listing operation with no side effects, and details the output fields (name, generation date, records). This is sufficient disclosure for a zero-parameter 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?

At 9 words, the description is extremely concise and front-loaded with the key verb and resource. Every word is meaningful. It could optionally mention no parameters are needed, but that is implicit.

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

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

For a zero-parameter, read-only listing tool with an output schema, the description is complete. It states what the tool lists and what information is returned. No critical gaps are present.

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

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

Schema description coverage is 100% but there are zero parameters, so the description has nothing to add about parameters. The baseline is 4 per the rubric for 0 params — description correctly says nothing about params because there are none.

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 'List' and the resource 'modules this server has learned', and specifies the information included: name, generation date, records. This distinguishes it from sibling tools like search_read, read_record, and explore_module by focusing on enumerating learned modules and their metadata.

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

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

The description implies this is a discovery tool for seeing what modules the server knows about, but does not explicitly state when to use it over alternatives like explore_module or read_record. No exclusions or prerequisites are mentioned.

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?

Without annotations, the description carries full burden. It explains the tool returns two lists, details key fields (im_status with state definitions and timeouts, channel_type with distinctions, members, unread counts), and notes that conversations are those the sender belongs to and hasn't archived. It does not mention whether the operation is read-only or any authentication needs, but the listing nature is clear.

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 longer than typical but is well-structured: a bold imperative line, followed by a clear explanation of the two lists with bullet points, and ending with usage guidance. Each sentence serves a purpose, though some details (e.g., the idle time for 'away') could be trimmed without losing core meaning.

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 zero parameters, an output schema (present but not shown), and no annotations, the description provides comprehensive context: why the tool exists ('an agent that cannot see the roster invents ids'), what data it returns with field explanations, when to call it (before any send), and how to use the results with sibling tools. The only slight gap is not explicitly stating it's read-only, but that's strongly implied.

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 zero parameters, so there are no parameter semantics to describe. With 0 parameters, baseline is 4. The description focuses on output context but adds value by explaining what the returned data represents, which is helpful even though no parameters exist.

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 'Who can be messaged and where' and breaks down the two lists: users (with presence) and conversations (with type and membership). It clearly distinguishes from sibling messaging tools like send_direct_message and send_channel_message by naming them and contrasting their roles.

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 opens with 'ASK THIS BEFORE SENDING ANYTHING,' establishing when to use it. It provides conditional advice (check presence before messaging) and explicitly directs to send_direct_message for individuals and send_channel_message for conversations, while noting notify_user is for annotating invoices/orders.

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?

Since no annotations are provided, the description carries the full burden. It discloses important behaviors: message is plain text with escaped HTML, newlines survive but are not turned into line breaks, user notifications go through personal Odoo settings (inbox or email, so email is possible), and the 'comment' subtype can be forced to bypass refusal. The only flaw is the internal contradiction about 'inbox' visibility, which undermines trust slightly.

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-organized with a table and clear sections. The purpose is stated upfront. Each sentence adds value, though the initial visible/inbox contradiction wastes some space. For a tool with 6 parameters and nuanced behavior, this length is justified.

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

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

Given the tool's complexity (6 parameters, required fields, no output schema visible despite context saying one exists), the description adequately covers behavior but misses key context: what the tool returns (a result ID or success message?), and any prerequisites like user permissions or record access. The internal contradiction also leaves the agent uncertain about the 'inbox' subtype's behavior.

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

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

Schema coverage is 0%, so the description must add full meaning. It does so excellently: explains 'model' with an example, describes the plain-text constraint for 'message', clarifies the meaning and default of 'subtype' with a table, defines 'user_ids' as res.users ids with notification semantics, and explains the 'force' flag. Every parameter is thoroughly documented, going far beyond the bare schema.

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

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

The description clearly states 'Write a note on a record's chatter and notify the users you name,' which accurately conveys the tool's primary purpose and distinguishes it from siblings like 'send_direct_message' or 'create_activity'. However, the initial claim that both subtypes post a visible message is contradicted later when the table shows the 'inbox' subtype is NOT visible in chatter, introducing unnecessary confusion.

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

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

The description provides detailed guidance on when to use each subtype (note, inbox, comment) based on visibility and email behavior, which helps the agent choose the right parameter value. However, it does not offer any high-level guidance on when to use this tool versus sibling tools like 'send_direct_message' or 'create_activity', leaving the agent to infer that from the purpose 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?

With no annotations provided, the description carries the full burden. It discloses that messages are returned newest first, that reading does not mark as read, and explains the unread counter behavior. It does not mention authentication requirements or rate limits, but the core read behavior is transparent. The presence of an output schema compensates for the lack of return format details.

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

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

The description is brief and well-structured: a clear purpose statement, usage examples, a prerequisite link, a behavioral note, and parameter definitions. Every sentence adds value, and there is no redundancy or fluff.

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

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

For a simple read operation with two parameters and an output schema, the description covers purpose, usage, parameter semantics, and a key behavioral nuance (unread marking). It does not mention error handling or rate limits, but these are not critical for a straightforward read tool, and the output schema fills the return format 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?

The input schema has 0% description coverage, but the description adds meaning by explaining that channel_id comes from list_message_targets and that limit controls how many recent messages are returned. This provides essential context beyond the schema's type and default, making the parameters understandable.

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 reads Discuss conversations, gives concrete examples of when to use it (e.g., 'what did they write to me'), and explicitly distinguishes from the sibling tool 'list_message_targets' by explaining that the latter provides the channel_id and unread count. This leaves no ambiguity about the tool's purpose.

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

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

The description explains when to use the tool (to answer questions about conversation content) and provides a prerequisite ('list_message_targets gives you the channel_id'). It also notes that reading does not mark as read, which is important for usage context. However, it does not explicitly state when not to use it or compare to alternatives like send_channel_message, though the differentiation is implied.

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 owns behavioral disclosure. It reveals that omitting fields returns a short state list, that reading all fields can be slow or fail, that specific models are refused, and that amount_total is in the record's currency while amount_total_signed is the company-currency sum. These are non-obvious behaviors that prevent misuse.

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 but every sentence adds value: purpose, constraints, alternative usage, and a currency warning. It is structured with paragraphs and bolded warnings, front-loading the core 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?

Considering the 3 parameters, the output schema, and 18 sibling tools, the description covers all necessary context: when to use, when to avoid, parameter semantics, and gotchas. The output schema documents return values, so no further explanation is needed there.

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

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

Schema description coverage is 0%, but the description compensates with thorough parameter explanations: model gets an example, record_id is defined, and fields is explained with its default behavior and constraints. This goes beyond the schema's bare type definitions.

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 'Read one record by id' — a specific verb and resource — and distinguishes itself from search_read by noting it reads a single record by ID. It also adds the 'named fields' pattern, clarifying the output format.

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?

Explicit guidance on when to use this tool vs alternatives: it states that account.move and account.move.line are refused and directs the agent to use search_read with a specific domain. It also warns against requesting all fields and explains the safe default when fields is omitted.

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 discloses behavior: it reads from live instance via fields_get/default_get, not from a table. Warns about hidden side effects of defaults. Transparent about data source and output content.

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 relatively long but well-structured: purpose first, then usage, then warning example, then parameter. Every sentence adds value, though some could be tightened slightly without losing context.

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

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

Given the tool's complexity and the presence of an output schema, the description covers purpose, usage, behavioral details, and parameter. No critical gaps remain; it provides sufficient context for an agent to use it 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% (no parameter description in schema). The description compensates by explaining the 'model' parameter with an example ('crm.lead') and context about Odoo models, adding 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 clearly states the tool lists required fields for a create operation, including defaults and usage distribution. It uses specific verbs ('List', 'demands') and distinguishes itself from siblings like create_record by emphasizing it as a pre-check.

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 instructs to ask this tool BEFORE create_record for unfamiliar models. Explains the rationale with a concrete example of dangerous defaults, providing clear when-to-use 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?

The description goes well beyond the annotations, which indicate destructiveHint=true and non-idempotent. It explains specific behaviors: a returned dict with 'res_model' indicates a wizard to follow, and transitions are one-way (calling twice raises error). This provides valuable context that annotations alone do not cover, fully justifying the tool's behavior.

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

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

The description is moderately concise but could be more front-loaded. The first sentence clearly states the main purpose, but the subsequent sentences about behavior become complex and may require rereading. Some information, like the one-way transition detail, is important but could be structured more clearly.

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 3 required parameters, an output schema, and annotations, the description provides sufficient behavioral detail (wizard handling, transition idempotency). It lacks explicit mention of what the output contains, but since an output schema exists, that burden is partially lifted. The description is adequate for an agent to understand key caveats.

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%, and the description does not explicitly describe each parameter. However, the description mentions the 'method' parameter in context ('the level follows method') and implies that 'record_ids' and 'model' are inputs. Although not detailed individually, the description adds enough context about how parameters relate to the tool's behavior, compensating 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 states that the tool runs a workflow method and reports the state it left behind, which gives a general idea. However, it does not specify what kind of workflow or method (e.g., from which framework or platform), and it does not distinguish itself from siblings like 'cancel_record' or 'write_record' which also deal with state changes.

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

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

The description provides some guidance on when the tool is appropriate (e.g., confirming/posting as state changes) and when it is destructive (cancelling/unlinking, raised ceiling). It also mentions a one-way transition behavior. However, it does not explicitly state when to use this tool over siblings such as 'write_record' or 'cancel_record', nor does it list 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?

No annotations were provided, yet the description transparently discloses multiple behavioral details: hard-capped limit at 200, multi-company reporting bias, performance warning about requesting all fields, and the currency conversion pitfall. This fully compensates for the missing annotations.

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

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

Description is front-loaded with the core purpose, then structured into two numbered pitfalls, then parameter explanations. Every sentence adds value—no filler. Slight length but justified given the complexity of Odoo's quirks. A minor point: the parameter list could be slightly more compact, but the trade-off for clarity is acceptable.

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 6 parameters, 0% schema coverage, no annotations, yet an output schema exists, the description covers parameter semantics, pitfalls, return behavior (hard cap, paging), and domain-specific business logic. It is completely sufficient for an AI agent to execute this tool safely and effectively, including handling complex edge 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?

Schema description coverage is 0%, but the description explains every parameter (model, domain, fields, limit, offset, company_ids) with usage examples, default behaviors, and warnings. It adds substantial meaning beyond what the schema types alone communicate, e.g., explaining the domain format, performance cost of null fields, and the company_ids multi-company trap.

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 uses specific verb 'Search and read' with resource 'records in one call' and immediately references the Odoo method 'search_read'. It clearly distinguishes from siblings like 'read_record' (probably single-record read) and 'count_records' by explaining this is a combined search-and-read operation returning 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?

Provides two explicit, high-value pitfalls with concrete examples: mandatory 'move_type' for account moves, and never summing 'amount_total' (use '_signed' twin). This tells the agent when NOT to use certain patterns and what alternatives to use, which is exceptional guidance beyond basic tool 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?

Without annotations, the description fully bears the burden of behavioral disclosure. It explains the side effect (everyone in channel sees it), the failure mode (non-employee members cause refusal, no post), and the irreversibility (deleting the message does not help). This is comprehensive for a simple 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 well-structured with a brief opening, key warnings in separate sentences, and an Args section. Slightly verbose in the middle paragraph, but each sentence adds clear value. Could potentially trim the middle block slightly, but overall efficient.

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

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

Given the simple input schema (2 string params), no annotations, but an output schema present (which can describe return values), the description covers all critical behavior: side effects, prerequisites, error conditions, and parameter semantics. Nothing essential is missing.

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

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

The schema has 0% description coverage, so the description must compensate entirely. It explains that `channel_id` must come from `list_message_targets`, and `message` accepts plain text or simple HTML. This adds crucial meaning beyond the bare property names 'channel_id' and 'message'.

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 posts to an existing Discuss channel, distinguishes it from creating a channel, and indicates the audience. The verb 'post' and resource 'existing Discuss channel' are specific and unambiguous.

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

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

Explicitly tells the agent not to use this to create channels, directs to `list_message_targets` for valid channel IDs, and warns about unrecoverability of wrong-sized room posts. It also references sibling `notify_user` for external follower rules, providing clear when-to-use and when-not-to-use 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 provided, the description carries the full burden of behavioral disclosure. It explains that the message opens a private chat (reusing existing), is pushed in real time, persists, and reaches offline users on next login. It also notes that it bypasses notification settings and sends no email. Missing are details about permissions, error handling, or response format, but the core behavior is well-covered.

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

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

The description is well-structured: a brief one-sentence summary, followed by use-case context, behavioral details, a clear distinction from a sibling, and then parameter descriptions. Every sentence adds value, and it is appropriately sized for a two-parameter 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 that the tool has only two parameters, no annotations, and an existing output schema, the description covers purpose, usage, behavioral details, parameter semantics, and distinction from siblings. It does not need to explain return values since the output schema is present. The description is sufficiently complete for an agent to select and invoke 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?

The input schema has 0% description coverage, so the description must compensate. It explains that user_id is the 'res.users id of the recipient — from list_message_targets', adding a source for valid IDs. It describes message as 'plain text or simple HTML', providing format guidance. Both parameters are clearly explained 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 the tool sends a 1-to-1 Discuss message appearing in the user's chat systray. It uses specific verbs 'send' and 'message', identifies the resource as a direct message, and distinguishes it from sibling tools like notify_user and send_channel_message by explaining the exact behavior.

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 contrasts with notify_user, stating that send_direct_message reaches the recipient regardless of notification settings and sends no email, whereas notify_user follows preferences and lands in the Inbox bell. It also provides typical use cases ("tell X", "message X", "warn X") and explains that it reuses existing private chats, giving clear guidance on when to use this tool.

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

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

The description goes far beyond the annotations by explaining the idempotent behavior (writing same value succeeds but changes nothing), the destructive nature of setting active=False (archives/deletes), and that the tool reports before/after comparisons. It provides concrete behavioral context that the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=true) only hint at.

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 efficiently structured in three paragraphs: the first states the core purpose, the second explains an edge case (idempotency), and the third warns about destructive behavior. While almost every sentence adds value, it could be slightly more compact by merging the first two sentences into a single line. Overall, it is well-organized and 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?

Given the tool has an output schema (which presumably documents the return format), the description adequately covers all critical aspects: what it does, idempotency, destructive side effects, and change reporting. It is complete for a write tool that only requires model, record_id, and values. No missing information is detected.

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 carries the burden. It explains how the 'values' parameter behaves (setting active=False is destructive) and that the report shows before/after. However, it doesn't explicitly describe the 'model' and 'record_id' parameters beyond what is in the schema, though the overall usage is clear from context.

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

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

The description uses the specific verb 'Write' with the resource 'one record' and explicitly distinguishes the tool by stating it reports what actually changed. It clearly differentiates from siblings like 'create_record' (which creates new records) and 'read_record' (which only reads).

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 explains when to use this tool (to write field values and see actual changes) and when it is not a real update (idempotency case). It also provides a key guideline: setting 'active' to False archives the record and is classified as destructive, which helps the agent avoid unintended destructive actions.

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