zenpilot

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

No annotations are provided, so the description carries the full burden. 'With a real mouse event' is a genuinely useful disclosure that this dispatches actual input rather than a synthetic DOM event, but it omits consequences (navigation, form submission, waiting for load) and failure behavior.

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

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

One sentence, action front-loaded, zero filler. Nothing could be removed without losing information.

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

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

For a one-parameter browser interaction with no output schema, the description covers the operation, the target, and the source of the identifier. It could go further on post-click effects such as navigation or load-waiting, but it is sufficient to call the tool correctly.

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

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

Schema description coverage is 0% for the single ref parameter, so the schema offers only a bare string. The description compensates by explaining what a ref is and where it originates (read_page), which is the key semantic the agent needs.

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

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

States a specific verb (click) and resource (element identified by ref), which clearly separates it from siblings like type, scroll, or read_page. It does not explicitly name a sibling to contrast with, but the action is unambiguous.

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

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

By noting the ref comes 'from read_page', it implies the precondition that read_page must run first to obtain a ref. However, it never states when to prefer click over alternatives (e.g., type for text entry) or what to do if the ref is stale.

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, but it only says 'Close a tab.' It does not disclose whether the close is destructive/permanent, whether unsaved state is lost, whether the tab must exist, or what happens on invalid tab_id.

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

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

A single short, front-loaded sentence with no waste, but its brevity reflects under-specification rather than disciplined concision.

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 one-parameter mutation-with-no-annotations tool, the description is too thin: it omits tab_id sourcing, destructiveness, and error behavior, leaving the agent without enough to call it 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 description coverage is 0% for the single tab_id parameter, and the description adds nothing about its format or where to obtain it (e.g., from list_tabs). It fails to compensate for the coverage gap.

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

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

States a specific verb (close) and resource (tab), so an agent understands this removes an existing browser tab. It implicitly contrasts with new_tab and switch_tab but does not name any sibling to differentiate scope.

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

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

No guidance on when to close vs. switch or navigate away, no exclusions, and no mention of any precondition. The agent must infer all usage context from the name alone.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses a content-selection heuristic (prefers <main>/single <article>), but omits fallback behavior, truncation via max_chars, and tab targeting.

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

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

A single front-loaded sentence with zero filler. It is appropriately sized for a simple extraction 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 two undocumented parameters, no annotations, and no output schema, the one-sentence description is too thin. It does not cover parameter behavior or expected return shape.

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%. Neither tab_id nor max_chars is explained in the description, leaving the agent to guess whether tab_id defaults to the active tab and how max_chars truncates the output.

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 what it returns: readable main text, with an extraction preference for <main> or a single <article>. This distinguishes it from broader siblings like read_page, though it does not explicitly name alternatives.

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

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

No guidance on when to use this tool versus read_page, screenshot, or scroll. There are no prerequisites, exclusions, or alternative-routing hints.

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 does disclose the output convention that the active tab is marked with *, which is genuinely useful behavioral detail, but it says nothing about window scoping, ordering, permissions, or whether it reflects live browser state.

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 short sentences, zero waste, and the output-marker detail is front-loaded right after the core action. Nothing is padded.

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

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

There is no output schema, so the description should carry the return-value burden. It partly does (ids plus active marker), but leaves unclear whether tabs are scoped per window, their ordering, and what identifying context beyond an id is returned.

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 parameters and 100% coverage, so the baseline of 4 applies. There are no arguments for the description to explain.

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

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

States a specific verb+resource (list open tabs) and even describes the output shape (ids, active marked with *). However, it offers no differentiation from siblings like get_text or read_page, which also surface page content, so an agent must infer when a tab listing is the right call.

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

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

No explicit when-to-use or when-not guidance, and no mention of the obvious companion tools (switch_tab, close_tab, new_tab). Usage is only implied — the agent must infer it should call this before switching or closing a tab.

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 usefully discloses one non-obvious trait — it waits for the page to finish loading (synchronous/blocking behavior) — but omits error handling, whether existing tab content is replaced, and permission/auth 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?

A single efficient sentence with no waste and the core action front-loaded. It is appropriately sized, though it could carry one more clause without becoming bloated.

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 2-param tool with no annotations and no output schema, the description covers the essential action and the load-waiting behavior, but leaves the tab_id semantics and failure modes unexplained. Adequate but with clear 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 implicitly covers 'url', but says nothing about 'tab_id' (nullable, default null) — e.g., what happens when tab_id is omitted, whether a new tab is created or the current one is used.

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

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

States a specific verb and resource: 'Load url in a tab'. However, it does not distinguish itself from siblings like read_page, new_tab, or switch_tab, which also concern tab/page context, so an agent gets limited routing help.

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 when-to-use or when-not-to-use guidance. It doesn't clarify the relationship between navigate and new_tab/read_page, leaving the agent to infer when navigation is the correct 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, the description carries the full burden, and it does disclose one genuinely useful side effect: the new tab 'becomes active' (a focus change). It does not say whether the previous tab's state is preserved, whether the response yields a tab identifier, or anything about popup-blocking/permission 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?

A single front-loaded sentence with zero wasted words; the activation behavior is called out inline rather than buried.

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 one-parameter tool with no annotations and no output schema, the description is adequate but thin: it does not indicate what the call returns (e.g., an identifier usable with switch_tab/close_tab), which is the main missing piece for correct follow-up actions.

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. 'Optionally loading url' correctly conveys that url is optional and what it does, but adds nothing about accepted format (absolute vs relative) or what loads when it is omitted.

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?

Specific verb+resource: 'Open a new tab' is unambiguous and clearly distinct from the siblings switch_tab, list_tabs, and close_tab, which deal with existing tabs. It stops short of naming or contrasting those siblings explicitly, so it lands at 4 rather than 5.

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

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

There is no guidance on when to open a new tab versus using switch_tab to reuse an existing one, or versus navigate. The use case is only implied by the verb; no prerequisites or exclusions are given.

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

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

With no annotations, the description carries the full burden and does well: it discloses the ref format, that refs expire on re-call or navigation, how checked states are rendered, and how role-less 'clickable' elements are labeled. It does not say whether the call itself navigates or mutates page state, which is the main remaining gap.

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

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

The core statement is front-loaded in the first sentence and the remaining lines each carry distinct information about refs and element states. The 'clickable' explanation is slightly discursive but still 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?

With no output schema, the description must convey return shape, and it does: an outline of elements, ref tokens, and state markers. Missing details are the tab_id default behavior and whether text content is truncated or scoped to viewport.

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 single optional tab_id parameter is never explained in the description. An agent cannot tell from the text whether omitting tab_id targets the current tab or the active one, nor what format tab_id takes.

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 statement of the resource returned: an outline of visible interactive elements and text, with refs like r12. That is far more than a restatement of the name. It never contrasts itself with the close sibling get_text, so an agent must infer which of the two to call for plain text.

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

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

Usage is only implied: the mention that elements 'get refs like r12 for click and type' hints that read_page is the prerequisite for click/type, but the description never says when to use it instead of get_text, screenshot, or scroll. No exclusions or alternatives are named.

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 disclosure burden. 'Visible part' usefully signals that off-screen content is excluded, but nothing is said about the return format (image data vs. path), permissions, or side effects.

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

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

A single short sentence with no waste and the key scoping qualifier ('visible part') front-loaded. Its brevity, however, tips into under-specification rather than disciplined conciseness.

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

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

With no annotations, no output schema, and an undocumented parameter, the description is too thin for an agent to call this confidently—especially since the return format of a screenshot tool is a critical unknown.

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?

One parameter (tab_id) with 0% schema description coverage and a null default. The description never mentions tab_id or explains what happens when it is omitted (e.g., capturing the active tab), so it does not compensate for the schema gap.

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

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

The phrase 'Screenshot of the visible part of a tab' identifies the resource (a screenshot) and the scope (visible viewport of a tab), which distinguishes it from read_page/get_text. However, it's a noun phrase with no verb and no explicit statement of what the tool does (capture/return an image), leaving the action implied rather than stated.

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

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

There is no guidance on when to use this tool versus siblings like read_page, get_text, or scroll. The word 'visible' hints at a viewport-only scope but never says to scroll first or when a screenshot beats text extraction.

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

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

With no annotations, the description carries the full behavioral burden, yet it only names the input gesture (mouse wheel) and unit. It does not say which tab is affected when tab_id is null, whether the page must be focused, or whether scrolling is relative or absolute.

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

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

A single waste-free sentence, front-loaded with the action and unit. It is appropriately sized but too terse to cover the parameters the tool exposes.

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

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

For a 3-parameter tool with zero annotation coverage, no output schema, and 0% schema description coverage, the description is inadequate: direction and tab targeting are never addressed, so an agent cannot reliably call it.

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 only 'amount' (in pixels), leaving the direction enum (up/down/left/right) and tab_id entirely undocumented in both the schema and the description.

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

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

States a specific verb (scroll), resource (the page), and mechanism (mouse wheel) with a unit (pixels). It is clearly distinct from all siblings, none of which scroll, but it omits the direction dimension that the tool actually supports.

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

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

There is no guidance on when to use this versus alternatives (e.g. read_page/get_text to inspect content) or any prerequisite such as needing an active tab. An agent must infer the usage context entirely.

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

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

With no annotations, the description carries the full behavioral burden, yet it says nothing about what happens if tab_id is invalid, whether the previously active tab is affected, or whether this changes OS/browser focus. It conveys only the surface mutation of active state.

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 short, front-loaded sentence with no filler; sized appropriately for a simple single-parameter tool. It is arguably too terse given the semantic gaps elsewhere, but there is no wasted text.

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

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

For a simple one-parameter action tool with no annotations and no output schema, the description still omits the essential detail of tab_id format and error/edge-case behavior. An agent can guess the intent but not call it 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?

The single required parameter tab_id has 0% schema description coverage, and the description provides no compensating detail—no indication whether tab_id is an index, an ID string, or a title, nor how to obtain one. This is a real gap the description should have filled.

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-like action on a specific resource: activating a tab. An agent can distinguish this from list_tabs, new_tab, and close_tab by the 'make active' phrasing, but the description never names those siblings or explicitly contrasts with them.

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

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

There is no guidance on when to use this versus new_tab (create then focus) or list_tabs (discover a tab_id first), no prerequisites such as the tab needing to already exist, and no exclusions. Usage is left entirely to inference.

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

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

With no annotations, the description carries the disclosure burden well: it says content is replaced (not appended), that real key events are emitted, that select/date/time/color/range inputs take their own value syntax, and that newlines become Shift+Enter so no accidental submit occurs. It omits edge behavior such as invalid refs, elements that reject typing, or rate/timing concerns.

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

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

Front-loaded with the core action, then the format table, then the newline/submit nuance — every sentence adds information. The enumeration of input formats is dense but still readable; nothing is redundant.

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

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

For a 3-parameter, no-annotation, no-output-schema browser tool, this covers the tricky parts (value formats, select matching, Enter vs Shift+Enter) that would otherwise cause failed invocations. The unresolved 'ref' provenance and undefined failure behavior keep it from being fully complete.

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

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

Schema coverage is 0%, so the description must compensate, and it does for two of three params: 'text' gets per-input-type format rules and newline handling, and 'submit' is defined as pressing Enter afterward. 'ref' is only glossed as 'by ref' with no indication of where refs come from, which is the one material gap.

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

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

States a specific verb ('replace the content of a field') plus the mechanism ('using real key events') and the target identifier ('by ref'), which is clearly distinct from siblings like click or get_text. It does not explicitly name a sibling or say it operates on the current page, so it falls just short of 5.

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

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

Usage is implied rather than stated: the input-format enumeration tells the agent this is for data-entry fields, but there is no explicit 'use this instead of click when…' guidance or precondition (e.g., that the field must already be visible/focused). The agent must infer the choice among read_page/click/type from context.

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