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

No annotations are provided, so the description carries the full burden, and it does disclose what is inspected, the returned payload keys, and the non-obvious side effect that failOnAuthWall:true converts the verdict into an [AUTH_REQUIRED] error rather than returning data. It does not cover latency, whether it navigates/waits, or false-positive 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?

Front-loaded with the core question, then what it reads, then the return shape, then usage, then the flag. Every sentence adds information; nothing is restated from the schema or title.

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

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

There is no output schema, and the description compensates by naming the return object's fields ({ authRequired, confidence, signals }). Combined with the usage triggers and the error-mode behavior, an agent has everything needed to call this correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds real meaning for failOnAuthWall (error vs verdict, and the harness-bucketing use case) that the schema's one-line hint only gestures at, though tabId/frameId/allFrames are left entirely to 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 verb+resource up front ('Is the tab sitting on a sign-in wall?') and immediately names the concrete signals it inspects (URL, title, password fields, sign-in controls) plus the verdict shape. An agent can distinguish this from generic readers like snapshot, get_html, or get_text without opening the schema.

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

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

Gives clear triggering contexts: 'after a navigate, or whenever a step fails unexpectedly', and frames the purpose as disambiguating 'session expired' from 'agent got lost'. It also explains the failOnAuthWall variant for harnesses. It stops short of naming a sibling tool or stating when-not to use it, so it is strong context rather than full 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, the description carries the full burden. It discloses that ops go through the same policy gate, rate limit, and error handling as direct calls, warns about concurrency safety for tab-scoped ops, and explains the payload budget behavior (replacing oversized results with summaries). This is thorough and prevents misuse.

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

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

The description is concise and front-loaded with the core purpose. Each sentence adds value: mode explanation, op format, policy/rate limit note, concurrency warning, usage example, and nesting prohibition. No fluff 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?

For a meta-tool with no output schema, the description covers the critical behavioral aspects: modes, error handling, concurrency, nesting, and payload budget. It does not explicitly describe the return format (e.g., array of results per op), but given the complexity and the fact that it's a wrapper around other tools, this is 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%, so the baseline is 3. The description adds meaningful context beyond the schema: it explains the shape of each op ({ tool, args }), the concurrency requirement for tabId, and the budget replacement behavior. This elevates it above the baseline.

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 clearly that the tool runs multiple tool calls in one request, with parallel or serial modes. It distinguishes itself from sibling tools by being a meta-tool, and the 'Cannot be nested' constraint adds further specificity.

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

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

The description gives explicit usage guidance: 'Use to drive several tabs at once (e.g. open tabs, then batch get_text across them)' and warns about the need for explicit tabId in parallel mode. It also explains the stopOnError and maxResultBytes behaviors, making it clear when to use each mode.

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. The word 'Report' implies a read-only operation and the sentence does indicate the kind of information returned, but it does not explicitly state side-effect freedom, backend interaction, or how capabilities are determined.

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 well-structured sentence with the verb and resource front-loaded, followed by concrete output details. Every phrase adds useful content and there is no 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?

For a no-parameter status tool, the description covers the major expected output categories: paired profiles, profile naming, and disabled capability flags. It does not describe the return structure or formatting, but the low complexity and absent output schema make the description 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?

The tool has zero parameters and the schema is empty, so there is nothing meaningful for the description to add. Per the baseline for zero-parameter tools, this is handled appropriately without parameter documentation.

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

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

The description uses the verb 'Report' with a specific resource, 'backend/session status', then enumerates what is included: paired browser profiles, how they were named, and capability flags. This clearly distinguishes it from the sibling status/auth/profile 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?

There is no guidance about when to use this tool relative to similarly named siblings such as auth_check or task_status, and no exclusions or alternatives are mentioned. The only implication is that it provides status information, which is too weak 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?

No annotations exist, so the description carries the full burden. It usefully explains that dedupe collapses links sharing an href (with the reason: nav/footer noise) and that limit caps the count, but says nothing about the return shape, failure on missing matches, or which frame/tab defaults apply.

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 tight sentences, front-loaded with the core action, then the two non-obvious parameter behaviors. Nothing is wasted and no filler is present.

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

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

For a 7-parameter extraction tool with no annotations and no output schema, the description leaves real gaps: the return format (href/text objects vs strings), the meaning of selector/sameOriginOnly, and default tab behavior. It covers the delimiter behavior well but not enough to be 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 only 43% (tabId, frameId, allFrames documented), so the description should compensate. It meaningfully explains dedupe and limit, but leaves selector and sameOriginOnly completely 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?

States a specific verb and resource ("Extract anchors from the page or a subtree"), which is clearly distinct from siblings like get_text, get_html, and snapshot. It does not explicitly name or contrast with those siblings, so it stops short of a 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?

No when-to-use guidance and no alternatives are mentioned. The agent must infer that this is the link-specific extraction tool versus get_html or read_as_markdown, which the description never addresses.

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

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

No annotations are supplied, so the description carries the behavioral burden. It discloses the reachability limitation ('every iframe the extension can reach') and the shape of the result, and 'List' implies a read-only, side-effect-free operation. It does not state error behavior for unreachable frames or any permission constraints, so it falls short of fully covering a no-annotation tool.

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

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

Two sentences, no filler: the first defines what is listed and returned, the second gives the trigger and the follow-up action. The most actionable content (when to reach for this tool) is placed second but still immediately readable.

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 or annotations, so the description must explain returns and behavior; it does name the returned fields (id and URL) and the frame-reachability caveat. It leaves unanswered what happens when no frames are found or when an iframe is unreachable, which for a no-annotation tool is a modest but real 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% and the single tabId parameter is already documented with its default ('agent's tab'), so baseline is 3. The description mentions frameId/allFrames:true, but those belong to other tools rather than clarifying this tool's input; it adds no syntax or format detail about tabId itself.

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 ('List the tab's frames') and defines scope precisely: 'the top document plus every iframe the extension can reach'. It also names the return contents (frame id and URL), which lets an agent distinguish it from tabs_list without opening schemas.

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 an explicit trigger condition — 'Use it when a selector that should match does not' — and a concrete next step ('pass frameId (or allFrames:true) to act inside it'). This is a when-to-use rule tied to observable failure, which is exactly what an agent needs.

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

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

With no annotations, the description carries the full burden. It discloses only that reads target the tab URL or an explicit url; it omits permission/auth requirements, whether httpOnly/secure cookies are included, and the return shape. This is thin for a network-adjacent read tool with no annotation coverage.

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 tight sentence with no wasted words, front-loaded with the verb and resource. It is efficient, though the brevity contributes to under-specification rather than maximal clarity.

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

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

No annotations, no output schema, and only 50% parameter coverage mean the description should do more. It fails to address permissions, cookie visibility rules, or the return format an agent needs to interpret results.

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

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

Schema coverage is 50%: tabId is documented inline (default agent's tab) but url has no schema description, and the description only implies url overrides the tab. It adds marginal meaning to the undocumented url parameter without fully compensating 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 (Read) plus resource (cookies) and clarifies the scope: cookies visible to the tab's URL or a supplied url. It is clear what the tool returns, though it does not differentiate itself from siblings like storage or snapshot that an agent might confuse with session data 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?

There is no when-to-use or when-not-to-use guidance, and no alternative is named. The description hints at a url override but gives no condition for choosing between the tab's URL and an explicit 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 full burden, and it does disclose two non-obvious behaviors: output is capped and truncated at a tag boundary, and password field values are always blanked (a security-relevant behavior an agent should know). It omits auth/permission requirements and error behavior, but the disclosed traits are meaningful.

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 short sentences, front-loaded with what the tool returns before the caveats. Every sentence carries information: scope, truncation behavior, and a selection tip.

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

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

For a 7-parameter tool with no output schema, the description covers the essential return-shape caveats (byte cap, tag-boundary cut, blanked passwords) that the schema cannot express. Remaining gaps — default targeting when neither ref nor selector is given, and full-payload retrieval — are partly covered by the schema's maxBytes note.

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 86%, so the schema already documents ref, tabId, frameId, maxBytes, selector and allFrames. The description adds only cross-parameter advice about maxBytes and selector rather than new per-parameter meaning, which is the expected baseline when the schema does the heavy lifting.

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 ('Get HTML of the page or an element') and immediately scopes what is returned, so an agent can tell it apart from text/markdown extraction siblings. It stops short of naming any sibling (get_text, read_as_markdown, snapshot) to differentiate itself explicitly.

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

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

Offers one concrete usage rule — narrow with `selector` rather than raising the cap — which is real guidance. However, it gives no when-to-use versus the sibling HTML/text/markdown extraction tools, and no prerequisites, so routing remains largely inferred.

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 of behavioral disclosure. 'Visible text' hints at rendered/visibility-aware extraction rather than raw markup, but nothing is said about return shape, truncation behavior, frame handling, or tab defaults beyond what the schema already states.

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 waste. Nothing is padded or 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?

With six optional parameters, no output schema, and no annotations, the description is thin: it omits return format, how ref/selector/allFrames interact, and how it relates to the several sibling tools that also read page content. The agent is left to open the schema and guess at routing.

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 all six parameters (ref, tabId, frameId, maxBytes, selector, allFrames) are already documented in the schema. The description adds no syntax, defaults, or precedence rules beyond that, so the baseline 3 applies.

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 (Get) and resource (visible text of the page or an element), which is meaningfully more precise than a generic 'read' tool. However, it does not differentiate itself from close siblings like get_html, read_as_markdown, or snapshot, leaving the agent to infer the distinction.

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 versus get_html, read_as_markdown, or snapshot, all of which return overlapping content. No mention of prerequisites (e.g., needing a ref from snapshot) or when an element-level read is preferable to a page-level read.

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 the save location (task results/ dir) and return shape (path and size, not bytes), which is genuinely non-obvious. It says nothing about failure modes, whether it waits for rendering, or permissions, so it is only partially 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?

Two sentences, front-loaded with the action and destination, and the rationale for returning only metadata is compact. The trailing 'a PDF is not something to spend context on' is mildly editorial but justifies the return-value decision.

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 an 8-parameter tool with no annotations and no output schema, the description does address the single most important unknown (what comes back and where it lands). However, it leaves error/blocking behavior and several parameters unexplained, so it is adequate but not 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 75% (scale range, pageRanges example, paper units, tabId default are all documented) with 8 optional parameters. The description adds no parameter-level meaning at all, so it does not compensate for the undocumented options like landscape or preferCSSPageSize. Baseline 3 for high coverage.

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

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

States a specific verb and resource ('Render the page to PDF') and adds the mechanism ('through Chrome's own print pipeline') plus the destination (results/ dir). An agent can distinguish it from the sibling 'screenshot' tool without opening the schema, though no sibling is named explicitly.

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

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

Usage is only implied: you reach for this when you want a PDF artifact of the current page rather than markdown, HTML, or an image. There is no explicit when-to-use/when-not guidance and no mention of alternatives like 'screenshot' or 'read_as_markdown'.

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. It explicitly states the name persists across restarts and that saved artifacts move with the profile, which are important side effects. However, it does not mention error conditions, permissions, or reversibility, so it is informative 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 two sentences with no fluff. The action is front-loaded, and the second sentence adds key behavioral context without 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?

For a simple rename tool with two string parameters and no output schema, the description covers the purpose and two important behavioral aspects. It is sufficient for an agent to understand how to call it, though it does not cover edge cases like non-existent profiles or naming constraints.

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?

Both parameters are fully described in the schema ('from' and 'to'), and the description provides a concrete example that clarifies expected formats. Since schema coverage is 100%, the description adds marginal value beyond the schema, but the example helps grounding.

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 renames browser profiles, with a concrete example ('profile-2' -> 'work'). It identifies the resource (browser profile) and the action (rename), distinguishing it from sibling profile_use which selects profiles rather than renames 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?

The description implies usage for renaming automatically named profiles, but does not explicitly state when to use it over alternatives or any exclusions. It provides context (names stick, artifacts move) but lacks direct guidance on selection criteria.

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

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

Without annotations, the description carries the full burden. It discloses two behavioral traits: storage location change and task reset. No contradictions.

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

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

Two sentences, front-loaded with purpose. Every sentence adds value with no 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?

For a single-parameter tool with no output schema, the description covers purpose, storage effect, and task side effect. It is sufficiently complete for an AI agent to use correctly.

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

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

Schema has 100% coverage, so baseline is 3. The description adds no additional meaning about the 'name' parameter beyond what the schema already provides (folder creation, sanitization).

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 'Switch' and resource 'active browser profile (identity)', clearly distinguishing it from other browser actions like navigate or click. The purpose is immediately clear.

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

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

The description explains when to use the tool by stating that subsequent actions are stored under profiles/<name>/ and that it resets the active task to 'default' unless task_new is called. It does not explicitly state when not to use it, but the guidance is adequate.

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 disclosure burden. It adds useful context that the proxy is configured per Chrome profile and that the reported IP is what remote sites see, but it says nothing about prerequisites (an active/connected browser session), whether it is a safe read, or what happens when no profile is active.

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 with no filler and the key subject (proxy + observed IP) front-loaded. The only flaw is the garbled second clause, which costs clarity but not length.

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-param status tool there is no output schema, so the description must describe the return value. It names the two returned facts (proxy, visible IP) but does not describe the shape or format of the response or any failure state, leaving the agent to guess the payload.

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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description correctly implies no inputs are needed, consistent with the empty 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 conveys what the tool surfaces — the active profile's proxy and the IP that sites observe — but it is a sentence fragment with no verb, and it never distinguishes itself from the sibling chrome_status. An agent can infer it is a read/status tool, but the purpose is only 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?

It names an alternative route ('for another IP, profile_use another profile'), which is genuine routing guidance, but it never states the positive condition for calling this tool (e.g. 'call this to verify the current egress IP'). Usage is implied rather than prescribed.

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 says nothing about authentication requirements, side effects, dynamic content handling, rate limits, or how the 'readable markdown' is produced; only the output format is mentioned.

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 with no filler. Every word contributes to stating the action, target, and output format.

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 five parameters, no annotations, and no output schema, the description is too thin. It omits usage context, behavioral traits, and any explanation of how maxBytes, frame targeting, or allFrames affect the result.

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 80%, which meets the high-coverage baseline. The description adds only a hint about subtree scope via '(or subtree)', which loosely relates to the undocumented selector parameter, but it otherwise does not clarify any parameter semantics 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 clear verb ('Read') and resource ('page (or subtree)') plus the output format ('readable markdown'). It distinguishes from siblings like get_text and get_html by naming markdown, but it does not explicitly contrast itself with those 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?

There is no when-to-use guidance, no exclusions, and no named alternatives. An agent can infer that this tool is for reading page content as markdown, but the description does not say when to choose it over get_text, get_html, or snapshot.

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 useful defaults (JPEG q70, CSS-pixel size) and the rationale (smaller than PNG). It omits what the call returns (image payload, file path, base64), and says nothing about permissions, tab targeting side effects, or rate/large-page limits.

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

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

Three tight sentences, front-loaded with the default behavior and size rationale before the overrides. No filler, though the format/quality/scale instructions are packed densely enough to require a careful read.

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

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

For a 9-parameter tool with no annotations and no output schema, the description should explain the return payload and how ref/selector/fullPage/allFrames interact. It covers the imaging knobs well but leaves selection semantics and the response shape unaddressed.

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 56%, and the description adds genuine meaning to three params: format tradeoffs, quality 1-100 as JPEG-only, and scale 2 for Retina / 0.5 to shrink. The remaining params (ref, selector, fullPage, allFrames, frameId, tabId) rely on terse schema strings, so the description only partially compensates 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 and resource ('Capture a screenshot') and clarifies the two scopes it supports (page or element). It does not, however, distinguish itself from close siblings like snapshot, print_pdf, or get_html, which an agent would need to pick between.

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

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

Gives practical guidance on format/quality/scale tradeoffs, which implies the default choice. But it never says when to prefer this over snapshot or print_pdf, nor when an element vs full-page capture is appropriate, leaving the use-vs-alternative decision 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 full burden. It usefully discloses that the last snapshot defines the diff baseline, and that password fields are masked as secret:true with no value. It omits broader behavior: return shape, auth-wall handling (only hinted via the schema's failOnAuthWall), frame scoping, and error 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?

Three tight sentences with the primary purpose front-loaded and each clause carrying weight (ref targeting, diff cost, secret fields). Parentheticals are dense but not wasteful; it could be marginally cleaner but there is 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?

For a 7-parameter, annotation-free tool with no output schema, the description covers diff, refs, and password masking but says nothing about max, tabId/frameId/allFrames scoping, interactiveOnly, or the returned tree structure. Adequate but with clear gaps an agent must infer from the schema.

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

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

Schema description coverage is 71%, so the schema documents most parameters itself (diff, tabId, frameId, allFrames, failOnAuthWall). The description adds only the diff baseline semantics and the secret-field note, not new meaning for max or interactiveOnly. Baseline 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?

States a specific artifact (accessibility snapshot of interactive elements) and the key output (refs for targeting). It implicitly distinguishes itself from get_html/get_text/screenshot by emphasizing ref-based targeting and reliability over CSS selectors, but it never names a sibling directly.

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

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

It explains the click/read loop use case and recommends diff:true as cheaper, which implies usage. However it never states when to prefer this over get_html, read_as_markdown, or screenshot, and gives no explicit exclusions or preconditions.

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 'read/write' but does not flag that set/remove mutate persistent state or that clear wipes all storage destructively, nor does it describe permissions or reversibility. The parenthetical '(or sessionStorage)' hints at a storage-type toggle but never explains how it is selected.

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, stating the resource and the operation set first. It is efficient, though the extreme terseness is closer to under-specification than to 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?

No output schema, no annotations, and a 5-parameter mutating tool with 20% schema coverage leaves the definition far from complete. An agent cannot determine per-op argument requirements, the meaning of 'session', or the destructive scope of 'clear' from this description.

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

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

Schema coverage is only 20% (just tabId), so the description must compensate. It adds almost nothing: the op enumeration duplicates the schema enum, and the sessionStorage reference does not explain the 'session' boolean. It never states that set requires value, that get/remove require key, or what happens if key is omitted on clear.

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 resource (localStorage/sessionStorage) and the full set of operations, so the agent immediately knows this is a browser storage accessor. It distinguishes itself implicitly from get_cookies, but never names or contrasts any sibling tool explicitly.

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

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

The description gives no when-to-use guidance, no prerequisites, and no routing to alternatives. An agent must infer that this is the tool for storage reads/writes versus get_cookies or the snapshot 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 must disclose behaviors. It mentions listing tabs but does not specify the format or content of the output (e.g., titles, URLs, IDs). The agent lacks insight into what the list contains.

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

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

The description is extremely concise (5 words) and front-loaded. Every word is necessary and informative.

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

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

For a simple list tool with no output schema, the description provides the basic function but fails to clarify what data is returned. It is marginally complete given the tool's simplicity.

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, so the schema is empty. The description adds value by stating the purpose, which is sufficient for a parameterless tool. Baseline 4 applies.

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 'List open browser tabs' clearly identifies the verb (list) and resource (open browser tabs). It distinguishes from sibling tools like tab_new, tab_close, and tab_select, which perform different actions.

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 for retrieving open tabs but provides no explicit guidance on when to use this tool versus alternatives (e.g., tab_select, tab_new). No when-not-to-use scenarios are mentioned.

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

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

With no annotations, the description carries full burden. It discloses directory creation and active task setting, but lacks details on overwriting behavior, error conditions, or required permissions.

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

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

Two sentences, no redundant information. The first sentence front-loads the action, and the second provides essential behavioral details concisely.

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

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

Given the simple single-parameter tool and no output schema, the description adequately explains the creation process and side effects. It could mention duplicate name behavior for completeness.

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

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

Schema description coverage is 100% with a clear parameter description. The tool description reinforces the folder creation context but adds minimal value beyond the schema.

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

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

The description clearly states 'Start a new task (run) under the active profile,' specifying the verb and resource. It distinguishes from sibling tools like tasks_list (listing) and task_status (status) by focusing on creation and activation.

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

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

No explicit guidance on when to use this tool versus alternatives (e.g., batch or tab_new). The description does not provide when-not conditions or alternative tool references.

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

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

No annotations provided, so description must carry full burden. It merely states the action and output fields, but omits behavioral traits: performance implications, permission requirements, potential for large data volumes, or edge cases (e.g., no tasks found).

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?

Single sentence, front-loaded with verb and resource. Every word adds value: 'every task', 'across all profiles', 'with sizes and download counts'. No fluff 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?

For a zero-parameter, no-output-schema tool, the description covers the essential purpose and output. However, it lacks any mention of the 'data dir' location, performance scale, or relationship to sibling task tools, missing some completeness for context-rich decision-making.

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?

No parameters in the schema; baseline 4 applies. The description adds no parameter info, but none is needed. Schema coverage is 100% by virtue of being empty.

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

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

Clearly states the verb 'List', the resource 'tasks', and the scope 'across all profiles under the data dir'. Specifies included data: sizes and download counts. Distinguishes from sibling tools like task_new and task_status by focusing on listing.

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

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

No guidance on when to use this tool versus alternatives like task_new (create) or task_status (check status). Does not mention any contextual triggers or exclusions, leaving the agent to infer usage without support.

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 should explicitly state read-only behavior. It says 'report', implying no side effects, but does not confirm it does not modify state or have rate limits. Barely adequate.

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?

Single sentence, front-loaded with purpose, no extraneous words. Excellent 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?

The description covers the key information reported (active profile/task and folder paths). No output schema exists, but the return values are implied. Slightly vague on what 'active' means, but sufficient for a simple status tool.

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

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

The input schema has zero parameters and 100% coverage, so the description does not need to add parameter details. Baseline 4 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 clearly states the tool reports the active profile/task and artifact folder paths, using a specific verb 'report' and specifying the exact resources. This distinguishes it from sibling tools like tasks_list which list all tasks.

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

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

No guidance on when to use this tool versus alternatives such as tasks_list or chrome_status. The description does not mention preconditions or when it is appropriate to call 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 full behavioral burden and mostly fails: it does not say what the default timeout is, what happens on timeout (error vs. empty return), whether the call blocks, or how failOnAuthWall/[AUTH_REQUIRED] surfaces. The appear/disappear toggle is mentioned but not tied to any parameter.

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 front-loads the core action and wastes no words. However, its brevity reflects under-specification rather than disciplined concision — key qualifiers were omitted rather than compressed.

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 an 8-parameter, zero-required tool with no annotations, no output schema, and half its parameters undocumented, one sentence is far too thin. Nothing tells the agent about blocking behavior, default timeouts, or the interaction between selector, textContains, and gone.

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

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

Only 50% of the 8 parameters are described in the schema (tabId, frameId, allFrames, failOnAuthWall); selector, textContains, gone, and timeoutMs are undocumented. The description gestures at 'selector or text' and 'appear/disappear' but never states that `gone` inverts the check or that selector/textContains are alternatives, so it does not compensate for the coverage gap.

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

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

The description states a recognizable verb and object (wait for a selector or text), so the general intent is clear. But it never explains how the appear-vs-disappear behavior is selected, nor distinguishes this from siblings like snapshot or get_text that also inspect page state. Adequate but with real gaps.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as snapshot/get_text/frames_list. An agent must infer entirely from the name that this is for blocking on page readiness.

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