Colibri

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

With no annotations at all, the description carries the full burden and does disclose real traits: a 40-step cap, strict ordering, first-error/first-block halt, and diff-only response. It omits mutation/permission implications, whether state persists across calls, and the fact that some steps require prior user confirmation (that only surfaces inside 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?

Two tight sentences, front-loaded with the core behavior and limits, then the view enum with its default. No filler; only minor density loss from cramming the view options into a sentence fragment.

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?

Covers limits, ordering, failure semantics and return shape for a complex browser-automation tool with no annotations and no output schema. Still missing what a "block" is, whether browse_open must precede it, and how errors/diffs are surfaced — meaningful gaps for a 40-step mutating executor.

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%, but the covered parameter (steps) is exhaustively documented in the schema itself, so the description rightly does not repeat it. The description does add one thing the schema lacks: the default value for view ("diff (default)"), which is genuine value-add. It does not explain what full vs none mean in output terms, leaving a gap for that 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 and resource ("Run up to 40 steps in order") plus the return contract ("return only the diff; stops at the first error or block"). This distinguishes it from the read-oriented siblings (browse_view, browse_read, browse_screenshot) without naming them directly, so an agent can infer it is the executor, but full sibling differentiation is implicit rather than stated.

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

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

No explicit when-to-use/when-not-to-use guidance or named alternatives, though the execution model (ordered steps, stop at first error, diff-only return) implies it is for performing actions after inspection. The default "view: diff" hints at the intended normal path, but an agent gets no rule for choosing browse_do over browse_task or browse_open.

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 real behavior: launching a browser, automatically rejecting non-essential cookies, and two response modes. It omits error/timeout behavior, auth requirements, and what happens if a session already exists, which matters for a tool with side effects.

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?

It is short and front-loaded with no filler, but the telegraphic fragment style ('rows:false: header+counts only; filter: matching rows') makes the two most load-bearing clauses hard 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?

There is no output schema and no annotations, so the description is the only guidance, yet it leaves the return shape ('rows') undefined and gives no sibling-selection or failure-mode guidance for a browser-launching 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 0%, so the description must define all three parameters. It gestures at 'rows' (false = header+counts only) and 'filter' ('matching rows'), but never explains what a 'row' actually is or what syntax 'filter' accepts, and 'url' is undocumented beyond 'Open URL'.

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 names a specific verb and resource (open URL, starts the browser) plus concrete side behaviors (cookie rejection, returning rows). It does not, however, distinguish itself from any of the eight siblings such as browse_view or browse_search, so an agent must infer the boundary.

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: the 'rows:false' note hints at a lightweight header-only mode and 'filter' hints at narrowing results, but there is no statement of when to pick browse_open over browse_view or browse_search, nor any 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered; the description adds real behavior beyond that — text mode strips menus, cards collapses repeated results to one row each, links:true appends URLs, pdf handles open or downloaded files. It does not describe return shape or how paging interacts with max/offset.

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 key constraint 'Read without acting' is front-loaded and the pipe-delimited mode breakdown is dense but scannable. The telegraphic style occasionally sacrifices clarity (e.g., '+links:true URLs'), but there is little wasted text.

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 7 parameters, zero required, no output schema, and 14% schema coverage, the description carries most of the burden. It covers modes and ref/query well but leaves offset/paging and the meaning of max partially unexplained, and gives no indication of what the returned content looks like.

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 14%, so the description must compensate, and it largely does: every mode value is explained, ref/selector semantics are given ('body'=all), and query changes meaning per mode (find = matching lines, pdf = URL or downloaded file). The gaps are max (only half-documented in schema) and offset, whose paging semantics are never 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 and constraint ('Read without acting') and enumerates the six read modes, which makes the tool's function concrete. It implicitly distinguishes itself from the mutating sibling browse_do, but never names the resource (current page) or explicitly contrasts with browse_view/browse_search.

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 mode list implies when each mode applies (cards for 'trains, flights, products', find for searching lines), which is useful implied guidance. However, there is no explicit statement of when to prefer this over browse_view, browse_search, or browse_screenshot, so the agent must infer 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?

Annotations declare readOnlyHint=true, so safety is covered; the description goes further and discloses the token cost (~900 tokens) and the output medium (JPEG), both of which an agent needs for budgeting context. It omits what the image actually shows at default scale (full window vs viewport) and any size limits, keeping it off a 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?

Two dense sentences, cost and addressing modes front-loaded, no filler. The semicolon-and-colon compression is efficient but borders on cryptic, costing a point on readability.

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 3-param, zero-annotation-coverage, no-output-schema tool this covers the essentials: cost, format, coordinate system, and the labels flag. It does not say what ref accepts or whether ref/region can be combined, which is the main residual 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 carries the full burden and largely does: region is given as [l,t,r,b] in 0-1 normalized space, and labels:true is explained as drawing refs. Only 'ref' is left unglossed, which assumes familiarity from sibling tools and prevents 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?

Names the artifact (JPEG screenshot), the three addressing modes (window, ref, region) and the coordinate convention, so the agent knows exactly what it gets. The telegraphic noun-phrase style lacks an explicit verb and doesn't contrast itself against browse_view or browse_do by name, but the resource and scope are unambiguous.

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

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

'Only when rows are not enough (charts, canvas, layout)' gives an explicit trigger and implicitly the condition for not using it — i.e. prefer row/text output otherwise. It stops short of naming a sibling to use instead, but the alternative mode is concrete enough to route on.

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, so the description carries the burden. It usefully discloses the return shape ('n. title | url | snippet') and the no-ads behavior, but says nothing about rate limits, failure modes, or result freshness.

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

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

A single tight line with the distinctive traits front-loaded; nothing is padded. The telegraphic 'no ads' is terse but still readable.

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

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

For a simple two-parameter tool with no output schema, describing the return row format is exactly the compensation needed. Only the omission of 'query' semantics and sibling routing 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?

Only 'max' is documented, and that documentation lives in the schema, not the description. The description adds no meaning for 'query' or for how 'max' interacts with the row output, so it neither compensates for the 50% coverage nor adds value beyond the schema.

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

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

States a specific verb+resource ('Web search') plus the engine (DuckDuckGo) and the exact result format, so it is clearly distinguished from open/view/read siblings. It stops short of explicitly naming which sibling follows it, but the purpose is unambiguous.

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

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

Usage is only implied by the name and by the row format (search then presumably open a URL). Against eight siblings there is no explicit when-to-use or when-not-to-use guidance, e.g. no note that browse_open fetches a result's page.

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

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

The readOnlyHint annotation already establishes that this is a safe read-only operation, so the description does not need to cover safety. It adds some session scoping and names token usage and screenshots as the measured data, but it does not clarify the return structure or whether the values are counts, comparisons, or both.

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 short sentence fragment with no wasted text and the metric context is front-loaded. Its brevity is appropriate, though the cryptic 'vs screenshots' wording slightly weakens the structure.

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

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

For a zero-parameter, read-only stats tool, the description gives a minimal indication of what is reported: session token usage and screenshots. However, without an output schema, the description should more clearly explain what the returned statistics look like and what 'vs screenshots' means.

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?

This tool has zero parameters, so parameter semantics are trivially complete. The empty schema and 100% schema description coverage mean no additional parameter explanation is required.

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 hints at session token usage and screenshots, but the phrase 'vs screenshots' is ambiguous and does not clearly state the resource or metric returned. It is distinguishable from the action-oriented browse_* siblings only because of the tool name and title, not because the description explicitly differentiates it.

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

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

There is no guidance on when to use this tool instead of browse_screenshot or the other browse_* tools. The description does not mention prerequisites, expected context, or 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?

With no annotations, the description carries full burden. It discloses genuinely useful behavior: fuzzy field matching (synonyms, typos, languages), date normalization into a single DD/MM/YYYY [HH:MM] value, verification before submit, and a probabilistic question-return mode for uncertain params. It does not disclose failure semantics, what happens to partially-filled forms, whether submission is reversible, or auth requirements.

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?

It is dense with no filler, but it is a single run-on sentence that mixes mechanism, field types, and workflow, with the critical ask/answer behavior buried at the end. Front-loading is weak and the parenthetical date clause interrupts the flow.

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

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

For an 11-parameter tool with nested objects, no annotations, and no output schema, the description covers the core mechanics but not the workflow shape (when to call it, what a question-response cycle looks like before re-invoking) or failure behavior. Adequate to attempt a call, insufficient to call it confidently on a complex form.

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 64%, so the baseline is 3, but the description adds real meaning beyond the schema: the format expected for date-shaped params ('one DD/MM/YYYY [HH:MM]'), how 'answers' pairs with returned questions, and the gating condition for 'confirm'. It still leaves url, view, before, and confidence 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?

The description names a concrete capability: driving a form task end-to-end (map params to fields, fill selects/autocompletes/dates/checkboxes, verify, then submit/expect/extract/read). That is far more than a restated title such as 'guided task'. It stops short of stating how this differs from the close sibling browse_do, which it only mentions indirectly as a step-runner in the 'before' param.

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 rather than stated: the sentence about uncertain params returning as questions reveals a two-turn ask/answer workflow (with 'answers' resolving it), and 'confirm: only after the user OK' hints at the safety gate. There is no explicit when-to-use vs browse_do/browse_open/browse_read, nor any exclusion or prerequisite.

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?

readOnlyHint already declares this is a safe read, so the bar is lower. The description does add real value beyond annotations by explaining what scope=all pulls in (header/nav/footer) and what scope=areas returns (refs for unlabeled clickable/drop zones like icons and canvas). It says nothing about row volume, truncation, or how returned refs are consumed.

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?

It is short and front-loads the resource, but the telegraphic semicolon style drops articles and verbs, making it read like notes rather than instructions. Nothing is padded, yet clarity was traded away for brevity.

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 0% schema coverage, no output schema, and only a readOnlyHint annotation, the description should explain what a returned row/ref looks like and how refs feed into browse_do. Those gaps matter for a 3-parameter inspection tool and are not covered.

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 carries the burden; it partially does so by explaining filter, two of the three scope values, and offset. But scope=main is undefined, filter syntax (substring vs regex) is unstated, and "offset: next rows" leaves the page size unknown.

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 phrase "Current page rows" identifies the resource (rows of the current browser page) but omits an explicit verb and never states that it reads/snapshots the page. An agent can guess it inspects the active view, but nothing distinguishes it from browse_read or browse_search.

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 is given: nothing says to call this before browse_do, or when to prefer browse_read/browse_search/browse_screenshot. The scope values imply some usage but the agent must infer it.

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