Zamery Browser

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description earns credit by adding non-obvious lifecycle behavior: artifacts expire after roughly 30 minutes or when the user stops sharing, which materially affects retry/error handling and is not in any structured field.

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, zero filler, with the core return behavior front-loaded and the expiry caveat immediately after. Every clause carries information an agent needs.

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

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

With no output schema, the description must sketch return content, and it does so only coarsely ('metadata or the image'). It also leaves local_file (a valid mode) and the artifact_id constraint unaddressed, so an agent hitting those branches is under-informed.

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

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

Schema coverage is 0%, so the description must carry parameter meaning, yet it explains only two of the three mode values (metadata and bounded_image) and says nothing about local_file. artifact_id format is also untouched, leaving the enum's third branch and the required identifier under-explained.

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 (Return) and resource (an artifact from browser_screenshot), naming metadata vs image as the payload. It links itself to the sibling browser_screenshot as the producer, which helps an agent route between the two. Sibling differentiation is implicit rather than explicit, keeping it just 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?

It gives a usable condition for invocation: 'if its access is still valid,' plus the expiry window. However, it never states when to choose this over other read paths or what to do when access has lapsed, so 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?

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the risk profile is known. The description adds real context beyond that: the click is synthetic (untrusted), and it may submit forms or trigger consequential real actions, plus the fresh-observation prerequisite. It does not discuss failure/stale-ref 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 short sentences, front-loaded with the action and its nature, then consequences, then prerequisites. No filler, though the undefined term 'the claim' introduces mild ambiguity for such a terse note.

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 five-parameter mutation tool with no output schema, the description covers the mechanism, the side-effect risk and the inputs required. Missing only edge-case handling such as stale observation or failed click outcomes, which slightly limits 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%, including the ref pattern, context_id format and request_id retry semantics, so the schema carries the burden. The description only vaguely gestures at 'the claim' and 'a fresh observation' without mapping them to context_id/observation_id or clarifying what 'claim' refers to.

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

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

States a specific verb (click) and target (a control), and immediately qualifies the mechanism as a synthetic DOM click rather than a trusted user click. That distinction separates it from sibling interaction tools like browser_fill, browser_type and browser_key, which target inputs and keys rather than arbitrary controls.

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 gives a precondition ('Needs the claim and a fresh observation'), which tells the agent it must hold a valid claim and a snapshot-derived ref before calling. It never states when to prefer this over browser_fill or browser_key, nor what to do when the observation is stale, so usage is only implied.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds real value beyond them: the filtering semantics (unshared tabs are excluded) and an explicit prompt-injection warning that titles/URLs are page data, not instructions — a meaningful disclosure for a browser-content 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?

Three short sentences, zero filler, with the core purpose front-loaded and the safety caveat last. 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 read-only list tool whose annotations cover safety and whose sole parameter is fully documented, this is nearly complete; the scope rule and injection warning round it out. Only return format/paging is unaddressed, which is minor absent an output 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?

One optional parameter with 100% schema description coverage, so the schema already explains browser_instance_id. The description adds nothing about it, which is the appropriate baseline when the schema carries the load.

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 tabs') plus the scope qualifier ('the user shared with this agent'), which cleanly separates it from sibling browser_tab (single tab) and browser_groups. An agent can select it without opening any 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?

'Tabs that are not shared never appear' implies the usage context (enumerate shared tabs), but no explicit when-to-use or when-to-prefer-an-alternative guidance is given relative to browser_tab or browser_snapshot. Usage is inferable but not spelled out.

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?

Annotations already declare destructiveHint=true and non-idempotent, but the description adds context annotations cannot: sensitive-field refusal behavior and the required fallback to browser_handoff. "Replace" also signals that any existing value is overwritten. It does not discuss retry/reconciliation, though request_id in the schema partly covers that.

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, and the operative instruction plus the critical safety exclusion are front-loaded. Every clause 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 6-parameter mutation tool with no output schema, the description covers purpose, the sensitive-field refusal path, and the handoff alternative. Return/reconciliation semantics are delegated to the schema's request_id documentation, which is a reasonable division of labor.

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% and all six parameters are documented in-schema (ref pattern, value maxLength, context_id example, request_id retry semantics). The description adds nothing about parameters, so the 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 verb and resource ("Replace the value of an ordinary text field"), and the word "ordinary" scopes it against siblings like browser_type. It never explicitly contrasts itself with browser_type, so an agent must infer which of the two to pick for a plain text input.

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 explicit exclusions (passwords, one-time codes, payment details), states the consequence (fields are refused) and names the correct alternative (browser_handoff, which the user must use instead). This is a complete when/when-not/alternative triad.

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?

Annotations already flag destructive=true and non-idempotent, and the description adds real context beyond them: group-wide operations are refused unless every member is shared, and are blocked while the user retains control. It does not state what a failed partial add/remove leaves behind, nor the retry/reconcile behavior that the request_id field implies, keeping it below 5.

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 action-prefixed clause structure front-loads the enumeration and every clause carries information; nothing is redundant. It is a dense run-on with no paragraphing, but the density is justified by the multi-action surface.

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 10-parameter, destructive, multi-action mutation tool with no output schema, the description covers action semantics and refusal conditions but omits two things an agent needs: how the target group is identified (handle) and what create returns (a handle to use in later calls). Return-value explanation is partially excused by the absence of an output schema, but the handle omission is a genuine gap.

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

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

Schema description coverage is only 40%, and the description compensates by implicitly mapping actions to fields (update -> title/color/collapsed, move -> index, add_tabs/remove_tabs -> context_ids, activate -> context_id). However it never mentions the handle parameter, which is presumably required for every non-create action, and does not spell out the action-to-parameter mapping explicitly, so the coverage gap is only partially closed.

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 enumerates every action verb with its resource effect (create groups tabs, update renames/recolors/collapses, add_tabs/remove_tabs change membership, move repositions, activate focuses), so the tool's scope is unambiguous. It never differentiates itself from the near-identically named sibling browser_groups (the read counterpart), which is the main risk for mis-selection, 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?

Per-action guidance is explicit (which tabs may be added, when changes are refused), giving clear conditions for success versus refusal. It does not name an alternative path (e.g. browser_request_access when sharing is refused) or point to browser_groups for read-only listing, so the when-not guidance is incomplete.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful non-obvious context: only tabs shared with the agent appear as members, and the incomplete_membership flag signals hidden tabs — real behavioral value beyond the annotations.

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

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

Two tight sentences, front-loaded with the primary list action before the get variant, and the visibility caveat packed into the second sentence. Zero 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?

No output schema exists, and the description partially compensates by describing the membership scoping and the incomplete_membership signal. It is nearly complete for a read-only, zero-required-parameter tool, though the action/handle relationship could be made explicit.

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 33% (only browser_instance_id is documented), so the description carries the burden. It connects 'get one by handle' to the handle parameter and implies the two action modes, but does not explain the action/handle dependency or the default action, leaving gaps.

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 specific verbs (list, get) and a specific resource (Firefox tab groups shared with the agent), plus the visibility scope. It does not explicitly differentiate itself from the singular sibling 'browser_group', so it is clear but not fully sibling-disambiguated.

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?

'List ... or get one by handle' implicitly maps to the action=list/action=get modes, so usage is inferable. However, it never states when to prefer this over browser_group or browser_request_access, and offers no explicit exclusions.

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?

Beyond the annotations (readOnlyHint=false, idempotentHint=false), the description discloses key behaviors: the agent stops acting until the user resumes, control genuinely cannot be taken back by the agent, and claim grants a write claim without a snapshot. The note field's untrusted-display nature is covered by the schema, so remaining gaps are minor.

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

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

One terse labeled clause per action, action names front-loaded so the agent can scan for its mode, then a closing pointer to browser_status. No filler sentences.

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 stateful handoff tool with no output schema, the description covers the four modes, the pause/resume semantics, and where to check progress. It does not cover edge cases like claiming a tab that already has a snapshot, but is sufficient to call the tool correctly.

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

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

The schema documents three of four params (75% coverage), but the action enum values themselves carry no schema description – the description supplies their semantics, which is precisely the highest-value parameter information here. It adds meaning well beyond the bare enum list.

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?

Each of the four actions is given a specific, distinct meaning: request_user_takeover asks the user to act and pauses the agent, resume asks the user to hand control back, claim takes a write claim without a snapshot, release drops the claim. An agent can tell exactly what the tool does and distinguishes it from siblings by pointing to browser_status for progress.

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 gives concrete when-to-use triggers for request_user_takeover (sign-in, MFA, payment, 'anything you must not do') and clarifies that only the user can perform resume, plus a routing hint to browser_status. It lacks explicit exclusions or a comparison to browser_request_access, so 4 rather than 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?

Annotations already declare destructive=true, idempotent=false and openWorld=true, so the safety profile is covered. The description earns credit for the genuinely non-obvious caveat that the event is synthetic and default browser behaviour is not guaranteed, which warns the agent that keystrokes may not trigger native form or navigation behaviour.

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 the core action and the important caveat. No padding; the credential cross-reference is the only sentence that could be considered optional overhead.

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?

Annotations cover safety, so the description does not need to restate destructiveness, and there is no output schema to explain. However, for a mutation tool it never clarifies why an operation is destructive (e.g. a key may submit a form) nor what the call returns, leaving a modest gap.

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

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

Schema description coverage is 100%, so all six parameters including ref, key and request_id are already documented in the schema. The description adds no syntax, format or default information beyond it, 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 and resource: dispatching a synthetic keydown/keyup event on a control identified by a ref. This distinguishes it reasonably from browser_click and browser_type, though it never explicitly contrasts itself with browser_type, the closest sibling.

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 comparison to browser_type or browser_click, which are the obvious alternatives for keyboard-driven interaction. The only usage-adjacent signal is the pointer to browser_fill's credential restrictions, which implies a prerequisite rather than routing the agent.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior. The description adds outcome-state semantics and retry guidance beyond what annotations provide, which is valuable context without overreaching.

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, front-loaded with purpose, followed by an example, the possible states, and a clear warning. 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 read-status tool with no output schema, the description enumerates possible return states and the key retry constraint. The schema covers the optional browser_instance_id, so the definition is complete enough for correct 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 50%; request_id lacks a schema description, and the description only restates that it identifies the mutation without adding format or origin details. The optional browser_instance_id is already documented in the schema, so 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 verb (look up) and resource (recorded outcome of a mutation by request_id), and notes the timeout/lost-response scenario. It does not explicitly differentiate from sibling status tools, so it falls 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?

Provides a clear trigger (after a timeout or a lost response) and a strong negative guideline (never retry an unknown outcome with a new request_id). It does not name alternative tools or exclude cases, so a 4 is appropriate.

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?

Annotations already cover the safety profile (destructiveHint=false, idempotentHint=true), so the description goes further with a negative-scope list clarifying it never grants access, changes duration, resumes control, or requests URLs/capabilities. This tells the agent what the tool does NOT do, which is genuinely additive beyond the annotations.

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

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

Front-loaded with the core action in the first sentence and a supporting negative-scope clause second. Efficient, though the enumerated negative list is somewhat long relative to the tool's simplicity.

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, single-optional-parameter, non-output-schema tool, the description plus annotations supply enough to call it correctly. The main residual gap is that it doesn't position itself relative to the many sibling browser tools.

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% and the single parameter (browser_instance_id) is fully documented in the schema as needed only when several profiles are connected. The description adds no additional parameter meaning, 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 action (asking Firefox to draw the user's attention to the Zamery Browser panel) so the agent knows this is a user-prompt/attention request, not a data operation. It does not, however, name or distinguish itself from siblings like browser_handoff or browser_status.

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 by the action description; there is no explicit 'use this when X, use browser_handoff when Y' guidance or prerequisite statement. An agent must infer the context from the purpose text alone.

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

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

Goes well beyond the annotations (which only declare read-only, non-destructive, non-open-world): it discloses output bounds (longest side <= 1600 px, small JPEG), that the image is a short-lived artifact whose artifact_id expires when sharing ends, that the result includes a local file path for hosts that cannot render inline images, and that a user permission grant is required. No contradiction with readOnlyHint=true or destructiveHint=false.

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-loads the core action and its scope in the first sentence, then adds constraints, fallback behavior and lifecycle in a logical order. Dense but each sentence carries operational information; only 'so you can look at it' is mild padding.

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

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

With no output schema and a 7-parameter nested schema, the description carries the return-value burden and does it: what image comes back, how large, where the local file is, how long the artifact lives, and what permission is needed before calling. Nothing an agent needs to interpret the response 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 baseline is 3; the schema already explains rect coordinates (page-relative CSS pixels), the jpeg-vs-png tradeoff, local_file, include_image and browser_instance_id. The description's mentions of rect and JPEG mostly restate that, and the new detail (1600 px bound) concerns output rather than any parameter.

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

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

Specific verb ('Capture') plus resource ('visible viewport (or a CSS-pixel rect) of a shared tab') and the purpose of the output ('return the image so you can look at it'). This distinguishes it from DOM-oriented siblings such as browser_snapshot, which would not return a rendered image.

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 a clear usage context (visual inspection when inline image is unavailable) and a concrete fallback path ('open that file with your image viewer (for example view_image)'), plus a prerequisite ('Needs the user to have allowed screenshots'). It does not explicitly contrast itself with browser_snapshot or other observation tools, so it stops short of naming when-not-to-use.

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?

Adds substantial behavior beyond annotations: form values are never returned, hidden controls are excluded, output can be truncated (pointing at 'coverage'), taking the claim makes refs actionable while invalidating earlier refs, and credential fields are flagged. That claim/staleness interaction is exactly the non-obvious behavior an agent needs.

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 dense sentences, no filler; scope first, then exclusions/limits, then the claim semantics, then the credential safety rule. Every clause carries operational meaning.

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

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

No output schema exists, yet the description covers return content (refs), what is omitted (values, hidden controls), truncation with a pointer to coverage, and the safety-relevant credential rule. An agent can call this correctly and interpret the result without further context.

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

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

Schema coverage is 100%, so baseline is 3, but the description goes further by tying claim=true to ref usability and the staleness of prior refs — consequences the schema's one-line description does not convey. context_id and browser_instance_id get no extra treatment, which keeps it from a 5.

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

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

Opens with a specific verb and resource — 'Read the interactive controls of a shared tab' — and immediately enumerates what counts as a control (links, buttons, fields, labels). This distinguishes it from browser_screenshot (pixels) and browser_click/fill (actions on refs) without needing to name 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?

Explains the claim=true default versus false for a 'read-only look', which is the key usage fork, and states the constraint that CREDENTIAL fields must be filled by the user rather than the agent. It never explicitly routes against sibling tools, so it stops 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?

Annotations already guarantee readOnly/idempotent/non-destructive, but the description adds genuinely new traits: it functions while the browser is disconnected, and it surfaces the next-step prompt for the user. That is meaningful disclosure beyond the structured safety hints, though no return shape is given (and there is no output schema).

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?

Purpose is front-loaded in the first sentence, with the safety/next-step reassurance compactly trailing. No filler, though the parenthetical list slightly lengthens the opening clause.

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 status tool with no output schema, the description does the necessary work by enumerating what the response reports (connection, shared tabs/actions/expiry, control). Annotations cover the safety profile, so the definition is sufficient to call correctly.

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

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

Schema description coverage is 100% and the single optional browser_instance_id is already documented in-schema as needed only with multiple Firefox profiles. The description adds no parameter meaning, 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?

Specific verb ("Report") plus a precise inventory of the resource state it returns: connection status, what the user shared (tabs, allowed actions, expiry), and who is in control. This is clearly distinct from siblings like browser_mutation_status or browser_contexts, though the description never names a sibling to differentiate 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?

Tells the agent when it is usable ("Always safe to call, works while disconnected") and what it is for (finding "what to ask the user to do next"), which is strong contextual guidance. It stops short of explicitly naming alternatives for the cases where this tool is not the right choice.

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

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

Annotations declare destructiveHint=true and openWorldHint=true; the description usefully adds policy-level behavior beyond that — the permission precondition for create, the http/https restriction, the same-site constraint on user tabs, and the guarantee that the user's tabs are never closed. What it omits is retry/idempotency behavior and the consequence of reload on unsaved state.

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

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

Five compact clauses, one per action, ordered to match the enum, with the most restrictive constraint (permission requirement) attached to the first action. No filler sentences and nothing repeated from 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?

For a six-parameter, five-action mutation tool with no output schema, the description covers the decision-relevant behavior for every action and the safety boundaries around user-owned tabs. It could still say what create/navigate return (e.g. tab id for later context_id use) since there is no output schema to fall back on.

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 67% and the schema itself documents active, context_id, request_id and browser_instance_id, including the retry guidance for request_id. The description adds no parameter-level detail (no mention of url format, context_id source, or when browser_instance_id is needed), so it neither compensates nor regresses. Baseline 3 applies given the schema already carries the parameter load.

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?

Each enum action is given a concrete verb and scope: create opens a new tab, navigate goes to a URL, activate brings a shared tab forward, close_owned closes a tab you created. It distinguishes own tabs from the user's tabs, which is the key resource boundary. It stops short of explicitly differentiating itself from siblings like browser_contexts or browser_handoff.

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?

Per-action conditions are stated inline: create only 'if the user allowed it', navigate is 'any site' for your own tabs but 'same site only' for the user's tabs, and close_owned is 'never the user's tabs'. That is strong when-to-use guidance. It never names an alternative sibling tool or an exclusion case where a different tool should be chosen.

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?

Annotations already declare write, destructive, non-idempotent, and open-world behavior, so the safety profile is covered. The description adds one genuinely useful behavioral note, the shared credential restrictions with browser_fill, but leaves the actual restrictions unspecified and does not mention retry/idempotency nuance.

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 core action is front-loaded. Nothing could be removed without losing information.

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

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

No output schema exists, and the description does not describe return values or the effect of a non-idempotent, destructive insert on existing field content. With annotations carrying the safety profile and the schema fully documented, this is adequate but thin for a destructive-input 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 schema already documents all six parameters including the request_id retry semantics and the observation_id/ref linking. The description adds only the 'at the caret' behavioral detail, so the baseline of 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?

The verb-resource pairing is specific: inserting text at the caret of a text field. The phrase 'ordinary text field' hints at a contrast with browser_fill, but it never names the distinction or the sibling explicitly, so an agent must infer which tool to pick.

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 and no comparison against browser_fill, browser_key, or browser_click. The mention of browser_fill is about credential restrictions, not about which situation selects this tool over that one.

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