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 post-conditions (returns a fresh snapshot) and orchestration behavior (rechecks targets, applies domain and irreversible-action gates), which hints at the allow_irreversible parameter's role. It stops short of explaining what the gates actually block, whether mutations are reversible, or failure/partial-batch semantics for the ops array.

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 no filler, and the core purpose is front-loaded before the snapshot and gating details. Efficient, though the gating sentence is somewhat jargon-dense for the space it consumes.

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?

An output schema exists, so return-value explanation is not required, yet the description adds a useful note about the fresh snapshot. For a multi-op mutation tool with no annotations and only 33% schema coverage, the description leaves meaningful gaps around the irreversible gate semantics and operation-specific requirements.

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 low (33%) and the description adds nothing about the three top-level parameters or the meaning of the nested ops fields. Critically, the 14-value action enum and per-action required fields (ref, name, text, value_key, etc.) are not clarified, even though the schema descriptions only partially cover them. The description 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?

States a specific verb (perform) and resource (manual browser operations) scoped to 'current element refs in an existing session', which distinguishes it from browser_run (new session) and browser_observe (observation only). It does not enumerate the operation set from the action enum, so the exact scope remains slightly abstract, but an agent can still tell what class of tool this is.

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

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

The phrase 'in an existing session' implies it should be used after browser_run, and 'a separate browser_observe is not needed after it' clarifies its relationship to that sibling. However, there is no explicit when-to-use guidance versus browser_navigate, browser_tabs, or browser_observe beyond that single aside, and no stated prerequisites for the session.

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

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

With no annotations, the description carries the full burden and does disclose concrete side effects: the session and its tab are destroyed and temporary handoff files are deleted. It also reassures that the shared browser is unaffected, which is genuinely useful context. It omits error/idempotency behavior for an invalid or already-closed session.

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, with the destructive action front-loaded and the non-destructive scoping note second.

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?

An output schema exists, so return values need no explanation, and for a one-parameter teardown tool the description covers destruction scope and blast radius. Minor gaps remain around failure behavior, but nothing essential to calling it 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% and the single 'session' parameter is already documented as 'Session ID returned by browser_run'. The description adds no format or constraint details beyond the schema, 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: 'Close a browser session and its tab', plus the side effect of deleting temporary handoff files. The clause 'The shared browser remains available for other sessions' scopes the operation and implicitly distinguishes it from any global shutdown, though it never names a sibling like browser_tabs or browser_resume.

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

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

Usage is implied (close a session you obtained from browser_run once finished) but there is no explicit when-to-use, when-not-to-use, or named alternative. The statement that the shared browser survives is the closest thing to a routing hint.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose a real behavioral constraint, the domain allowlist, which is valuable. But it omits failure behavior, whether navigation waits for load, and interaction with the session lifecycle.

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 no wasted words. It is well-structured but arguably too terse to convey the operation's constraints fully.

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?

An output schema exists, so return values needn't be explained. For a two-required-param navigation tool with no annotations, though, the definition leaves out session requirements, allowlist failure handling, and expected effects on the tab.

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 50%: 'session' is documented, but 'url' has no schema description and the description adds no format, allowlist-match, or resolution semantics for it. The description fails to compensate for the undocumented 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?

States a specific verb (navigate) and resource (the selected session tab), which is clearer than a generic 'browse'. However, it offers no differentiation from siblings like browser_act or browser_run that also operate within a session.

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 routing to alternatives. An agent cannot tell from the description when browser_navigate should be chosen over browser_act, browser_run, or browser_tabs.

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 call takes no action and that a screenshot path may be returned 'when safe', but says nothing about permissions, rate limits, session validity, or what 'safe' means. Partial behavioral coverage only.

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 read-only purpose. Every sentence contributes something, though the trailing screenshot clause is vague enough that it earns slightly less than a perfect score.

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

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

An output schema exists, so return-value explanation is not required, and the description covers the essential read-only purpose and detail escalation. The remaining gap is the un-explained 'screenshot' boolean against thin schema coverage, which keeps it from a 5.

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 33%: 'session' is documented in the schema, 'detail' has an enum but no prose, and 'screenshot' is entirely undocumented. The description compensates for 'detail' with the compact-vs-full guidance and hints at screenshot output, but the boolean 'screenshot' parameter remains unexplained.

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

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

States a specific verb+resource ('Read the current page') and explicitly scopes it as non-mutating ('without taking action') in an 'existing session', which separates it from action-oriented siblings like browser_act and browser_navigate. It does not name 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?

Gives a concrete conditional for the 'detail' parameter ('Use full detail when the compact snapshot omits needed content'), which tells the agent when to escalate. No explicit when-not-to-use or exclusion relative to browser_act/browser_tabs, so it is clear context without full routing.

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

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

No annotations exist, so the description carries the full burden. It does disclose one genuinely useful behavioral trait — approval is scoped to a single pending irreversible action — but omits what happens on an expired session, whether resumption is idempotent, and what happens to values already supplied.

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 continuation purpose. The scoping clause about approval earns its place by disambiguating a risky operation, though the enjambed sentence mixes three separate modes.

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?

An output schema exists, so return values need not be described, but for a 6-parameter continuation tool with nested objects, no annotations, and low schema coverage the description leaves gaps on allowed_domains semantics, secret resolution, and failure modes.

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 17%, with just 'session' documented. The description partially compensates by mapping to concepts (values, goal update, approval, irreversible action), but 'allowed_domains', the secret_ref/origins wrapper, and 'dialog.value_key' are never explained, leaving half the parameters opaque.

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 ('Continue an existing session after a handoff') and enumerates the concrete modes: supplying values, refining the goal, or approving one pending irreversible action. This implicitly separates it from browser_run (which starts a session) and browser_act, though it never names a sibling 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 phrase 'after a handoff' supplies a clear triggering condition, and the three listed activities describe when each capability applies. It stops short of stating exclusions or naming an alternative tool to use instead when no handoff has occurred.

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

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

With no annotations, the description carries the burden and does disclose meaningful behavior: Jev acts autonomously and 'hands back early with a question when unsure', plus the handoff-status semantics. This is genuine runtime behavior not expressed in the schema, though it omits any note on irreversible-action or auth implications (those live only in the 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 and the follow-up guidance is compact. It is slightly repetitive about the resume/act siblings, but every sentence carries useful routing information.

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

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

For a complex autonomous tool with an output schema, the description covers the goal, the handoff model, and the continuation path. Return-format details are correctly left to the output schema, so the remaining gaps are minor.

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 9 parameters and their nested fields thoroughly. The description adds nothing parameter-specific, 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 ('Open a new browser session and work toward a goal'), which is clear and distinct from the resume/reuse flow. It names the session-reuse siblings but does not explicitly contrast with browser_navigate, which also concerns browsing.

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

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

It explicitly tells the agent how to continue after a handoff ('continue with browser_act / browser_resume from the returned snapshot') and that the session can be reused with several siblings. However, it never states when to choose browser_run versus browser_navigate, and gives no exclusions or prerequisites.

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

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

With no annotations, the description carries the full behavioral burden, yet it does not disclose that 'close' is destructive/irreversible, what 'select' changes (active/focused tab state), or any permission requirements. The only added context is the ownership scoping phrase 'owned by a browser session.'

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 that wastes no words and enumerates the modes efficiently. It is arguably too terse, but there is no filler or redundancy.

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

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

An output schema exists so return values need not be explained, but with no annotations and only one of three parameters documented, the action-to-parameter contract (especially tab_id) is left incomplete for a tool that can also destroy state via close.

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% (just the session param). The description does not clarify that tab_id is required for select/close (it is not in the required list), how to obtain a tab_id, or how the action enum interacts with tab_id. It adds no meaning beyond the schema.

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

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

States three specific verbs (list, select, close) against a clear resource (tabs owned by a browser session). It does not explicitly contrast with siblings like browser_close or browser_run, but the resource scope is unambiguous enough for selection.

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 beyond restating the three enum actions. It does not say when to pick this over browser_close for tearing down a session, nor which action to choose in a given situation, so the agent must infer everything.

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. It states one non-behavior (does not create or change a browser session) but omits whether the tool mutates state, has side effects, requires authentication, or how the decision port behaves. This is a significant gap for a tool whose name implies decision-making.

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

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

The description is two short sentences with no wasted words, and the purpose is front-loaded before the browser-session disclaimer. It is structurally clean, though the extreme terseness leaves little room for important context.

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

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

Given two parameters, nested object schemas, and no annotations, the description is far too sparse. While an output schema exists so return values need not be explained, the description should at least clarify the state format and the typed question variants; instead it omits both.

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

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

The description names 'state' and 'typed questions,' which loosely map to the two parameters, but with 0% schema description coverage and a deeply nested anyOf schema (choice/score/noul variants, instructions, criteria), it adds almost no semantic detail. It does not explain required fields, allowed question types, or the shape of state, so an agent must infer everything from the schema.

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

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

The description states a specific verb and resources: 'Pass a state and typed questions directly to the configured decision port.' However, 'decision port' and 'typed questions' are jargon, and the description never explains what the tool actually returns or decides, leaving the purpose vague for an agent unfamiliar with this port. It does distinguish itself from browser session tools by negation, but the core outcome remains unclear.

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 only usage-oriented statement is 'This does not create or change a browser session,' which is a negative disclaimer rather than a positive when-to-use condition. There is no explicit guidance on when to choose this tool over alternatives, and the siblings are all browser_* tools, making the intended invocation context ambiguous.

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