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

With no annotations, the description carries the behavioral disclosure burden. It does reveal an important side effect: a confirmation dialog may open and is reported as changes.dialog_opened, with instructions on how to proceed. However, it does not disclose potential destructive/irreversible consequences (e.g., 'Delete') or any prerequisites such as the menu needing to be open/visible.

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 purpose is front-loaded and the dialog-handling instruction is actionable. Both sentences earn their place, though the second sentence is dense with multiple connected clauses. No filler, but not as crisp as it could be.

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 UI-action tool with no annotations and no schema descriptions, the description covers the primary flow and dialog follow-up well. However, the `scope` parameter semantics and behavior when no matching label exists are missing. Since an output schema exists, not restating return values is acceptable, but the scope gap remains significant.

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

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

The description explains the required `item` parameter as a dropdown label with examples, but the optional `scope` parameter is never mentioned. Since schema description coverage is 0%, the description is the only documentation source, and it leaves `scope` completely unexplained.

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

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

The description states the specific action ('Pick an entry ... by label'), the exact UI surface ('cog / "Actions" dropdown of the current view'), and provides concrete label examples. This clearly distinguishes it from sibling tools like open_menu or click_button.

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 defines the situational context (current view's Actions menu) and explains the follow-up behavior when a confirmation dialog appears, directing the agent to confirm with click_button or cancel with click_button('discard'). It does not explicitly contrast with alternatives or state exclusions, so it stops short of a full when/when-not guide.

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

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

No annotations are provided, so the description carries the burden. It details the flow (click add, set cells in order, validate), mentions behavior when required cells are missing (invalid_cells), and fallback to popup. It also explains the 'create' parameter. This is transparent about its behavior, though it could also mention, for example, potential 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 dense but informative, covering key aspects in a few sentences. It could be slightly more structured (e.g., separate usage and parameters) but is far from verbose.

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

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

Given there is an output schema (though not provided here), the description covers the essential behavior, edge cases (missing cells fallback), and parameter hints. It might be missing details on 'scope' and 'values' structure, but it's sufficient for a complex tool.

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

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

Schema coverage is 0%, so the description must compensate. It explains 'field' and 'values' implicitly, mentions 'create' as the label for the add link. It doesn't describe 'scope' or the structure of 'values' in detail, but it provides enough context for an agent to infer usage.

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 adds a line to a one2many/many2many list field (e.g., order_line) and fills it. It distinguishes from siblings like delete_line by focusing on adding, and provides concrete examples.

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 it (adding lines) and gives a fallback behavior (popup form) when inline editing is not possible. However, it doesn't explicitly contrast with similar tools like set_field, but it's clear enough.

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 disclose meaningful behavior: it 'Waits for the resulting RPCs' and reports state changes, navigation, dialog open/close, notifications, and errors. It also flags `timeout` for long actions. This is more transparent than a generic click description, though it could mention prerequisites like visibility or permission.

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 core action is front-loaded and the whole description fits in a short paragraph. The run-on list of 'Also' targets and the tacked-on timeout note could be better structured, but there is no redundant filler.

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

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

The definition is moderately complete: accepted selectors, waiting/reporting behavior, and timeout are covered, and an output schema exists so return values need not be restated. However, `scope` remains unexplained and there is no guidance for resolving overlap with sibling tools, so context is not fully 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 coverage is 0%, so the description must compensate. It explains `name` (technical name or label, with examples) and `timeout` (ms for long actions), but the `scope` parameter is never described. That is a significant gap for one of the three parameters.

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

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

States a concrete interaction ('Click a button') and identifies accepted selectors (technical name or label, with example `action_confirm`). The list of extra click targets makes the resource boundary clear, but it does not explicitly contrast with sibling tools like `click_row` or `action_menu`, so it misses the strongest differentiation.

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 given for when to use this tool instead of siblings such as `click_row`, `open_menu`, or `action_menu`. The overlap is real (e.g. the description lists 'save' as a clickable label while a dedicated `save` tool exists), and no exclusions or decision criteria are provided.

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

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

With no annotations, the description carries the full burden. It says 'open' but does not disclose what that entails (e.g., navigation, form opening, side effects, prerequisites like being on a list view, or failure behavior). No mention of errors, permissions, or state changes.

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

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

The description is two concise sentences with the core action front-loaded. It is efficient, avoids filler, and conveys the essential selection logic and the alternative list_field usage in minimal space.

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

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

While an output schema exists (so return values are not needed), the description omits the scope parameter, does not state prerequisites (e.g., being in a list/kanban view) or consequences of opening a row, and does not differentiate from similar sibling tools like open_record. These gaps make it incomplete for an agent to use reliably.

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

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

Schema coverage is 0%, so the description must explain parameters. It clarifies index_or_text (index or text match) and list_field (one2many context), but completely ignores the scope parameter, leaving its meaning and default 'auto' unexplained.

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 ('Open a row') and the resource ('current list/kanban view'), and specifies the two ways to select a row (0-based index or text match). It also distinguishes the list_field case for one2many lists inside a form, setting it apart from sibling tools like open_record.

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

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

It implies usage in a list/kanban view and explains the list_field condition for forms, but does not explicitly contrast with alternatives such as open_record or click_button. It provides a specific context but no exclusions or clear '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, the description carries full behavioral disclosure responsibility. It discloses the side effects (opening a browser, logging in), the configuration source, and a security-related refusal behavior. It does not describe what happens if connect is called twice or whether an existing connection is replaced, but it gives a solid 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 three short sentences with no filler. The core action is front-loaded, followed by configuration defaults and mandatory sequencing. Every sentence conveys necessary 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 output schema exists and the sibling list includes a disconnect tool, the description provides enough context for an agent to call connect successfully: launch browser, log in, defaults, ordering, and remote-URL guard. It could add idempotency or reconnection behavior, but that is supplementary rather than essential for initial invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It adds value by explaining that arguments default to ODOO_URL/ODOO_DB/ODOO_LOGIN/ODOO_PASSWORD from .env, which clarifies the optional nature of the parameters. However, the headless parameter is not mentioned and its behavior remains 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 states a specific action and resource: 'Open a browser on the Odoo instance and log in.' This clearly distinguishes connect from siblings such as open_url and disconnect, which are navigation or teardown operations. The purpose is concrete and directly actionable.

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

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

It explicitly says 'Must be called before any other tool,' giving the agent unambiguous sequencing guidance. It also explains environment-based defaults and the remote-URL restriction, which are essential configuration constraints. No alternative tool needs to be named for an entry-point operation.

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 a critical behavioral trait: 'Nothing is saved until save/validate.' This is valuable because it tells the agent the operation is not persistent until a subsequent save action. It also explains the 'editing' special value behavior. It doesn't mention side effects like whether the row is immediately removed from the UI or if there's a confirmation dialog, but the save disclosure is significant.

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

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

Two sentences with no waste. The first sentence states the action and target, the second explains the key parameter and the save behavior. Every word earns its place, and the most important behavioral note (nothing is saved) is front-loaded in the second sentence.

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

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

The tool has an output schema, so return values are covered elsewhere. The description covers the main action, the line parameter semantics, and the save behavior. However, it doesn't explain the 'scope' parameter, which is optional but could affect behavior. For a UI automation tool with siblings like add_line and click_button, the description is mostly complete but leaves the scope parameter undocumented.

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 'line' parameter in detail: '0-based row index, or "editing" for the row currently in edition.' This adds meaning beyond the schema's bare anyOf integer/string. However, it doesn't explain 'field' or 'scope' parameters, leaving some gaps. The 'field' parameter is somewhat self-explanatory from the description's example, but 'scope' is not addressed.

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 ('Remove a row') and the resource ('one2many/many2many list field'), and gives a concrete example ('order_line'). It distinguishes itself from add_line, its sibling, by describing the deletion action. However, it doesn't explicitly name the sibling alternative, so it's clear but not fully differentiated.

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 it: when you need to remove a row from a list field, and it mentions the 'editing' special value for the row currently in edition. It doesn't explicitly state when not to use it or mention alternatives like set_field or orm_call, but the context is reasonably clear for a UI automation 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?

With no annotations, the description carries the full burden of behavioral disclosure. 'Close the browser' implies a destructive/terminating action, but it doesn't state whether unsaved state is lost, whether it affects other sessions, or whether it is idempotent. The description is minimal and leaves these behavioral traits undisclosed.

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 short sentence with no wasted words. It is appropriately sized for a simple tool, though it could add a brief note about side effects without becoming verbose.

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 that terminates a browser session, the description is incomplete. It doesn't mention side effects, whether it is safe to call when no browser is open, or how it relates to connect/open_url. The output schema exists but doesn't compensate for missing behavioral context.

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

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

The tool has zero parameters, so the schema provides no parameter semantics to add. The description correctly implies no arguments are needed. Baseline 4 is appropriate for a no-parameter tool.

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

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

The description 'Close the browser.' is a clear verb+resource statement that distinguishes this from siblings like connect and open_url. However, it is terse and doesn't elaborate on scope (e.g., current browser session vs all browser contexts), which leaves some ambiguity for an agent deciding whether this is the right 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?

No guidance is given on when to use this tool versus alternatives. The sibling list includes connect and open_url, which are related, but the description does not state conditions like 'use when done with the browser session' or 'not needed if the browser was opened by another 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?

With no annotations, the description carries the full burden and does so well: it discloses async execution, the available context objects `env` and `__mcp`, the opt-in environment variable requirement, and the 20 kB truncation limit. This goes well beyond what is normally provided.

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

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

The description is compact and front-loaded: purpose first, then execution context, then constraints. Each sentence adds a distinct piece of information with no filler or redundancy.

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

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

It covers the parameter, execution context, enablement condition, and output truncation, and an output schema exists to describe return values. It could additionally warn about potential destructive side effects or error behavior, but overall it is quite complete for an arbitrary JS evaluation tool.

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

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

Schema coverage is 0%, but there is only one self-descriptive parameter, `expression`. The description clarifies that the expression is JavaScript, that async is allowed, and that `env` and `__mcp` are in scope, adding meaningful context 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 states a specific verb and resource: it evaluates a JavaScript expression in the Odoo page. The 'Escape hatch' framing and the mention of arbitrary JS clearly distinguish it from the sibling tools, which are targeted UI/ORM operations.

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

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

It calls itself an 'Escape hatch,' implying use when other tools are insufficient, and it gives a hard prerequisite (ODOO_MCP_ALLOW_JS=1). However, it never explicitly says when to prefer it over siblings or what conditions would make it the wrong choice.

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 transparency. It discloses that clear=True empties the recording and advises reviewing generated selectors before committing. However, it does not state whether the tool writes files to disk, modifies the session in other ways, or requires any specific permissions. The side effect of clearing is covered, but broader behavioral context is missing.

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 dense sentence that front-loads the primary purpose and output types, followed by format options and the clear side effect. It is efficient and avoids fluff, but the structure could be improved by separating the parameter-specific details (format, clear) from the main purpose for better skimmability. It is not overly long and earns a strong score.

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 6 parameters, 0% schema coverage, and no annotations, the description should provide enough context for correct invocation. It explains format and clear but omits the meaning of url, login, and module, which are likely essential for targeting the correct Odoo instance and module. It also does not mention any prerequisites (e.g., that actions must be recorded first) or how the output will be delivered. The presence of an output schema reduces the need to describe return values, but input parameter clarity remains a significant 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?

Schema description coverage is 0%, so the description must compensate. It provides some detail for 'format' (lists the allowed values) and 'clear' (explains its effect), but it does not explain 'name', 'url', 'login', or 'module'. Since only 'name' is required, these parameters are likely important for the export, but their meaning is left entirely to the schema property titles/defaults, which are insufficient without additional explanation.

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: converting session actions into an Odoo web_tour with concrete output types (JS file, HttpCase test, manifest asset line). It lists the specific action types it covers (open_menu, set_field, etc.) and names the output formats. This differentiates it from siblings like run_tour (which executes a tour) and the recording tools (open_menu, set_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 implies usage after performing session actions ('Turn the actions performed in this session'), but it does not explicitly say when to use this tool versus alternatives. It mentions the clear flag and formats but lacks explicit exclusions or guidance on when NOT to use it (e.g., when a different export path is preferred). No sibling tool is named as an 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?

With no annotations provided, the description carries the behavioral burden. It conveys a read-only operation through the verb 'List' and discloses important output behavior: output is 'compact and truncated' and can be filtered via include. It could also state no-side-effects explicitly, but the read-only framing is sufficient for this tool type.

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 well-organized: purpose first, then the enumerated return categories, then parameter filtering guidance. Every sentence adds useful information, and nothing is redundant with the schema.

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 moderate complexity and the existence of an output schema, the description covers the essential behavioral and parameter context: what is returned, how scope works, and how to filter results. The only notable omissions are explicit include_empty semantics and truncation specifics, but these are minor given the output schema exists.

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 scope parameter ('current screen... open dialog when scope='auto'/'dialog'') and fully enumerates valid include values. The include_empty parameter is not described, but its name and default make its intent reasonably clear, so this is a minor gap rather than a critical one.

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, non-tautological action: 'List the interactive elements of the current screen (or of the open dialog...)' and enumerates the exact element categories (fields, buttons, tabs, rows, etc.). This clearly distinguishes it from sibling action tools like click_button, set_field, or open_menu.

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 clear context for when the tool applies: reading the current screen or the open dialog via scope='auto'/'dialog'. It does not explicitly name alternatives or exclusions, but the list-oriented purpose is clear against the action-oriented sibling tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does important work by revealing the buffer semantics: clear empties the buffer afterwards, making the destructive side effect explicit, and since filters to entries with seq > since. It also identifies what kind of content will be returned. A small gap is the meaning of since being null, but overall the key behavioral traits are 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 compact and well-organized: purpose first, then parameter semantics in a clear 'name: meaning' format. There is no filler or repetition of schema type information. Every clause earns its place, and the length is appropriate for a tool with two optional parameters.

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

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

The tool is low-complexity and has an output schema, so the description need not detail return values. It covers the purpose, the error categories, and both parameters' core semantics. The notable omission is the behavior of since when set to null, which is the default and therefore likely to be used without explicit intent. This leaves an agent slightly uncertain about the baseline query.

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 for the bare schema. It does meaningfully explain both parameters: since is a sequence threshold and clear empties the buffer afterwards. However, the description is brief and does not clarify the behavior of since when it is null, even though null is the schema default and a natural way to call the tool.

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

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

The description opens with a specific, action-oriented phrase, 'Return intercepted errors,' and enumerates the exact error categories covered: server RPC errors with tracebacks, JS errors, open error dialogs, and error notifications. This makes the tool's purpose unambiguous and clearly distinguishes it from any sibling tool, none of which concern error 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?

The description implies when to use the tool (whenever you need the current session's intercepted errors) but provides no explicit usage context, exclusions, or alternatives. It does not say, for example, 'use this after an action to check for failures' or contrast with a different error-checking path. The since/clear details are parameter semantics rather than usage guidance.

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

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

With no annotations, the description carries the transparency burden and does add meaningful behavior: case/accent-insensitive label matching, exact > prefix > contains precedence, support for xmlids, and the fact that it returns a location. It does not discuss side effects, but opening a menu is inherently low-risk navigation.

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 tight, front-loaded sentences with no filler. The core purpose, accepted formats, and key matching behavior are all covered efficiently.

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

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

For a single-required-parameter tool with an output schema, the description covers input variants, separators, matching behavior, and return value. Nothing an agent needs to select and invoke this tool correctly 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 provides only a bare string parameter with no description, so the description must compensate fully. It does: it explains that path can be a label path or xmlid, shows valid separators, gives examples, and specifies the matching strategy.

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 a specific verb+resource: open a menu using a label path or xmlid, with concrete examples. It is distinguishable from sibling tools like open_record or action_menu, though it does not explicitly name or contrast them.

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

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

Provides clear instructions on accepted path formats and matching precedence, so an agent knows how to invoke it. However, it does not say when to prefer this tool over alternatives such as action_menu or open_record, nor does it describe exclusions or prerequisites.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal an important behavior: without res_id and with view_type='form', it opens a blank new record, and it hints that menu defaults may be lost. But it does not explicitly state that this is a UI navigation action, that it does not save data, or whether any side effects occur before save, leaving some behavioral ambiguity.

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

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

Two sentences with no filler. The main purpose is front-loaded, and the second sentence packs the edge-case behavior and a usage tip into minimal text. Every sentence contributes directly to correct invocation.

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 three parameters and an output schema, the description covers the main call patterns (form, list, kanban, blank new record) and gives a sibling preference. It does not explain exact model string format or what the output schema contains, but the output schema exists and the tool is simple enough that the description is largely 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. It explains that 'res_id' identifies the specific record and that 'view_type' can be 'form', 'list', or 'kanban' (implied for form, explicit for list/kanban). It also ties the absence of res_id and view_type='form' to the blank-record behavior, adding real meaning beyond the raw parameter 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 states a specific verb ('Open') and resource ('record' or 'model's list/kanban view'), and clearly names the accepted view types. It distinguishes itself from siblings like open_menu and open_url by focusing on model+id-based navigation, so an agent can tell exactly what it 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 gives an alternative for creating new records: 'Prefer click_button("new") from a list to keep the menu's defaults.' It also explains the default behavior when res_id is omitted, which tells the agent when the blank-record path applies. However, it does not explicitly contrast with other navigation siblings like open_menu or open_url, so it misses a small amount of routing guidance.

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

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

No annotations are provided, so the description carries the full burden. It states the action but doesn't disclose potential side effects like page reload, error handling on invalid paths, authentication requirements, or whether it waits for page load. For a navigation tool, these are relevant behavioral details. The description is too thin on what happens after navigation and on failure.

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

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

Two sentences with no filler. The primary action and examples are front-loaded, and the note about subsequent tools is concise and relevant. 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?

Given that an output schema exists (though not shown), the description doesn't need to detail return values. It covers the essential purpose, gives usage context, and hints at the interaction flow. It lacks details on edge cases (e.g., invalid path, network issues), but for a simple navigation tool this is adequate. A 4 reflects that it is complete for typical use, not exhaustive.

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 'path' as a string with no description (coverage 0%). The tool description compensates by providing concrete examples ('/wms/reception' for kiosk, '/web' to return), which clarifies the expected format and meaning. 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 action (navigate), the resource (URL path on the connected Odoo host), and provides concrete examples. It also implicitly distinguishes itself from element-interaction tools by noting that plain HTML pages are then driven via get_elements / set_field / click_button, making its role as a navigation step obvious among siblings.

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 examples of when to use it (kiosk page, web client) and implies it is a prerequisite for subsequent interaction tools. It doesn't explicitly state when not to use it or name alternatives like open_menu, but the navigation-focused wording makes the intended usage clear. A bit more explicitness about avoiding it for menu-based navigation would push it to 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?

No annotations exist, so the description carries the full burden. It discloses result truncation at 20 kB and notes that it bypasses the UI and runs through the session, implying authentication context. It also implies side-effecting operations ('create for test data'), though it does not detail error behavior or potential data integrity impacts.

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

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

The description is three sentences with no redundancy. It front-loads the core action, then states purpose/usage, then a critical output limit. Every sentence contributes value, making it both concise and easy to scan.

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

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

For a generic ORM caller, the description provides essential context: purpose, session/authentication, and a 20 kB truncation limit. It lacks explicit notes on model name validation or method availability, but given the tool's generic nature and the presence of an output schema, it is reasonably complete.

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

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

The schema has zero descriptions (0% coverage) and only type/title information. The description gives examples of methods but does not explain the structure or intended use of 'args' and 'kwargs' beyond their schema types, leaving agents to guess that args are positional and kwargs are keyword arguments—an important gap for a generic method caller.

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 ('call') and resource ('model method'), and adds context that it executes server-side through the logged-in session. Concrete examples (search_read, read, name_search, create) clarify the intended usage and clearly distinguish it from the UI manipulation siblings.

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

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

It explicitly says to use it to 'prepare or verify data' and 'not to replace the user flow', which provides clear when-to-use guidance relative to UI tools. However, it does not name specific alternative tools or describe scenarios where another tool would be preferred, leaving some inference to the agent.

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

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

With no annotations, the description carries the behavioral disclosure burden. It reveals that execution happens inside the open browser, uses auto mode, and returns success/failure with the failing step description. This covers the main behavioral surface, though it leaves 'auto mode' and potential side effects on browser state implicit.

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

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

Two sentences, front-loaded with the tool's purpose and workflow position, followed by a concise parameter note and result summary. Every sentence earns its place with no filler.

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

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

The core purpose, input option, and result behavior are covered, and an output schema exists. However, with no annotations and 0% schema coverage, the unexplained name/timeout parameters and the unstated dependency on an already-open browser or existing recording leave notable gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It only explains steps_js; name and timeout are never described, forcing the agent to infer their meanings from defaults and parameter 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 gives a concrete verb ('Replay'), a resource ('recorded actions as an Odoo web_tour'), and an explicit purpose ('validate an export_tour result before adding it to a module'). This clearly differentiates it from the sibling export_tour, which is the recording counterpart.

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 clearly states the intended workflow position: use after export_tour and before adding the tour to a module. It does not explicitly list alternatives or exclusions, but the contextual framing is sufficiently narrow to guide an agent's 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 provided, the description carries the full behavioral disclosure burden. It usefully discloses that the tool 'Reports invalid required fields and server errors,' which is a behavioral trait beyond the name. However, it does not mention side effects, persistence specifics, or whether saving overwrites existing data.

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

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

The description is short and front-loaded with the primary purpose, with no filler. The only slight weakness is the abrupt fragment 'timeout in ms,' which is informative but not well-integrated. Overall, every sentence earns its place.

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

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

For a simple tool with two optional parameters and an output schema, the description is usable: an agent can invoke it with defaults. However, the meaning of 'scope' is missing, and there is no guidance on when to use it relative to alternatives. The gaps are significant but not critical for a default invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It only adds meaning for the timeout parameter ('timeout in ms') and leaves the scope parameter completely unexplained. This is partial compensation at best, and insufficient for an agent to understand valid scope values or behavior.

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

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

The description states a clear verb and resource: 'Save the current form (or the open form dialog).' It also adds behavioral specifics about reporting invalid fields and server errors, which differentiates it from siblings like open_record, set_field, or click_button. Even though the name is generic, the description makes the purpose unambiguous.

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

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

The phrase 'Save the current form (or the open form dialog)' implies when to use the tool, but there is no explicit guidance about when not to use it or which alternative to pick. It does not name sibling tools or rival approaches, so an agent must infer usage from 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?

No annotations are provided, so the description carries the full burden. It discloses a key behavior: the screenshot is saved to a file (under screenshots/ or an absolute path) and then returned. However, it does not mention any prerequisites (e.g., an active browser connection), side effects (e.g., file overwrites), or limitations (e.g., timing, visibility of elements). For a read-like operation, this is moderate disclosure, but not exhaustive.

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, tight sentence that front-loads the core action and includes the most important behavior (save location). Every word adds value; there is no filler. It is appropriately sized 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?

The tool is simple with only two optional parameters and no output schema or annotations. The description adequately explains the main purpose and the path parameter, but fails to describe 'full_page', which is a significant omission. It also doesn't specify the return format beyond saying 'return it', which could be ambiguous (does it return the file path or the image data?). For a tool with zero annotation coverage, this is incomplete.

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

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

Schema description coverage is 0%, so the description must explain both parameters. It partially does: the phrase 'unless an absolute path is given' clarifies the 'path' parameter by indicating it influences the save location. However, it completely omits any mention of the 'full_page' boolean parameter, which is essential to understanding whether the screenshot captures the full page or just the viewport. This leaves the agent guessing about half the tool's capabilities.

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 does a specific thing: takes a PNG screenshot of the browser, with a clear resource (browser) and verb (take). It also mentions the default save location and that it returns the screenshot, making it unambiguous and differentiated from any sibling tools (none of which are screenshot-related).

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 whenever a screenshot of the current browser state is needed. It does not explicitly mention alternatives or when not to use it, but among the sibling tools there is no other screenshot tool, so the context is clear. A minor gap is the lack of any explicit 'use this when...' statement, but given the self-evident purpose, this is acceptable.

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 behavioral burden. It discloses important operational behavior: suggestion selection, loose field matching, the side effect of clear=True removing existing facets, and the return value (active facets). It does not mention scope behavior, but the main behavioral traits are transparently 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 compact, front-loaded with the primary action, and each sentence contributes useful behavior or parameter semantics. Slightly dense run-on phrasing prevents a 5, but there is no wasted content.

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

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

The output schema exists, so return-value documentation is not the description's burden. For a four-parameter UI-search tool with no annotations, the description covers the required text, the optional field semantics, and the clear side effect. The only notable omission is the scope parameter, leaving it slightly incomplete.

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

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

Schema description coverage is 0%, so the description must compensate. It explains text, field (label shown in suggestions, matched loosely), and clear (removes existing facets), but does not explain the scope parameter at all. This is a strong partial compensation, missing only one parameter's meaning.

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

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

The description states the exact action ('Type in the search box of the current list/kanban') and conveys the resource and context. It is specific enough to distinguish this from siblings like open_record or open_menu, and it clarifies what result the tool produces (active facets).

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 the two modes of use: no field uses the first suggestion, and a field picks the matching suggestion. It also explains clear=True behavior. It does not explicitly name alternatives or give when-not-to-use guidance, but no direct sibling search tool exists, so this is sufficient contextual usage guidance.

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

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

With no annotations, the description takes on the behavior disclosure burden. It discloses auto-switching notebook tabs, row validation/commit behavior, invalid-cell reporting, and the fact that onchange can alter other fields and that those changes are returned. It also exposes side effects such as quick-creating records and opening a selection dialog.

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 long but every section earns its place: purpose, supported types with concrete syntax, notebook behavior, list editing, and return value. It is front-loaded with the core action and then layers detail by 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?

For a 6-parameter tool with 0% schema coverage, the description covers the main workflows, type-specific value encodings, and the return contract, so the tool is callable in most cases. It leaves scope undefined and does not describe what commit=false implies, which are small but real gaps in an otherwise rich definition.

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 explain the parameters, and it does so for name/value (including typed formats and many2one dict options), line/list_field, and commit. The one gap is 'scope', whose default 'auto' is never explained, keeping this from 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?

Opens with a specific verb and resource: 'Set a field on the current form (or open dialog), by technical field name.' This clearly distinguishes set_field from sibling tools like click_button, open_menu, or add_line, and the scope (form/dialog/list cell) is stated up front.

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

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

The description gives clear context for when the tool applies: current form, open dialog, and editable-list cells. It does not explicitly list when-not-to-use cases or name alternatives, but the usage domain is unambiguous enough to route an agent correctly.

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 transparency burden; it clearly frames the operation as describing (read-only) and lists the state dimensions it reports. It does not explicitly state 'does not modify state' or discuss errors, but the verb and scope make side effects and behavior adequately clear for this query 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?

One tight, front-loaded sentence states what the tool does before a colon-separated list of specifics; every listed item adds information and none 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 zero-parameter introspection tool with an output schema, the description covers the relevant situational details and does not need to document return structure. It fully specifies what aspects of the screen are described, which is sufficient for selection and invocation.

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

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

There are zero parameters and the schema is already complete, so there is no parameter ambiguity; the baseline of 4 applies. The description adds no misleading or redundant parameter details.

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 and resource ('Describe the current screen') and enumerates the exact aspects covered (menu path, model, record id, view type, record state, dirty/new flags, open dialog, notifications), making its intent unmistakable. It does not explicitly name sibling tools, but the content distinguishes it from visual (screenshot) or low-level (get_elements) tools.

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

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

The wording implies the tool is for obtaining a structured summary of the current UI context, but there is no explicit statement about when to prefer it over siblings or when not to use it. An agent would need to infer its relationship to tools like screenshot or get_elements.

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