jevbridge

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

Beyond the annotations (destructive, open world, non-read-only), the description discloses ordered execution, page-change reporting, new-tab following, input validation before typing, JS dialog auto-handling with dismissal by default, upload path restrictions, and the interpretation of a page that did not change as a likely missed action. This adds substantial behavioral context that annotations alone do not convey.

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 long but densely informative, with the main purpose and return behavior front-loaded, followed by a compact but complete grammar for every operation and inline examples. Each tip and note adds practical guidance rather than filler, making the length justified for the tool's complexity.

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?

Despite lacking an output schema, the description explains the return value precisely: fresh element table, changed rows plus gone refs, and a page-changed indicator. It also covers edge cases like JS dialogs, upload restrictions, new tabs, and validation failures, making it sufficiently complete for an agent to use 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 has zero property descriptions Pand the description carries nearly all of the semantic weight for the required 'ops' parameter, thoroughly enumerating each operation format, optional fields, and examples. The optional 'tabId' parameter is not explicitly defined, but the constant references to 'tabs' and 'the new tab becomes the one you drive' make its purpose inferable.

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 plainly states the tool's action: run an ordered list of operations (click, type, drag, etc.) on the target tab (e.g., 'click', 'type', 'select', 'scroll'). It also distinguishes itself from browser_observe by explaining that browser_observe returns the full table while this tool returns only changed rows when the page is mostly unchanged.

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 when-to-use and when-not-to-use guidance: use wait only when a control is absent/disabled or results are loading, prefer page-offered tools over clicking when one fits, and use click_text for custom widgets not in the table or click_xy for canvas apps. It also advises against repeating actions like re-toggling a checkbox already in the wanted state, and suggests picking a different target rather than repeating a missed action.

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?

The description goes beyond the readOnlyHint and openWorldHint annotations by specifying that the call returns pass/fail and by defining what each assertion checks. It also adds an important behavioral caveat about not treating link presence as success, which helps the agent sequence downstream actions correctly.

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 compact and front-loaded, leading with the core purpose before enumerating options. Every sentence adds a distinct piece of information—modes, return type, and a caution—so 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 read-only assertion tool, the description covers purpose, options, return value, and an important usage caveat. It is missing only minor completeness details such as how tabId is resolved and what happens when no assertion argument is provided, but these are largely inferable from the sibling tool 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?

With zero schema description coverage, the description carries the parameter-documentation burden and defines three of four parameters (contains, url_includes, ref_visible) with precise semantics in parentheses. It also imposes a 'provide one of' constraint, though it does not describe tabId or what happens if multiple or no arguments are supplied.

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

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

The description opens with a specific imperative, 'Prove an outcome instead of inferring it,' and enumerates three concrete assertion modes (contains, url_includes, ref_visible). This makes the tool's verification role clear and distinguishes it from the observational/navigational sibling 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?

It provides clear context for when to assert ('when the goal is to reach a specific result') and an explicit when-not rule ('a matching link in a list is NOT success'). It does not name sibling alternatives such as browser_observe or browser_act explicitly, but the guidance is strong enough to route behavior.

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 (which only say readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description discloses a key behavioral detail: beforeunload handling. It warns that navigation is cancelled unless dialog is accepted and that accepting may lose unsaved changes. This is valuable context not captured by 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?

The description is two sentences: the first states the main action and result; the second adds the critical caveat about dialog. It is front-loaded with the essential action and wastes no words, achieving high information density in a compact form.

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 tool has three parameters, no output schema, and minimal annotations. The description covers the main action and the dialog edge case, but misses the default behavior of tabId. Given that the schema marks tabId optional, an agent might not know whether navigation targets the current tab or a specific one without further clarification. This is a minor but real completeness 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 0%, so the description must compensate. It explains the dialog parameter well, but says nothing about tabId (optional, likely defaults to current tab) or the format/requiredness of url. The description mentions 'target tab' but does not clarify that tabId is optional or what happens when omitted, leaving a significant semantic gap for an agent.

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 ('Navigate'), a clear resource ('target tab'), and a concrete outcome ('return the element table once loaded'). It also distinguishes itself from siblings like browser_observe and browser_act by focusing on navigation, so an agent can immediately tell when to use this tool.

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

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

The description gives explicit conditional guidance for the dialog parameter: only pass 'accept' when the user is fine losing unsaved changes, and notes that navigation is cancelled otherwise. It does not compare to alternative tools, but the navigation purpose is self-evident and the dialog usage is clearly specified.

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 mark readOnlyHint and openWorldHint, and the description adds substantial behavior beyond them: refs are valid until next observation, off-screen controls are actionable, covered controls require dismissal, cross-origin frames cannot be read, and page text is untrusted data. No contradiction with 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?

Long but dense and front-loaded with the core concept and an example. Every sentence adds a distinct formatting, behavioral, or security rule; for a tool with this output complexity, the length is justified and well organized.

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, so the description carries the full burden of explaining the return format; it does so in detail with refs, flags, suffixes, iframes, and options. The only notable gap is not explicitly mapping the tabId parameter to 'target tab,' but overall behavior is fully specified.

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?

Adds concrete semantics for find ('searches the whole page... cheap on long pages') and text ('adds the visible text') beyond the schema descriptions. However, tabId is never mentioned in the description, leaving its role implied by 'target tab' rather than explicit.

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: 'Read the target tab as an element table' and enumerates control kinds (click/fill/select/upload). The title and examples make clear it is an observation tool for interactive elements, though it does not explicitly differentiate from sibling browser_read or browser_screenshot.

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 rich how-to guidance: find option for long pages, text option, ref validity, off-screen behavior. However, it never explicitly says when to use this tool versus browser_act, browser_read, or browser_screenshot; usage context is implied rather than stated.

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?

The annotations already signal read-only and open-world behavior. The description adds that the tool extracts prose-like readable text rather than element/table data, which is meaningful behavioral context. It does not mention truncation behavior or max_chars effects, but the readOnlyHint lowers the burden for safety-related disclosure.

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 well-structured sentence with the action and resource front-loaded. Every clause adds value: what it reads, what format it returns, and when it should be preferred.

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 core read behavior and output format are adequately described, and the tool is simple with only two optional parameters. However, with no output schema and no parameter documentation, the description still leaves tabId and max_chars semantics underspecified, so it is not fully complete.

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

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

Schema description coverage is 0%, so the description must compensate, but it only loosely references the 'target tab' and says nothing about max_chars. An agent cannot infer that tabId identifies a specific tab or that max_chars caps the returned text length.

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 ('Read') with a specific resource ('target tab') and clearly defines the output as 'plain readable text (article/prose content)'. It also distinguishes the tool from the 'element table' mode, so an agent can tell what this tool is for at a glance.

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 states when to use the tool: 'for pages where you need the text itself — rules, docs, articles — rather than the element table'. This gives clear context and an implicit exclusion, though it does not explicitly name a sibling tool like browser_observe as the alternative.

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 indicate readOnlyHint=true and openWorldHint=true, so the description's read-only nature is confirmed. It adds useful details like default marks behavior and the security warning about untrusted text. Lacks some parameter effects, but the 'where supported' caveat provides context. Slight gap in not explaining what happens when marks is false, but overall satisfies the standard.

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 paragraph but efficiently covers purpose, usage, and security. It front-loads the core action and then adds use-case conditions and a practical tip. The security note is a minor add-on. Could be slightly improved with bullet points for scannability, but overall it is well-structured and compact.

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 screenshot tool, the description covers the core functionality, usage scenarios, and integration with siblings. It lacks details on output format specifics (dimensions) and parameter effects, but the annotations and purpose cover the essentials. Given the tool's simplicity and existing annotations, it is nearly 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 50%, meaning marks and tabId are partially described in the schema. The description adds meaning by explaining marks as 'label controls with their refs' and clarifies that the image can be used for click_xy, but tabId is not elaborated beyond the schema. Given moderate coverage, the description does not fully compensate but is adequate.

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 it takes a screenshot of the visible viewport, with format details (JPEG, CSS pixels) and a specific purpose. It distinguishes itself from siblings like browser_observe by focusing on visual capture when the element table is insufficient.

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 explicit guidance on when to use (canvas-rendered apps, charts, visual state) and when not to (element table sufficient). Also describes how to use the output with browser_act for clicking coordinates, which is crucial for tool chaining.

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=true, but the description adds behavioral insight by explaining that the tool reports state and differentiates between two connection failure scenarios. This is valuable context beyond the structured hint, and no contradiction exists. It does not, however, describe the output format or other edge cases, which would have made it fully 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?

The description is two sentences with zero fluff. The primary action and resource are front-loaded, followed directly by a practical usage directive. Every word earns its place, and the structure makes the purpose immediately graspable.

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, read-only diagnostic tool with no output schema, the description fully covers what the tool does, when to invoke it, and what distinction it can make. Nothing an agent needs to call it correctly 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?

With zero parameters, the schema is trivially 100% covered and there is nothing to document. The baseline for no parameters is 4, and the description does not attempt to invent or describe any parameter semantics. This is appropriate for a stateless diagnostic tool.

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

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

The description uses a specific verb ('Report') and resource ('bridge + extension connection state and the currently targeted tab'). It goes beyond a generic statement by distinguishing two failure modes ('no extension connected' vs 'no tab attached'), which clarifies exactly what the tool reveals. This clearly separates it from sibling tools that observe, navigate, or act on the browser.

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

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

The description explicitly says 'Call this first if anything behaves unexpectedly', giving a clear when-to-use instruction. It explains the diagnostic value by describing what it distinguishes, but it does not mention alternative tools by name or provide when-not-to-use guidance. The context is clear, yet excludes explicit exclusions or sibling comparison.

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=true, so the agent knows this is a safe read operation. The description adds the behavior of returning the active tab as the default when omitted, and explicitly lists the fields available. This is contextual information that the schema (empty) does not provide, and it aligns with the read-only annotation.

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

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

The description is two sentences with no filler. The primary purpose is front-loaded, and the usage instruction follows immediately. Every clause earns its place, and the format is easy to parse.

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 listing tool with no parameters and no output schema, the description fully explains what is returned, the default behavior, and how to apply the result with sibling tools. Nothing an agent needs to call it correctly 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?

The tool has zero parameters, and the schema trivially covers 100% of them. The description appropriately focuses on output semantics rather than parameters, and it clarifies the default behavior (active tab) which is the only implicit parameter-like choice. Baseline for 0 parameters is 4, and the description does not need to add more.

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 verb 'List' and the resource 'open tabs in the real browser', and enumerates the returned fields (id, title, url, active). This distinguishes it from sibling tools like browser_navigate or browser_act, which perform actions rather than listing. The mention of 'real browser' also adds a specific scope.

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

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

The description provides direct guidance on how to use the returned tab ids with other tools ('Use a tab id with the other tools to target a specific tab; omit to use the active tab'). While it does not explicitly state when to call this tool vs alternatives, the instruction implies it is the prerequisite for tab-targeting operations and is clear enough for an agent to infer its role.

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