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

No annotations are provided, so the description carries the full behavioral disclosure burden. It communicates a read-only checking behavior and that status info is returned, but it does not mention error behavior, side effects, or whether the tool can initiate a connection if none exists. The behavior is implied but not fully detailed.

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

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

The description is a single sentence with no redundant content. It front-loads the action and resource, and every word contributes to understanding the tool's purpose.

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

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

For a parameterless status-check tool, the description is mostly adequate, but with no output schema, 'return status info' leaves the return-value structure ambiguous. It does not specify what fields the agent should expect, such as connection state, browser version, or error details.

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 already fully covers parameter semantics. The description adds meaningful context by clarifying that the result is status info, satisfying the baseline for a parameterless 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 uses a specific verb ('Check') and resource ('browser connection') and states the expected result ('return status info'). It clearly identifies a health/status operation and is distinct from sibling tools that manipulate tabs, fetch pages, or run scripts.

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—when needing to verify the browser connection—but it does not explicitly state when to prefer it over alternatives or mention whether it should be called before other browser operations. No exclusions or comparative guidance is 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 burden of disclosing behavior. It does state that the tool returns the page state after the action, which is useful. However, it does not mention side effects of mutating actions like form submission triggering navigation, clicks that navigate away, or how failures/timeouts behave.

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 action list is front-loaded, followed by the prerequisite and return information. 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 multi-action tool with 6 parameters and no output schema, the description covers the essential flow: prerequisite tab_id, the range of actions, and the return value. It does not spell out the exact structure of the page-state return or per-action differences, but the rich parameter schema compensates for much of that.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds some value by connecting tab_id to open_tab and summarizing the action enum, but it does not add meaningfully beyond what the schema already documents for selectors, timeout, or wait_after.

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: interact with a persistent browser tab. It enumerates the supported actions (click, type, select, submit, scroll), which makes what the tool does immediately obvious and distinguishes it from tab-management siblings like open_tab and close_tab.

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

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

The description gives a clear prerequisite: 'Requires a tab_id from open_tab.' This implies when the tool is appropriate, but it does not explicitly contrast it with alternatives such as execute_javascript or fetch_page, nor does it state when not to use this tool. Usage context is present but only implicitly.

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 burden. It clearly discloses that the operation closes a tab and is intended for cleanup, which implies a mutating action. However, it does not mention side effects, error behavior, or whether the close is irreversible.

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

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

Two concise sentences, with the core action front-loaded and the usage context in the second sentence. No filler or redundant wording.

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-parameter tool with no output schema, the description is largely complete: it states what is closed, what identifier is needed, and when to use it. It could mention return/error behavior, but the simplicity of the operation makes this a minor gap.

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

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

Schema coverage is 100%, with tab_id already documented as 'The tab ID returned by open_tab'. The description restates this relationship but adds no significant new semantic detail beyond what the schema provides.

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

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

The description uses a specific verb ('Close') and resource ('persistent browser tab') and identifies the exact identifier needed ('by its tab_id'). This is clearly distinguishable from siblings like open_tab and list_tabs.

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 states when to use the tool: 'Use this to clean up tabs opened with open_tab.' It does not provide when-not-to-use guidance, but there is no alternative close tool among the siblings, so this is sufficient.

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

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

Discloses that traversal is depth-limited, output is a list with titles/summaries, and that same-domain/link_filter constraints are respected. However, with no annotations, it leaves side effects unclear (e.g., whether it opens tabs or alters browser state, auth handling, rate limits) and doesn't describe execution mode.

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

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

Three sentences pack purpose, output, and constraints without filler. Front-loaded with the core action; 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 no output schema, the description supplies a high-level return shape (pages with titles and optional summaries) and covers core constraints. It doesn't detail the exact returned item structure, error behavior, or side effects, but defaults and parameter meanings are fully documented in the schema.

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

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

Schema covers 100% of parameters with clear descriptions, so the baseline is 3. The description reinforces the role of link_filter and includes content summaries but adds no new parameter-specific 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?

States the tool's action ('Crawl'), resource ('a website'), and key behavior ('following links up to a specified depth'), plus the output ('list of discovered pages with titles and optional content summaries'). This clearly separates it from single-page siblings like fetch_page and extract_links.

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?

Implies the use case of multi-page link traversal from a URL, and mentions constraints (same-domain, link_filter), but gives no explicit 'when to use vs. alternatives' or exclusions. Siblings such as fetch_page/multi_fetch are not referenced.

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

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

No annotations are present, so the description carries the transparency burden. It usefully discloses that the script runs in the browser and must return a JSON-serializable value, but it does not mention error behavior, timeout/async semantics, or the potentially page-mutating side effects of arbitrary JS.

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 the most important usage caveat are front-loaded. Every clause adds functional 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 four-parameter tool with no output schema or annotations, the description covers execution context, return-type constraint, and tab/session behavior. It leaves minor gaps around error handling and asynchronous behavior, but an agent can reasonably decide how to invoke the tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds a little context (persistent sessions and the current-page behavior when tab_id is used), but those details mostly duplicate the existing parameter descriptions rather than substantially expanding them.

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

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

States a specific verb and resource ('Execute arbitrary JavaScript in the context of a loaded web page') and clarifies the return contract. This clearly differentiates it from sibling tools like fetch_page, open_tab, or click_and_navigate, which do not run custom JS.

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

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

Gives clear invocation context by explaining persistent sessions via tab_id and when the url parameter may be omitted. It does not explicitly compare to sibling tools or state when not to use this tool, so it falls just short of full alternative 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 disclosure burden. It mentions persistent sessions and regex filtering, but does not explain side effects such as whether a tab is created or kept open, whether redirects are followed, whether results are deduplicated, or how timeout and max_results affect behavior. The claim 'all links' is also undercut by the max_results default, which is not acknowledged.

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

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

The description is concise and front-loaded: the core action is stated first, followed by two short sentences that add useful capability context. Every sentence earns its place, and there is no redundant restatement of parameter details already present in 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?

The schema documents all five parameters well, including defaults and the url/tab_id relationship, which covers much of what an agent needs to invoke the tool. However, with no output schema and no annotations, the description leaves some behavioral questions unanswered, such as how persistent sessions are managed and what exactly is returned beyond 'links'.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's mention of regex filtering and tab_id mostly restates what the schema already documents in more detail, and it does not add meaningful semantic value beyond the schema.

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

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

The description states a specific action ('Extract all links from a web page') and mentions additional capabilities like regex filtering and tab_id reuse. It is generally distinguishable from siblings like fetch_page or web_search, though it does not explicitly differentiate itself from the similar-sounding crawl 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?

The description gives no explicit guidance on when to use this tool versus alternatives such as crawl, fetch_readable, or fetch_structured_data. The intended use is implied by the name and purpose, but the description does not state exclusions, prerequisites, or conditions that would route an agent to a sibling 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 behavioral burden. It discloses the primary action and output format, and that tab_id supports persistent sessions. However, it does not clarify side effects such as whether a new tab is opened, whether tabs remain open, or how failures/timeouts behave.

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

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

Two concise sentences with no filler. The main purpose is stated first, followed by the session capability. Every word 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?

The description plus schema covers parameters and the Markdown output, making simple calls feasible. However, with no annotations, no output schema, and a browser tool that may have side effects, it lacks guidance on tab lifecycle, required input combinations, and when to use alternatives.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters. The description adds little beyond the schema; 'persistent sessions via tab_id' restates the schema's tab_id description rather than adding new 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 clearly states the action ('Load a URL'), the resource ('URL'), and the result ('full page content as Markdown'). It also mentions persistent sessions via tab_id, which distinguishes it from simpler fetch tools. However, it does not explicitly differentiate itself from sibling tools like fetch_readable or fetch_structured_data.

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 fetch_page versus alternatives such as fetch_readable, open_tab, or crawl. The mention of persistent sessions via tab_id is a partial usage hint, but it does not explain when to prefer this tool or when to avoid it.

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

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

With no annotations, the description carries the behavioral disclosure burden and does a solid job: it reveals that navigation/ads/sidebars are removed, that it falls back to full page content when extraction is too short, and that persistent sessions are supported. It omits details like output format or side effects, but the key behavioral traits are disclosed.

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 concise sentences, each earning its place. The core behavior is front-loaded, fallback behavior follows, and the persistent-session capability is stated without fluff.

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

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

The description covers the core extraction behavior and fallback, but it does not explain the return format despite there being no output schema, nor does it offer guidance on choosing among related sibling tools. It is adequate for basic invocation but leaves notable gaps around output expectations and alternative tool selection.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds only a light conceptual layer about persistent sessions via tab_id, but most parameter meaning is already fully documented in the schema. No compensation needed or provided.

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 a specific verb and resource: 'Load a URL and extract the main article content.' It also differentiates itself from siblings like fetch_page by emphasizing readability extraction that removes navigation, ads, and sidebars, with a fallback behavior.

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

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

The description implies when to use the tool—when main article content is needed—but never explicitly contrasts it with alternatives like fetch_page or fetch_structured_data. Mentioning persistent sessions via tab_id gives some contextual guidance, but no when-not-to-use or explicit alternative routing.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It only states extraction capabilities and the existence of persistent sessions via tab_id; it does not disclose whether a new tab is opened when tab_id is omitted, whether the tab remains open afterward, whether the operation is read-only, or how sessions are cleaned up. These are material side effects for an agent to invoke the tool safely.

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 short sentences with no filler. The core capability is front-loaded, followed by a scannable list of extractable data types and one sentence about session reuse. Every word 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 annotations and no output schema, the agent learns what can be extracted but not what the return payload looks like, what side effects occur, or when this tool is the right choice among thirteen browser-related siblings. For a tool that can create or reuse persistent browser sessions, this leaves too much to inference.

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

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

The input schema already documents all four parameters with 100% coverage, including optionality, defaults, and the relationship between url and tab_id. The description adds little beyond restating the tab_id concept ('Supports persistent sessions via tab_id'), so it does not meaningfully extend the schema's parameter semantics.

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 ('Extract structured data') on a precise resource ('a web page') and enumerates the concrete data types it returns: JSON-LD, OpenGraph tags, meta tags, tables, headings, and links. That list clearly distinguishes it from sibling tools like fetch_readable, fetch_page, and extract_links, which have narrower or different extraction scopes.

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

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

The description makes the tool's domain clear and mentions the persistent-session tab_id option, so an agent can infer when structured-data extraction is wanted. However, it never explicitly says when to prefer this tool over fetch_readable, fetch_page, or extract_links, nor does it explain when to supply tab_id versus url. The guidance is implied rather than explicit.

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 'List all open browser tabs' clearly conveys a read-only enumeration behavior. It also discloses what the result will contain (URLs and titles), which is helpful beyond the tool name.

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

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

The description is a single, front-loaded sentence that communicates the action, scope, and output fields with no wasted words.

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

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

For a zero-argument listing tool, the description provides the essential information an agent needs: what is listed and what fields are returned. No output schema exists, but the description covers the meaningful output content.

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

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

The tool has zero parameters and the schema reflects that fully, so the baseline applies. The description does not need to explain any parameter semantics.

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 a specific verb and resource: 'List all open browser tabs with their URLs and titles.' It is unambiguous and informative, but it does not explicitly distinguish itself from sibling tools like browser_status or fetch_page.

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 such as browser_status, fetch_page, or open_tab. The context is simple, but the description does not state exclusions or preferred conditions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that monitors exist and can be listed or stopped, but it does not state whether start launches a background process, whether checks consume or destroy state, whether resources persist, or what side effects monitoring has. A stateful tool needs more explicit lifecycle 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?

Two sentences with no filler, front-loaded with the core purpose. The second sentence compactly maps all four actions without unnecessary elaboration.

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 action surface is covered clearly, but the broader behavior is underspecified: there is no output schema, no indication of what 'start' returns, no clarification of whether monitoring is server-side or tied to an open tab, and no cleanup or rate-limit guidance. For a stateful tool with no annotations, this leaves important gaps an agent would have to infer.

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 100%, so the schema already documents every parameter, giving a baseline of 3. The description adds some action-to-parameter intent by tying 'start'/'check'/'stop'/'list' to the action enum, but it does not meaningfully explain parameter details beyond the schema.

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

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

States a specific function—monitoring a web page for content changes—and enumerates the four supported operations. This clearly distinguishes it from one-shot sibling tools like fetch_page, screenshot, and crawl.

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 the monitoring workflow by listing start/check/stop/list, giving an agent clear operational context. However, it does not explicitly state when to choose this tool over siblings like fetch_page or crawl, and it offers no exclusions or alternative routing.

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 explain that fetching is parallel, returns Markdown, and caps at 5 URLs. However, it does not disclose what happens on partial failures, per-URL errors, malformed URLs, or whether results are returned in the original order, which is meaningful for a batch fetch tool.

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

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

The description is two sentences with no filler. The first sentence states the core action and output format, and the second provides use cases and the limit. 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 batch-fetch tool with only one required parameter and complete schema descriptions, the description covers the essential selection and invocation information well. The main gap is the lack of explicit failure/partial-response behavior, and since there is no output schema, a bit more detail about return behavior would make it fully complete.

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

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

Schema description coverage is 100%, so the input schema already documents all four parameters. The description adds only the max-5 constraint, which the schema also states, and provides no additional meaning for timeout, wait_for, or max_length_per_page. This aligns with the baseline of 3.

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 ('Fetch multiple URLs in parallel') and the resource ('multiple URLs'), and identifies the output ('return their content as Markdown'). It also distinguishes itself from sibling tools like fetch_page by emphasizing parallel batch fetching, making its 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 description provides concrete use cases: 'comparing sources or gathering information from several pages at once,' which tells an agent when this tool is appropriate. It does not explicitly name alternatives like fetch_page or crawl, nor does it state when not to use it, so it falls short of a 5.

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

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

With no annotations provided, the description discloses key behaviors: the tab is persistent, returns a tab_id, and remains open until explicitly closed or the session expires. It does not cover failure modes or resource implications, but the core lifecycle behavior is clearly stated.

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 compact sentences with the primary action first, followed by return value and lifecycle semantics. Every sentence earns its place 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?

The description covers everything needed to invoke the tool correctly: it explains what it does, what it returns, and how long the tab persists. Since there is no output schema, the explicit mention of tab_id is essential and sufficient. The schema handles parameter details, so nothing critical is missing.

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

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

Schema description coverage is 100%, so the schema fully documents both parameters. The description adds no extra semantic detail about them, but it doesn't need to; it focuses on the tool's overall 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 uses a specific verb and resource ('Open a new persistent browser tab') and distinguishes itself from siblings like fetch_page by emphasizing persistence and returning a tab_id for multi-step workflows. This makes the tool's role clear and easily 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 explicitly identifies the intended use case: multi-step workflows such as login, navigation, and form filling. It doesn't name alternative tools or state when not to use it, but the persistent-tab framing and tab_id return value imply the contrast with single-shot tools like fetch_page.

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 behavioral disclosure burden. It adds meaningful details beyond the schema: it returns a PNG, reuses persistent tabs via tab_id, and can target the current page when url is omitted. It does not mention tab lifecycle side effects when no tab_id is given, but the disclosed behavior is substantial.

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 core purpose and return type are front-loaded, followed by the key tab_id usage caveat. 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 tool with 7 optional parameters and no output schema, the description provides sufficient invocation context: what it captures, what it returns, and how tab_id interacts with url. Minor gaps remain around combining url and tab_id simultaneously and what happens when neither is provided, but individual parameter details are covered by the schema.

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

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

Schema coverage is 100%, so the baseline is met. The description adds cross-parameter meaning by clarifying that url is optional when tab_id is provided and that a selector can target a specific element. This relationship is not fully apparent from the individual schema descriptions.

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

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

The description opens with a specific verb and resource: 'Take a screenshot of a web page or a specific element.' The output format is also stated ('Returns a PNG image'), which clearly differentiates it from sibling content-fetching tools like fetch_page or fetch_readable that return HTML/text.

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

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

The description gives clear usage context for the persistent-session mode: when tab_id is provided, url is optional and the current page is captured. It does not explicitly contrast against fetch_page or web_search, but it provides enough operational guidance for when to use a tab_id versus a URL.

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 mentions that search runs through the user's real browser and that results are structured, adding useful context. However, it does not disclose potential side effects such as opening tabs, relying on existing browser state, or any rate-limiting behavior.

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

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

The description is two sentences with no filler. It front-loads the core purpose and then specifies the result structure, making it efficient for an agent to parse quickly.

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

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

For a simple search tool with one required parameter and a stated return format, the description is nearly complete. It lacks only minor behavioral details about browser side effects and limitations, which are not critical for basic 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 100%, so the schema already documents query, engine, and max_results. The description adds no parameter-specific details beyond what the schema provides, so the baseline of 3 is appropriate.

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 ('Search') and resource ('the web'), identifies the mechanism (Google or DuckDuckGo through the user's real browser), and specifies the return format (title, URL, snippet). This clearly distinguishes web_search from sibling browser tools like fetch_page or crawl.

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 clear context is that this tool should be used when a web search is needed, as opposed to fetching a specific page or crawling a site. It does not explicitly state exclusions or alternatives, but the contrast with the sibling tool set makes the intended use reasonably evident.

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