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 idempotence ('if it isn't running') and that a version is returned, but says nothing about whether the call blocks until the browser is ready, resource cost, failure modes, or what happens on concurrent starts.

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 the action first and the conditional qualifier second; no 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?

An output schema exists, so the return value need not be explained, and the description still flags that a version is reported. For a zero-parameter startup tool this is nearly sufficient; only the blocking/timing behavior is left unstated.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool 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: 'Start the ochi Chrome (separate profile)', plus the side effect of reporting its version. It does not explicitly contrast with the sibling browser_status, so an agent must infer the division of labor between starting and checking 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?

The clause 'if it isn't running' implies idempotent startup and hints at when the call is appropriate, but no alternative (e.g. browser_status) is named and no explicit when-not guidance is given. Usage 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?

With no annotations, the description carries the full burden, and it usefully discloses the key side-effect boundary: this is a passive check that will not launch Chrome. It says nothing about cost, blocking behavior, or what a negative result means, but for a zero-arg status probe with an output schema those gaps are small.

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 fragments, the core question front-loaded, and the disambiguating caveat immediately after it. Nothing is wasted and nothing is buried.

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?

Return values are covered by the existing output schema and the tool is trivially simple, so the description is nearly complete. It could add one clause on when to reach for this versus browser_start, but nothing required 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 takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. The absence of arguments is consistent with a pure status probe.

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 gives a specific check ('Is the ochi Chrome running?') against a named resource, and the parenthetical 'does not start it' directly separates it from the sibling browser_start. An agent can pick this tool 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?

The exclusion 'does not start it' effectively routes the agent to browser_start when launching is needed, so the when-not case is explicit. However, browser_start is not named directly and no other usage context (e.g., call before fetch/snapshot) is given.

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 discloses nothing about authentication (Discogs marketplace data typically needs a token), rate limits, or whether the lookup is a safe read. The mention of 'shipping to the logged-in user' hints at auth context but stops short of stating 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?

A single tight sentence fragment with zero filler, and the most discriminating detail (it is one listing, not a collection) comes first. It is terse to the point of under-specification, but nothing is redundant.

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

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

An output schema exists, so return values need not be explained, yet the description still fails to state the operation or document the id argument. For even a simple one-parameter tool, the agent lacks the verb and the parameter meaning needed to invoke it confidently.

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%, and the description never mentions listing_id, its format, or where to obtain it. For the single required parameter it must compensate for the schema gap and does not.

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 resource ('One marketplace listing') and enumerates its contents, so the agent can tell it apart from discogs_search (which searches) and discogs_release (a different resource). However, it is a noun fragment with no verb, so it never actually states the operation (fetch/retrieve by id), leaving the purpose inferable rather than explicit.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as discogs_search or discogs_release despite four Discogs siblings in the tool set. The agent must guess when this single-listing lookup 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?

No annotations are provided, so the description carries the full behavioral-disclosure burden. It does not state that this is a read-only operation, whether authentication or rate limits apply, or how results are paginated or ordered.

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

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

The description is a single front-loaded sentence with no filler. It immediately states what is returned and the optional filter, and nothing needs trimming.

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 lookup with an output schema, the description covers the core purpose adequately. However, with no annotations and 0% schema description coverage, it remains thin on parameter semantics and behavioral details such as pagination or read-only status.

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. It gestures at a master release and a format filter, but does not name the parameters, explain acceptable format values, or mention the default of 'Vinyl'. It adds only marginal meaning beyond the schema titles.

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 resource and scope: all pressings of a master release, with a format filter. It is specific enough to distinguish from siblings like discogs_release or discogs_search, though it does not explicitly name alternatives.

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

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

It implies the tool is used to retrieve pressings and optionally filter by format, but offers no guidance on when to choose it over sibling tools such as discogs_release or discogs_search. There are no when-to-use or when-not-to-use statements.

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 whole behavioral burden and discloses almost nothing: read-only status is only implied by 'details', and there is no mention of authentication (Discogs token), rate limits, or error behavior for invalid IDs. Listing return fields is mild context but largely duplicated by the 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?

A single compact sentence, front-loaded with the resource and followed by the most relevant returned fields. Nothing wasteful, though the fragment style leaves it terse to the point of under-specification.

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 output schema means return values need not be explained, and the price/have/want notes add a little value. But for a tool with no annotations and an undocumented required parameter, the description should do more to explain input expectations and read-only semantics.

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% for the single required release_id, and the description never names or formats it. It does implicitly distinguish a release from a master by calling out master_id as a returned field, which is useful disambiguation, but ID type/format remains undocumented.

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 'Release details' identifies the resource and that it returns a full record, but there is no verb and no differentiation from siblings like discogs_listing or discogs_master_versions. The enumerated fields hint at a detail-fetch, yet an agent cannot tell from the text alone how this differs from the other discogs_* lookups.

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, no prerequisites, and no mention of any alternative tool. The agent must infer from the name alone that this is the per-release lookup rather than search, master versions, or marketplace listings.

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

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

No annotations provided, so the description carries full behavioral burden. It does not state whether results are paginated (per_page exists but unexplained), whether any auth is required, or what the output looks like despite an output schema existing.

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?

Very short and front-loaded; every sentence carries information. The cryptic 'format e.g. Vinyl' is terse to the point of ambiguity, but nothing is wasted.

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 4 params at 0% schema coverage, no annotations, and an output schema, the description is minimally adequate. It establishes the search context and type values but omits pagination, result shape expectations, and sibling-routing guidance an agent needs.

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. It clarifies type's accepted values (release|master|artist|label) and gives a format example, but leaves q, per_page, and format semantics vague and does not explain defaults or pagination.

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 (Search) and resource (Discogs database), which clearly distinguishes it from fetch/look/show siblings and from the item-level discogs_release/listing tools. The type enumeration further clarifies 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?

No guidance on when to use this search vs discogs_release or discogs_master_versions. The description implies discovery but gives no explicit when-to-use or when-not-to-use conditions.

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 well: it discloses the side effect that Chrome is launched automatically if needed, and explains the conditional result (site-specific extractor returns structured data, otherwise generic readable text). It omits failure modes, timeouts, and whether logged-in sessions are used, but the auto-launch disclosure is valuable context.

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?

Four short sentences, each earning its place, with the primary behavior front-loaded before usage hints and the Discogs caveat. Only minor friction from the parenthetical interrupting the opening sentence.

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-shape documentation is not required, and the description nonetheless explains the two result modes. It covers mechanism, usage, and a site-specific quirk; the main remaining gap is what max_chars controls and how failures surface.

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 adds real meaning to the URL (extractor-matching behavior and the ochi_max=<price> URL convention) but says nothing about max_chars beyond its self-explanatory name, leaving one of two parameters undocumented.

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 a web page') plus the mechanism ('through the user's own Chrome'), and explains the two extraction paths. This clearly separates it from siblings like browser_start (starts the browser) and snapshot/tabs (state inspection), so an agent can pick it without reading the schema.

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

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

Explicitly routes usage: 'Use for sites that block normal fetching (Discogs marketplace, Reddit, news)', and notes the Discogs-specific ochi_max=<price> refinement. It gives a clear positive condition but no explicit when-not-to-use or named alternative for ordinary pages, 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?

No annotations are provided, so the description bears the full burden. 'List' implies a safe read operation and it discloses that URL patterns are included, but it does not explicitly confirm read-only/non-destructive behavior or mention pagination or result limits.

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

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

A single front-loaded sentence that earns its place. Minor deduction because the term 'ochi' is undefined in the description and could confuse an agent unfamiliar with the server name.

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 the description need not explain return values. For a zero-parameter listing tool the description is nearly sufficient, with only the safety profile left implicit.

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

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

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to clarify beyond what the empty schema already conveys.

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 ('List') and resource ('site extractors') and adds what the listing contains ('their URL patterns'). It is distinguishable from siblings like fetch/look/snapshot, though it does not explicitly contrast itself with any of 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?

No explicit when/when-not guidance or named alternatives. The usage is only implied: an agent would reasonably infer this is how you discover which sites are supported before calling fetch, but that routing logic is never 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?

No annotations exist, so the description must carry behavioral load. It states 'Does not navigate or close anything,' which clarifies the side-effect profile (read-only interaction). The max_chars parameter is not explained in the description.

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, front-loaded, with no filler. Does not waste space but could mention return-value characteristics.

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 an output schema exists, the description need not explain return values. With two parameters and no annotations, the description covers the essential behavior and tab selection, though max_chars is unaddressed.

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

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

Schema coverage is 0%, so the description should compensate. It explains the tab parameter by saying 'tab number `tab` from tabs()', but gives no explanation for max_chars.

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 page in the ochi browser, the visible tab or a tab selected by number. It also clearly distinguishes this from a navigation action and from the browser-level 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?

Explains that this is used for the page the user is looking at right now or a tab from tabs(), giving context for use. No explicit exclusions or alternatives like snapshot/fetch are named, so it is clear but not a full 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?

With no annotations, the description carries the full burden and does disclose meaningful side effects: a new tab is created, it is visible, and it is left open rather than closed. That persistence detail is exactly the kind of behavior an agent cannot infer from the schema. It omits prerequisites such as whether the browser must already be running (browser_start/browser_status siblings) and any auth or rate considerations.

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 action and followed by the usage constraint; nothing is redundant. The parenthetical 'look what I found' is informal flavor, but it does reinforce intent, so it costs little.

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 side-effect tool the description covers what happens, how visible it is, and when to invoke it. The remaining gap is lifecycle context — what happens if no browser session is active — which the browser_start/browser_status siblings imply is relevant.

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

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

There is a single required 'url' parameter with 0% schema description coverage, and the description only alludes to it as 'a page' — no format, absolute-vs-relative, or scheme guidance. The parameter's intent is self-evident, so the gap is small, but the description adds nothing beyond the schema field name.

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 gives a concrete verb and target: open a page in a new visible tab of the ochi browser. That is far more specific than the bare name 'show' and clarifies the tool is user-facing rather than a silent fetch. It does not, however, explicitly contrast itself with siblings like fetch, look, or snapshot, so the agent must infer the distinction from 'visible tab'.

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?

'Use sparingly: only when they'd want to see it themselves' is an explicit use condition plus a restraint cue, which is stronger than most definitions. It stops short of naming a concrete alternative (e.g., use fetch for silent retrieval), so a 5 is not warranted.

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 disclosure burden. It reveals the side effect (writes to snapshots/) and that it saves rendered rather than raw HTML, but says nothing about overwrite behavior, permissions, or what happens on failure.

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 sentence, front-loaded with the action and destination; every clause, including the parenthetical, 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?

An output schema exists, so return values need no explanation, and this is a simple one-parameter tool. Still, with zero annotations the description should say more about the write side effect and parameter expectations to fully cover the 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% for the single 'url' parameter. The description implies the input is a page to snapshot but adds no format, scheme, or constraint details beyond the schema's bare string type.

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 ('Save') and resource ('rendered HTML of a page') plus destination ('snapshots/'), and adds the intent (write or debug an extractor), distinguishing it from siblings like fetch or look.

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?

Parenthetical names the use case – building or debugging an extractor – which implicitly tells when to prefer this over fetch/look, but it states no explicit exclusion or alternative 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?

With no annotations, the description carries the full disclosure burden, and it does indicate this is a read of existing tab state by enumerating index/title/url/visibility. It does not state whether the list is ordered, whether it is scoped to a single window, or whether hidden/background tabs are included, which are the behavioral details that matter here.

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 filler; the resource and the returned fields are both stated without redundancy or 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?

An output schema exists, so return values need not be explained, and with zero parameters there is little that must be documented. The remaining gap is disambiguation from snapshot/browser_status, which an agent selecting among the browser-inspection siblings would need.

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

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

The tool takes zero parameters, so there are no semantics to explain and the baseline of 4 applies. Schema coverage is 100% and the description adds nothing that is needed beyond that.

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 resource ('List open tabs in the ochi browser') and even enumerates the returned fields (index, title, url, visible), so the agent knows exactly what it gets. It does not, however, distinguish itself from siblings such as snapshot, browser_status, or list_extractors, which also describe browser state.

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 statement of when to call this versus browser_status, snapshot, or look when the agent needs to inspect the browser. Usage is only inferable from the name and the listed fields, not from any explicit guidance or exclusions.

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