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

No annotations are provided, so the description carries the full behavioral burden. It discloses the cross-profile ID constraint and the profile prerequisite, which is genuine beyond-schema value. However, it never says what happens on a duplicate URL, what errors look like, or what permissions are needed for a mutating operation.

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 blocks: the action on the first line, the prerequisite and ID-locality caveat immediately after. No filler, and the most failure-prone constraint is stated up front.

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. But for an unannotated mutation tool with three required parameters, the description omits duplicate handling and failure behavior, leaving real gaps for an agent deciding whether a retry or a different tool is appropriate.

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 75%, so title, url, and parent_id are already documented, including the rule that parent_id must be a folder. The description adds needed meaning for the undocumented profile_id by naming profiles_list as the source and noting ID locality, but contributes nothing for the other three.

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: 'Create a new bookmark'. An agent can tell it apart from bookmarks_create_folder in the sibling list, though the description itself does not explicitly contrast the two.

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 an explicit prerequisite and a routing hint: obtain profile_id from profiles_list. It also warns that all object IDs are profile-local and must never be reused across profiles. It lacks an explicit 'use bookmarks_create_folder instead if...' exclusion, 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 carries the full burden for a mutation tool. It adds genuinely useful non-schema context — the profile-scoping rule and where to get profile_id — but says nothing about duplicate titles, permission failures, or whether the call returns the new folder's ID, all of which matter for a create operation.

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 the action, then the mandatory prerequisite. No filler or restated boilerplate; the only small inefficiency is the line break separating the two ideas rather than integrating them.

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, and all three parameters are covered between schema and prose. What's missing is failure behavior (duplicate title, invalid parent) — relevant but not blocking for an agent to call this correctly.

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

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

Schema coverage is 67% and the uncovered parameter is exactly the one the description addresses: profile_id has no schema description, and the prose explains how to obtain it and that IDs are profile-local. The parent_id type restriction is already fully documented in the schema, so the description doesn't duplicate it.

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: 'Create a new bookmark folder.' The resource noun ('bookmark folder') separates it from bookmarks_create, which plainly creates a bookmark rather than a container. It stops short of explicitly naming that sibling, so an agent must infer the distinction from the names.

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

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

Gives a clear prerequisite chain ('profile_id is required: obtain it from profiles_list') and a hard constraint ('never reuse IDs in another profile'). It never says when to use this versus bookmarks_create or when nesting via parent_id is appropriate, so the selection guidance 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 at all, the description must carry the full behavioral load. It usefully discloses the profile-scoping rule (IDs are local and never reusable), but never states whether deletion is permanent or recoverable, whether deleting a folder removes its children, or what happens on a nonexistent/sibling-profile ID.

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 paragraphs, action first, constraint second — front-loaded and free of filler. The only slight redundancy is restating that profile_id is required, which the schema's required list already enforces.

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 the parameter set is small and well-covered. However, for a destructive tool with zero annotation coverage, the description should explicitly flag irreversibility or trash semantics; that absence is the main 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 only 50% — bookmark_id is documented in the schema, profile_id is not. The description fills that gap by explaining where profile_id comes from (profiles_list) and constraining ID scope to that profile, which is meaning the schema alone does not convey.

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 ("Delete a bookmark") that unambiguously distinguishes it from bookmarks_create, bookmarks_update and bookmarks_move. It stops short of naming when this is preferred over alternatives, but the core action is unmistakable.

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 one concrete usage prerequisite — profile_id must come from profiles_list — which is genuinely actionable. It gives no guidance on when to delete versus update or move, and no exclusion cases or error handling expectations.

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 well: it discloses the line format (📁 folders, 🔖 bookmarks, ID/parent ID/index per line), the empty-folder message, the interleaving caveat when listing the whole tree, and the fact that IDs are profile-local and must not be reused. It never explicitly states the operation is read-only and non-mutating, which is the main remaining gap.

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

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

Front-loaded with purpose, then output format, then parameter semantics. Every sentence carries information, though the run is a dense block rather than cleanly separated lines, making it slightly harder to scan than it needs to be.

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 two-parameter read tool with an output schema present, almost everything an agent needs is here: scoping behavior, output shape, empty result, and the ID provenance chain. The only omission is pointing at bookmarks_search for non-structural queries.

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% (profile_id is a bare integer), and the description compensates fully: folder_id's effect on ordering and nesting is spelled out, and profile_id's origin (profiles_list) plus the profile-scoped ID constraint are explained. This is meaning the schema does not contain.

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

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

Opens with a specific verb+resource ('List browser bookmarks') and then distinguishes itself functionally: it is the ID-discovery tool that feeds bookmarks_update, bookmarks_delete, bookmarks_move and bookmarks_create. That makes it easy to separate from bookmarks_search and from the mutation siblings.

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 the two operating modes explicitly — with folder_id you get direct children in order; without it you get the whole tree — and tells the agent to obtain profile_id from profiles_list. It never names bookmarks_search as the alternative for keyword lookup, so one routing decision is left to inference.

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 so: it discloses identity preservation ('keeps its ID, unlike deleting and recreating'), recursive effects ('A folder moves with everything in it'), profile scoping ('never reuse them in another profile'), and specific refusal conditions. These are behavioral traits an agent could not infer from 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?

The core action is front-loaded in the first sentence, followed by short paragraphs grouped by topic (semantics, constraints, prerequisites). No sentence is filler; even the ID-preservation note prevents a costly delete-and-recreate workaround.

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 the remaining gaps an agent would face — how to find IDs, profile scoping, and rejected move targets — are all covered. Nothing needed to invoke this 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?

Schema coverage is 75%, and the description compensates for the undocumented profile_id by explaining how to obtain it and its scoping implications. It also adds a constraint absent from the schema — that at least one of parent_id/index must be supplied — though it does not restate the index semantics already well documented in 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 opening sentence names a specific verb and resource ('Move a bookmark or folder') and states both the destination-folder and reorder variants. It is clearly distinguishable from siblings like bookmarks_update, bookmarks_create, and bookmarks_delete.

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

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

It gives an explicit precondition ('Give at least one of parent_id and index'), names the discovery tool ('Use bookmarks_list to find IDs and the current index'), and states the prerequisite for profile_id ('obtain it from profiles_list'). It also enumerates the cases Firefox rejects, which is when-not guidance.

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 well: it discloses that folders are never matched, that results carry their own ID plus the parent folder ID (the values bookmarks_update/bookmarks_delete expect), and the exact empty-result message 'No bookmarks found'. It does not state whether matching is substring/prefix/case-insensitive, nor whether results are capped or paginated — a meaningful omission for a search endpoint with no limit parameter.

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

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

Front-loaded with the purpose, then the folder exclusion and the alternative, then result shape, then the profile prerequisite. Every sentence adds operational information; nothing is 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?

An output schema exists, yet the description still usefully flags the empty-state message and the ID/parent-ID fields needed to chain into update/delete. What remains unaddressed is query matching semantics and result-size behavior — the two things an agent most needs to trust a search result set.

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% — profile_id has no schema description and 'query' is described only as 'Search query for bookmarks'. The description compensates substantially for profile_id (required, sourced from profiles_list, IDs local to that profile) but adds nothing about how 'query' is matched against title vs URL, which is the core semantic of the 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 first line states a specific verb and resource ('Search browser bookmarks by title or URL') and immediately scopes it ('Matches bookmarks only — folders are never returned'), which separates it from bookmarks_list. An agent can distinguish this tool from its sibling without opening either 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?

It explicitly names the alternative for the excluded case ('use bookmarks_list to walk the tree instead') and gives the prerequisite path for profile_id ('obtain it from profiles_list'). It also warns against a concrete misuse pattern — reusing object IDs across profiles.

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 behavioral burden. It does disclose a critical operational constraint (profile scoping and ID locality) that annotations could never express, but it omits whether unspecified fields are left unchanged, what error results from a bad profile_id, or any permission/locking behavior. Also slightly imprecise: it implies folders can have URLs updated, while the schema restricts url to bookmarks.

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, front-loaded with purpose and followed by the blocking prerequisite. No filler, though the profile_id guidance reads as boilerplate likely repeated across the bookmark/window/tab tools.

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?

This is a small 4-parameter mutation tool with an output schema and mostly documented fields; the description covers purpose, the required prerequisite, and the cross-profile hazard that would otherwise cause silent wrong-target updates. Nothing critical to a correct invocation 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 coverage is 75% and profile_id is the undocumented parameter, which the description explicitly compensates for by telling the agent to source it from profiles_list. The optional/null semantics of title and url are covered by the schema itself, so the description adds meaning where the gap is.

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 (update) plus resource (bookmark or folder) and names the mutable fields (title and/or URL), which distinguishes it from bookmarks_move, bookmarks_delete and bookmarks_create in the sibling list. It does not explicitly say how it differs from bookmarks_move (which also mutates a bookmark), so 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?

Explicitly states the prerequisite for profile_id (obtain it from profiles_list) and warns that object IDs are profile-local and must never be reused elsewhere, which is real usage guidance. However, it gives no guidance on when to prefer bookmarks_move for re-parenting, or what to do when updating a folder versus a bookmark.

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. It does disclose a real behavioral constraint that IDs are profile-local and never reusable across profiles, which is valuable. However, for a destructive close operation it never states irreversibility or the fate of child tabs, leaving the primary risk unaddressed.

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, action stated first and the prerequisite constraint second. Every clause earns its place.

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

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

An output schema exists, so return values need no explanation, and parameter prerequisites are covered. The gap is behavioral: an unannotated destructive mutation should state what is destroyed and whether it can be undone.

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% – profile_id has no description in the schema – and the description fills exactly that hole by declaring it required and pointing to profiles_list as the source. The profile-scoping rule for all object IDs adds meaning the schema does not encode.

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?

'Close a browser window' names a specific verb and resource, and 'window' clearly separates it from the tabs_close sibling. It falls short of 5 only because it doesn't explicitly contrast itself with the other window-level tools (create_window, focus_window, get_window).

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 supplies a prerequisite workflow – obtain profile_id from profiles_list – which is genuinely actionable. It gives no when-to-use vs alternative guidance and, notably, does not say how this differs from tabs_close or what happens to open tabs when a window closes.

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 performs exceptionally well. It discloses return type ('Return JSON container metadata'), constraint behaviors ('Duplicate names are permitted'), and internal validation rules ('Firefox validates color and icon').

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 text is highly condensed, using every sentence to deliver a crucial piece of operational knowledge. It is concise without sacrificing necessary detail.

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 definition is complete for an agent. It covers data creation, return format, operational constraints, and the scope/validity of object identifiers, leaving no ambiguity for invocation.

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

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

The description adds significant semantic value beyond the schema. It specifies the dependency of 'profile_id' on 'profiles_list' and explains the global scope constraint regarding object IDs being local to a specific profile.

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 purpose is to create a persistent Firefox container. It is specific, differentiating itself from other list or update tools in the container family.

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 excellent usage guidance by stating that duplicate names are permitted. It also sets a critical prerequisite by stating that profile_id must be obtained from profiles_list.

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 reasonably well: it discloses that IDs are opaque, that default_cookie_store_id marks normal browsing, that names may repeat, and that IDs are profile-local and must never be reused elsewhere. It never explicitly states the operation is read-only or whether results are paginated, which keeps it below 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?

Front-loaded with the return shape, then the profile scoping rule. Minor redundancy between 'IDs belong to the connected profile' and 'All object IDs are local to that profile', but no sentence is wasted overall.

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 single-parameter list tool with an output schema and no annotations, it covers the required prerequisite, the profile-scoping constraint, the meaning of the default cookie store, and the non-uniqueness of names. An agent has everything needed to call it correctly and interpret the IDs.

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, and it does: it declares profile_id required, tells the agent where to obtain it (profiles_list), and explains that all object IDs are scoped to that profile. It omits the type (integer), but the semantic scope is well covered.

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 ('List Firefox containers') and even the shape of the result (cookie_store_id, name, color, icon, default_cookie_store_id). It is unmistakably the read-only listing counterpart to containers_create/update/remove, 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?

It supplies a prerequisite ('profile_id is required: obtain it from profiles_list'), which tells the agent how to call it, but not when to choose it over alternatives such as containers_update or tabs_list. Usage is only implied by the 'list containers' framing.

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 so well: it discloses the destructive scope (stored site data is removed), the concrete failure mode and error codes, the known race with browser UI, and that no cleanup happens automatically. It does not state permission/auth requirements or explicitly flag irreversibility of the removed data.

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

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

Five short sentences, action first, caveats after, zero filler. The phrasing is slightly telegraphic ("Refuses open tabs with CONTAINER_IN_USE and tab_ids"), but nothing is wasted and the ordering prioritizes what an agent needs before calling.

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 two-param destructive tool with an output schema (so return values need no explanation), the description covers preconditions, failure behavior, and profile scoping. The remaining hole is the container identifier's source, which leaves one required parameter under-specified for a delete operation.

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, and it only half does. It explains profile_id's provenance (profiles_list) and that object IDs are profile-local and non-portable, but never explains what cookie_store_id is or how to obtain it — the reader must infer the link between "named Firefox container" and that parameter 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?

Specific verb + resource ("Remove a named Firefox container and its stored site data") with the side effect (data deletion) named up front. It is trivially distinguishable from containers_list, containers_create, and containers_update 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?

Gives a real precondition and the remedy: close tabs explicitly first, otherwise the call fails with CONTAINER_IN_USE plus tab_ids. It also tells the agent where profile_id comes from (profiles_list). It stops short of naming the sibling that supplies the container identifier (containers_list), which would have made routing fully deterministic.

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 usefully discloses the key mutation semantics: the container ID survives the update and omitted properties are preserved rather than reset. It also mentions JSON metadata output, although it does not discuss error behavior such as supplying no changes or referencing an unknown container.

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 operation and its partial-update behavior before giving invocation requirements and ID scoping. Each sentence adds useful information with no unnecessary elaboration.

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 reduces the need to document return values, and the description covers most behavior needed for a safe partial update. Nevertheless, for a five-parameter mutation with undocumented schema fields and no annotations, leaving cookie_store_id’s role and acquisition unexplained is a material invocation 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?

Despite 0% schema description coverage, the text explains the update-field requirement, the source of profile_id, and the profile-local scope of object IDs. However, it never explains that cookie_store_id identifies the container to update or where to obtain it, and it gives no accepted-value guidance for color or icon.

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?

“Update a named Firefox container” gives a specific verb and resource, while “preserving its ID and omitted properties” clarifies that this is a partial update of an existing container. That distinguishes it from containers_create, containers_list, and containers_remove without requiring their schemas.

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 supplies clear preconditions: provide at least one of name, color, or icon, and obtain profile_id from profiles_list. It does not explicitly route agents to containers_list for the target identifier or state when not to use the tool, so it falls short of fully comprehensive guidance.

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 substantial work: consent-per-tab/origin, 60-second approval-prompt expiry, queued tabs waiting in turn, and the warning that object IDs are profile-local and must not be reused. It does not classify which scripts mutate page state (set-file-input, youtube-play-pause) versus which are pure reads, leaving the safety profile partly inferred.

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

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

Front-loaded with the core action, then behavioral constraints, then the required-parameter rule, then the catalog. The catalog is long but replaces a missing enum and every entry earns its place; the only slack is the preamble wording, which is slightly redundant with the 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 return values need no explanation, and the description covers the remaining agent-critical unknowns: consent flow, prompt expiry, queueing, profile scoping, and the full script inventory with argument shapes. Nothing essential to a correct first invocation 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 coverage is 75%, and the one undocumented parameter (profile_id) is compensated for directly in the description, including where to obtain it and its ID-scoping implications. The script_args semantics are also enriched beyond the schema by the per-script argument signatures (e.g. 'day [month] [year]', '[play|pause|toggle]').

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 — execute a *predefined* external script and run its JavaScript output in a tab — and immediately enumerates the concrete script catalog, which distinguishes it from the generic content_execute_script sibling. An agent knows exactly what class of operation this is without opening 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?

Gives per-script usage context (e.g. 'In a Google Calendar tab', 'In a YouTube tab'), argument syntax for each script, and the profile_id prerequisite with its source tool (profiles_list). It never explicitly says when to choose this over content_execute_script for ad-hoc JS, so the alternative-routing 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 does well: it discloses that an extension setting may require per-tab/origin user approval, that prompts expire after 60 seconds, and that queued tabs execute in turn. These are real behavioral traits (blocking, timing, user interaction) an agent needs. It stops short of saying whether execution errors surface as tool errors or in the output.

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

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

Front-loaded with the action, then supporting constraints in short lines; there is no filler. The phrase 'an optional extension setting' is slightly vague about which setting, but the overall structure is efficient and scannable.

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 the three required parameters plus approval/queueing behavior are covered. Given the tool executes arbitrary code, a note on error semantics or side effects would have closed the remaining 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 67% with profile_id undocumented in the schema; the description compensates by stating profile_id is required, how to obtain it, and that all object IDs are scoped to that profile and must not be reused elsewhere. That adds meaning beyond the schema for the one gap, though code and tab_id get no further detail.

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 first line gives a specific verb+resource (execute JavaScript code in a tab) that clearly separates it from data-reading siblings like content_get_text or content_get_html. It does not explicitly name content_execute_predefined as the alternate, so the distinction from that closest sibling is left implicit.

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 establishes prerequisites (profile_id required, obtain via profiles_list, IDs are profile-local) which is useful routing context. However it never states when to choose this over content_execute_predefined or content_load_file, so the when-to-use decision is only implied.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses the exact source (document.documentElement.outerHTML), that the page is not mutated, that truncation is marked with an ellipsis, that iframe documents are excluded, and that IDs are profile-local. It does not state whether the read is subject to any auth or timing constraints, leaving a small gap.

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

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

Three short sentences, front-loaded with the core action and size limit, then the disambiguation, then the prerequisites. Nothing is repeated and no sentence is 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?

An output schema exists, so return shape need not be explained; the description still covers scope, truncation behavior, exclusions, and the profile-id prerequisite. Everything an agent needs to invoke this correctly on the first try is present.

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%, and the undocumented parameter is profile_id — the description compensates well by marking it required, naming profiles_list as its source, and warning that object IDs are local to that profile. tab_id is only covered by the schema's own text, and the description doesn't clarify the relationship between the chosen tab and 'the main document.'

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 main document's current HTML') with an explicit 2,000-character scope bound. It is immediately distinguishable from content_get_text, which the description names directly.

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 an explicit selection rule: 'Use this for markup, or content_get_text for rendered text,' and adds a negative boundary ('Does not include iframe documents'). It also states the prerequisite that profile_id must come from profiles_list rather than being guessed.

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 does the heavy lifting: it declares the operation is non-mutating ('without changing it') and enumerates real behavioral limits (iframes excluded, lazy content not awaited, restricted Firefox pages unreadable). It stops short of describing error signals or any cost/latency characteristics, so not a full 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?

Front-loaded with the core action and primitive, then a usage/alternative sentence, then constraints, then per-parameter notes. Four short paragraphs with no repetition and nothing that could be cut without losing routing or behavioral 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?

An output schema exists, so return values need no explanation, and every other decision an agent must make — which tool, whether the page type is readable, how to size the output, where the ID comes from — is answered in the description.

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

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

Schema coverage is 67%; profile_id has no description in the schema, and the description compensates well by stating it is required, that it comes from profiles_list, and that all object IDs are profile-local and non-portable. max_length semantics (character slicing plus ellipsis on truncation, null = full text) are added beyond the schema's brief note; only tab_id gets no extra meaning.

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 current page body's rendered text') and even gives the exact extraction primitive (document.body.innerText), removing ambiguity about what 'text' means. It explicitly names the sibling content_get_html as the markup alternative, so an agent can distinguish it without opening either 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?

'Use this for readable page content, or content_get_html for markup' gives an explicit routing rule to the alternative. The description also lists when-not conditions: no iframe documents, no waiting for lazy-loaded content, and restricted Firefox pages that block content scripts.

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 and does so thoroughly: it waits for downloading to finish, returns JSON with file_id and metadata, sets a five-minute/navigation-bound handle lifetime, notes that assigned inputs remain valid, and documents a 110s download timeout.

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?

Despite its length, the description is front-loaded and dense with actionable detail. Every paragraph earns its place by covering loading behavior, script usage, input handling, cleanup, expiration, timeout, and profile scoping.

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 file-loading tool with no annotations, the description is complete enough to call correctly: it covers return shape, lifecycle, timeout, unsupported environments, required profile context, and the exact browser-side usage pattern.

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 75%, and the description adds important semantics for profile_id by stating it is required and must come from profiles_list. It also warns that all object IDs are profile-local, which is not captured in the schema. Remaining parameters are largely covered by the schema itself.

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 and resource: 'Load a server-local file for website uploads/imports.' It immediately clarifies the scope with 'does not submit it,' making the tool distinct from the follow-up script execution 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 clearly states when to use it, what it does not do, and how to proceed afterward with content_execute_script or a predefined script in the same tab. It also names constraints such as private tabs being unsupported and profile_id being required from profiles_list.

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 behavioral burden. It discloses that this is a create operation, that profile_id is required and must come from profiles_list, and that object IDs are profile-local. It does not cover permission requirements, failure modes, or side effects beyond the obvious creation of a browser window.

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, front-loaded with the core action. The second sentence is dense but every clause adds useful constraint information: required profile_id, source, and profile-local ID scoping.

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 10 parameters, one required, an output schema, and 90% schema description coverage, the structured data carries most detail. The description supplies the key missing operational context: the required profile_id, where to get it, and the profile-local ID constraint. Minor gaps remain around when to choose this over tab-creation or other window tools.

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

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

Schema description coverage is already 90%, so most parameters are documented structurally. The description adds meaningful semantics for the required profile_id by specifying where to obtain it and warning that object IDs are local to that profile and must not be reused elsewhere.

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: 'Create a new browser window.' This clearly separates it from window-management siblings like list_windows, get_window, close_window, and update_window, and from tab creation. It does not explicitly name an alternative, but the resource distinction is strong enough for correct tool 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?

The description provides a prerequisite for profile_id and says to obtain it from profiles_list, which is useful guidance. However, it does not explain when to create a window versus creating a tab or using another window tool, nor does it state exclusions or alternatives.

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 provided, the description carries the behavioral burden and does disclose that this is a read-only status check that does not change browser state or reconnect anything. It does not describe error behavior or authentication needs, but for a zero-parameter debug status tool the main behavioral trait is clearly disclosed.

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 three short sentences with no wasted language. The core purpose and safety guarantee are front-loaded, followed by the alternative tool guidance.

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 the low complexity, zero parameters, and existing output schema, the description is complete enough for an agent to call this tool correctly. It covers purpose, usage context, behavioral safety, and the relevant sibling alternative.

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, so there are no parameter semantics to explain, and the baseline for this case is 4. The schema is fully described and the absence of parameters is unambiguous.

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: reading the server's connected Firefox profile IDs and names. It also distinguishes this from the sibling tool profiles_list, which is used for windows/tabs and target discovery.

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 says when to use this tool: for a quick connection check, including when no extension is connected. It also names the alternative profiles_list and the context in which that alternative should be used.

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 discloses the core effect (fronting and focusing a window) and the profile-locality constraint, but does not describe failure behavior, permissions, or side effects beyond the focus action. The output schema reduces the need to explain return values.

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 tightly written sentences with no wasted language. The core action is front-loaded, followed immediately by the critical profile-scoping prerequisite.

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 focus tool with an output schema, the definition covers the essential profile requirement. It is still incomplete because it does not say how to obtain window_id (e.g., via list_windows) or when a sibling like get_current_window is more appropriate.

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%: window_id is documented in the schema, while profile_id is not. The description compensates for profile_id by explaining that it is required, obtained from profiles_list, and scopes all object IDs, but it adds no further meaning for window_id 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?

The description states a specific verb and resource: 'Bring a window to front and focus it.' This clearly distinguishes it from siblings like get_window, close_window, and list_windows, though it does not explicitly name those 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 gives useful prerequisite guidance for profile_id ('obtain it from profiles_list') and warns that IDs are profile-local. However, it does not explicitly say when to use this versus siblings such as get_current_window or tabs_switch, leaving usage implied rather than fully guided.

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 and does well: it says the tool reads without focusing or changing the window, and it explains profile-local ID scoping. It could add edge-case behavior, such as what happens if no window is focused, but the non-mutating and scoping semantics are clear.

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 scope and non-mutating behavior are front-loaded, followed by precise routing to alternatives and the required profile prerequisite. The four sentences are compact and each contributes necessary 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?

The description is complete for this read tool: it covers purpose, alternatives, non-mutating behavior, the required profile_id source, and profile-local ID constraints. An output schema exists, so return values do not need to be explained in prose.

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%, but the description compensates for the undocumented required profile_id by explaining where to obtain it and warning that object IDs are profile-local. It also clarifies that populate controls whether tabs are included, though it adds little beyond the schema for that optional boolean.

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 and resource: reading the profile's current, most recently focused Firefox window. It also explicitly distinguishes this from get_window and list_windows, so an agent can select it without opening sibling schemas.

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 exactly when to use this tool and names concrete alternatives: get_window for a known window_id and list_windows to inspect all windows. The profile prerequisite is also called out explicitly.

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 and does disclose the important cross-call invariant that all object IDs are profile-local and must never be reused in another profile. That is non-obvious, high-value context beyond the schema. It stops short of confirming read-only semantics or stating error behavior for an unknown window_id.

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 the core action and followed by the constraint. Every sentence earns its place, though the profile-scoping sentence reads as boilerplate likely repeated across every tool in this server.

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 the read-only nature of a 'get' is clear. The remaining gap is what happens on an invalid or cross-profile window_id, which is a minor omission for a simple retrieve operation.

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

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

Schema coverage is 67%: window_id and populate are already documented in the schema, while profile_id has no inline description. The description compensates for exactly that gap by telling the agent where profile_id comes from. It adds nothing about the populate default or the effect of disabling tab information, so it stays at baseline.

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 ("Get information about a specific window"), which an agent can distinguish from list_windows (all windows) and get_current_window (focused window) by inference. It never names those siblings explicitly, so the 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?

The description supplies a real prerequisite ("obtain profile_id from profiles_list"), which is genuine usage guidance. However it never says when to prefer this over list_windows or get_current_window, and no exclusions or failure conditions are 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 safety burden and does so well: it discloses that the operation is irreversible ("no history restore tool") and delimits blast radius ("removes history records, not the open tab, bookmarks or cookies"). It does not state whether a confirmation is required or how deletion interacts with an in-flight sync/other devices, so it stops short of full 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?

Three short sentences/paragraphs, front-loaded with the destructive action and scope, then prerequisites and alternatives. No filler; every sentence adds a constraint or a routing rule.

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. For a two-parameter destructive tool with no annotations, the description covers irreversibility, scope boundaries, prerequisites, ID locality, and alternatives — everything needed to call it correctly.

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

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

Schema coverage is only 50% — profile_id has no schema description — but the description compensates by stating it is required, where to obtain it (profiles_list), and that IDs are profile-local and must not be reused elsewhere. It also clarifies url semantics as an exact-match single URL rather than a pattern.

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 with precise scope: "Delete all history visits for one exact URL in this profile." The word "exact" plus "history visits" distinguishes it from bookmarks_delete and tabs_close without requiring the schema to be opened.

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

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

Gives explicit routing: use history_query to find the URL first, use tabs_close if the goal is to close a page instead, and notes no restore tool exists. It names the alternatives and the conditions that select them.

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 does add valuable behavioral context - IDs are profile-local and must never be reused across profiles - but says nothing about whether this is a pure read, how many results come back, or what the ordering is, 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?

Two short sentences, front-loaded with the purpose and followed by the one constraint that will cause failures if ignored. Nothing is padded.

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 two-parameter read tool with an output schema, the description covers the only real footgun (profile-scoped IDs) and the prerequisite. The remaining gap is disambiguation from history_query, which an agent must guess at.

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% (profile_id is undocumented in the schema), and the description compensates by explaining where to obtain it and warning that object IDs are scoped to that profile. The count parameter is left to its schema default of 10, which is acceptable.

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 ('Get recent browser history') that an agent can act on immediately. It does not, however, distinguish itself from the sibling history_query, so the 'recent' qualifier is the only differentiator.

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 prerequisite (profile_id must come from profiles_list), which is real usage guidance. It never says when to prefer this over history_query or what 'recent' means in terms of a time window, so the when-to-use decision is only implied.

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

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

With no annotations, the description carries the full behavioral burden and does disclose an important trait: object IDs are profile-scoped and must never be reused across profiles. It does not explicitly say the operation is read-only, whether results are ordered or paginated, or what happens when no matches exist, though the presence of an output schema reduces the need to describe return values.

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

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

Two short sentences with no wasted words. The required-parameter constraint and the profile-scoping warning are front-loaded and easy to act on before opening the schema.

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

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

For a five-parameter read tool with an output schema, the description covers the key setup requirement and profile-scoping semantics. It is incomplete in that it never routes the agent between this and history_get_recent or describes result ordering/limits beyond the schema's max_results default, which are the main remaining ambiguities.

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 80% and already documents query, start_time, end_time, and max_results well. The description adds value where the schema is silent: profile_id is required, it is an integer obtained from profiles_list, and its namespace is local to that profile. This fills the one gap in the schema rather than repeating it.

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 ('Search browser history'), which is clear enough for an agent to understand the operation. However, it does not differentiate this tool from the sibling 'history_get_recent' or explain how a search differs from retrieving recent entries, leaving the boundary between the two tools implicit.

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 'Search browser history'. The description adds a required prerequisite ('obtain [profile_id] from profiles_list') but never states when to use this tool instead of history_get_recent, history_delete_item, or bookmarks_search. It provides setup guidance rather than decision guidance.

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 supplied, so the description carries the full burden; "List" implies a read but is never stated. It does add a real behavioral constraint that IDs are profile-local and must not be reused across profiles, which is valuable context not found in the schema, but it says nothing about ordering, pagination, or what happens for an invalid profile_id.

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, the purpose stated first and the parameter prerequisite second. No filler and nothing 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?

With an output schema present, return values need no explanation, and the description covers the one undocumented parameter. Only minor gaps remain around read-only semantics and result ordering for a simple two-parameter listing 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 coverage is only 50% — profile_id has no schema description — and the description compensates by explaining where to get it and what its values mean (profile-scoped object IDs). The populate parameter is documented in the schema, so the description correctly does not duplicate it.

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

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

States a specific verb and resource ("List all browser windows") with the scope word "all", which implicitly separates it from get_window and get_current_window. It stops short of naming those siblings explicitly, so an agent must infer the distinction from the names alone.

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

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

Explains the prerequisite for the required parameter — obtain profile_id from profiles_list — which is a genuinely useful usage cue. It does not say when to prefer this over get_window, get_current_window, or tabs_list, so the choice among sibling read tools is left implied.

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

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

With no annotations, the description carries the burden, and it does disclose a meaningful behavioral constraint: object IDs are local to a profile and must not be reused elsewhere. It does not say what happens when there is no prior history entry or whether the navigation waits for load, which are relevant for an unannotated mutation tool.

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

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

Two tight sentences: the action first, then the critical profile-scoping constraint. Nothing is padded, though the second sentence could be shortened slightly.

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 an output schema present, return values need not be described, and the description covers the key calling constraint (profile_id sourcing and locality). Only edge-case behavior (no prior history) is missing, which is minor for a 2-parameter 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?

The schema describes tab_id but leaves profile_id undocumented, so the description's instruction to obtain profile_id from profiles_list and its note that IDs are profile-local add genuine meaning beyond the schema. This largely compensates for the 50% 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?

The description states a specific verb and resource ('Navigate back in browser history for a tab'), which is clear and distinct from siblings like navigation_forward or navigation_reload. It stops short of explicitly contrasting itself with those siblings, but the action 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?

It gives a prerequisite ('profile_id is required: obtain it from profiles_list'), which is real usage guidance, but it never says when to use this versus navigation_forward or when a back navigation is inappropriate (e.g., at the start of history). Usage is implied rather than fully 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?

With no annotations at all, the description carries the full behavioral burden. It usefully discloses the profile-scoping rule and the ID-locality constraint, but never says what happens when there is no forward history (no-op vs error) or what the response contains. Meaningful but incomplete for an unannotated mutation of navigation state.

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

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

The core action is front-loaded in the first sentence, and the following two sentences are short, non-redundant prerequisites. Only the profile-locality warning is generic enough to border on boilerplate, but it still 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 the required-parameter prerequisites are covered. The remaining gap is the no-forward-history edge case, which matters because an agent looping on this call has no way to know it should stop.

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%: tab_id is documented in the schema but profile_id has no description. The description compensates by naming profile_id as required, telling the agent to obtain it from profiles_list, and warning that IDs are profile-local. That is real added meaning above the schema, short of a full enumeration of parameter behavior.

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 ('Navigate forward in browser history') plus the scope ('for a tab'), which cleanly separates it from navigation_back, navigation_reload, and navigation_go_to_url. An agent can select this 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 word 'forward' implies the when-to-use case against navigation_back, and the profiles_list prerequisite is spelled out. However, there is no explicit guidance on when this fails or when to prefer navigation_go_to_url, so the routing signal is only implied.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It explains the profile_id prerequisite and ID locality, but does not state whether navigation waits for page load, what happens on invalid tabs or URLs, whether permissions are required, or other navigation-specific behavior.

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

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

The description is front-loaded with the core action and followed by the critical prerequisite in two tight sentences. 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?

For a three-parameter navigation tool with an output schema, the description covers the essential profile scoping and retrieval requirement. It could more explicitly say where tab_id comes from and describe navigation behavior, but it is adequate overall.

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

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

Schema coverage is 67%, with profile_id lacking a schema description. The description compensates well by explaining that profile_id must come from profiles_list and that all object IDs are local to that profile and must not be reused in another profile.

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, resource, and scope: navigate to a URL in a tab. This clearly distinguishes it from sibling navigation actions such as navigation_back, navigation_forward, and navigation_reload.

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 a clear prerequisite: profile_id must be obtained from profiles_list. It also warns that all object IDs are local to a profile and must not be reused elsewhere, though it does not explicitly compare this tool against navigation_back/forward/reload alternatives.

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 provided, the description carries the full behavioral burden and does so well: it discloses that reloading may discard unsaved state, triggers new network requests, bypass_cache requests a fresh load, and returns as soon as reload is issued rather than after page load completes. It also notes that request monitors or content reads must wait for the page itself, which is exactly the kind of timing detail an agent needs.

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

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

The description is front-loaded with the core action and alternative, then layers on necessary behavioral details in short paragraphs. Every sentence adds actionable context without repetition.

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 is simple in schema but has important timing and state side effects, and the description covers purpose, alternatives, prerequisites, cache behavior, unsaved-state risk, and asynchronous return semantics. An output schema exists, so return values need not be explained.

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

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

Schema coverage is 67%, with tab_id and bypass_cache already described in the schema. The description adds meaningful semantics for the otherwise undocumented profile_id by stating it is required, must come from profiles_list, and that all object IDs are local to that profile and must not be reused elsewhere.

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: reload a page in a tab. It explicitly distinguishes this from navigation_go_to_url, which is used to choose a different URL, so an agent can select the correct navigation tool without opening schemas.

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

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

It gives explicit when-to-use guidance: refresh the tab's current URL with this tool, or use navigation_go_to_url to navigate elsewhere. It also names the prerequisite for profile_id and warns about unsaved page state, covering both selection and safe invocation.

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 discloses key behaviors: read-only (does not switch profiles or focus windows), volatile IDs on reconnect, name repetition or unavailability, and separate reporting of per-profile window errors. This is rich for an unannotated tool, though rate limits or exact response structure are not covered.

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 front-loaded with purpose and usage, then moves to behavioral caveats. It is slightly verbose but every sentence contributes relevant information; 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 return values need not be explained. The description covers purpose, usage, parameter meaning, and behavioral traits (IDs changing, name ambiguity, error handling). It is nearly complete for an agent to call the tool correctly.

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

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

Schema coverage is 100%, so the schema already defines the 'populate' parameter. The description adds a use-case hint ('inspect tab titles/URLs to choose a target; False omits tabs'), but this largely paraphrases the schema and does not introduce substantial new semantic detail.

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 verb and resource ('Discover connected Firefox profiles, their real names and windows'), clearly distinguishing it from siblings like list_windows or containers_list. It also explicitly states the scope of IDs (window, tab, group, container, monitor) belonging to that profile.

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 explicit when-to-use guidance: 'Use this first to choose a profile_id for browser commands, and again after a disconnect or server restart.' It also names an alternative ('Use list_windows for windows in one known profile'), making the routing decision unambiguous.

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 largely meets it: it discloses that no network request is made, that bodies may be truncated by max_body_size, that non-text or unmonitored content types return content: null with a size instead, and that request_headers is always empty. It does not explicitly declare read-only semantics or say whether capture state is affected, leaving a small gap.

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?

Content is front-loaded with the action and the key behavioral caveat, and each paragraph carries a distinct piece of information. A few clauses duplicate the schema's 'accepted and ignored' notes, which is minor waste for an otherwise tight block.

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, yet the description still surfaces the one non-obvious return behavior (null content with size filled in for non-text bodies). Combined with prerequisites, truncation, and ID locality, an agent has everything needed to invoke this correctly on the first attempt.

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 83%, so the baseline is 3; the description earns above that by explaining where each required ID originates and by stating that all object IDs are profile-local and must not be reused across profiles — a constraint the schema cannot express. The include_binary and save_* caveats largely restate schema text, so it is not 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?

States a specific verb and resource ('Read a captured request's stored metadata and text body') and immediately distinguishes itself from sibling reads by noting it makes no new network request, separating it from content_get_text and navigation tools. An agent can locate this tool's role in the capture workflow 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?

Gives an explicit prerequisite chain: monitor_id comes from requests_start_monitoring and request_id from requests_list_captured, and profile_id from profiles_list. That effectively routes the agent to the right prior calls. It stops short of naming a when-not-to-use case or an alternative for live content, so it lands at 4 rather than 5.

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

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

With no annotations, the description carries the burden well: it discloses eventual-consistency semantics ('a request appears here once it has completed, so a page navigation started a moment ago will not be in the list yet'), confirms the read is non-mutating, and warns that object IDs are profile-local and must never be reused across profiles. It stops short of mentioning pagination, result caps, or ordering, which are real behavioral traits for a list endpoint.

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 core purpose is front-loaded in the first sentence, followed by the timing caveat and then the workflow chain. Every sentence carries information, though the paragraph could be broken into tighter lines for scanning.

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 two-parameter list tool with an output schema, the description supplies everything the schema cannot: prerequisite ordering, ID provenance, profile scoping, and the async-visibility caveat. Return shape is correctly left to the output schema.

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

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

Schema coverage is only 50% and profile_id has no schema description at all, but the description fully compensates: it states profile_id is required, where to obtain it (profiles_list), and that all IDs are scoped to that profile. monitor_id's provenance is likewise tied to requests_start_monitoring.

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

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

States a specific verb and resource — 'List all captured request summaries from a monitoring session' — and immediately scopes it against siblings (requests_start_monitoring for capture, requests_get_content for bodies). An agent can distinguish it from every other requests_* tool without opening a 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?

Gives an explicit ordered workflow: obtain profile_id from profiles_list, start with requests_start_monitoring, reuse its monitor_id here, then feed a returned request_id to requests_get_content. It also names what the tool does not do ('without starting or stopping capture'), covering the when-not case.

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 so: it discloses memory cost, that monitors cannot be listed, the full lifecycle (client disconnection stops monitors; profile disconnection clears monitors and captured data, but stored captures remain readable until then), and the requirement to stop when finished. It also states that object IDs are profile-local and must never be reused elsewhere.

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 purpose is front-loaded in the first sentence, and each subsequent sentence carries distinct operational information (ordering, sibling routing, lifecycle, ID provenance) rather than restating the name. Paragraphing separates the call contract from the cleanup caveats.

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, yet the description still flags the crucial monitor_id handoff to requests_list_captured, requests_get_content and requests_stop_monitoring. For a stateful monitoring-start tool with 4 params, nothing needed to invoke or clean up 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?

Schema coverage is 75 percent, and the description compensates for the gaps: profile_id has no schema description but the description says to obtain it from profiles_list, and tab_id omission is restated as capturing across the profile. It adds the monitor_id return-value contract used by three sibling tools. The remaining option fields (body size, content types) are left to 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 first sentence states a specific verb (start capturing), resource (future web requests), and scope (matching URL patterns in a profile). It is immediately distinguishable from its siblings requests_stop_monitoring and requests_list_captured, which are named in the body.

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 to start before triggering navigation or other traffic, and explicitly routes the agent away from this tool when reading an existing monitor: 'use requests_list_captured to read an existing one instead.' It also states the condition for omitting tab_id (capture across the profile).

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 so: it discloses no-wait semantics, the ignored drain_timeout, post-stop data availability, the MONITOR_NOT_FOUND failure mode, and the profile-scoping constraint on all IDs. That covers destruction scope, error behavior, and identity scoping in one place.

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

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

Front-loaded with the action and return, then a second paragraph covering timing, data persistence, errors, and profile scoping. Every sentence conveys operational information; none restate the tool name or schema types.

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?

Output schema exists, so the brief mention of 'capture totals' suffices. For a zero-annotation, destructive-ish stop operation, the description supplies timing semantics, error codes, and cross-profile ID safety — nothing material 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 coverage is only 67%, and the undocumented parameter is profile_id — the description compensates fully by saying it is required, obtainable from profiles_list, and that IDs are local to that profile. It also clarifies drain_timeout's accepted-but-ignored behavior, adding meaning beyond the schema's default of 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?

States a specific verb and resource ('Stop one monitor immediately and return its capture totals'), including the side effect of returning totals. It is clearly distinguishable from requests_start_monitoring, requests_list_captured, and requests_get_content, which are named as the surrounding workflow.

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 says when to call it ('when no more traffic needs capturing') and where the monitor_id comes from (requests_start_monitoring). It also states that drain_timeout is ignored and that already-captured records remain reachable via the sibling list/get tools, so the agent knows what happens next.

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 provided, the description carries the behavioral burden and does well: it discloses that a filename writes the image to disk and returns a success message plus path, while omitting it returns an inline base64 data URL and may be large. It also warns that profile-scoped object IDs must not be reused across profiles.

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 front-loaded with the purpose, then covers return behavior and required profile context in three tight paragraphs. Every sentence adds useful operational detail without waste.

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 an output schema and high schema coverage, and the description still usefully explains output modes and profile requirements. It is nearly complete, though the prose does not mention window_id capture even though the schema includes it.

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 high at 83%, so the schema already documents most parameters. The description adds useful semantics for profile_id sourcing, local object ID scope, and filename-dependent output behavior, though it does not elaborate on format or quality 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?

The description uses a specific verb and resource: "Capture a screenshot" of a tab. It clearly distinguishes between capturing the visible tab and capturing the tab identified by tab_id, so an agent can understand the core action immediately.

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 explains the key usage split between passing a filename and omitting one, including the resulting return behavior. It also states that profile_id is required and must come from profiles_list, but it does not explicitly name alternatives 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?

Since no annotations exist, the description must carry the burden. It discloses critical operational behaviors like what happens when the last tab is closed, the non-existence of a 'restore' feature, and the failure mode for invalid IDs.

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 information-dense but follows a logical flow: function -> usage instructions/alternatives -> constraints/warning. The critical warnings about ID scope are placed effectively at the end.

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 that this is a destructive tool with no annotations, the description is comprehensive, covering prerequisites, alternatives, potential edge cases (last tab), and failure conditions. Nothing vital appears to be 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?

Although schema coverage is only 50%, the description provides critical semantic context by requiring profile_id to come from profiles_list and adding the vital constraint that IDs are local to a specific profile, preventing cross-profile misuse.

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 action (close), the resource (one browser tab), and the immediate consequences (removal of live page/unsaved state). It clearly defines the boundary of its functionality.

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 explicit instructions for prerequisite steps (use tabs_list first) and lists three distinct alternatives (tabs_switch, close_window), making the correct choice obvious to the agent.

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

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

No annotations at all, so the description carries full burden. It does disclose a non-obvious behavioral rule: object IDs are profile-scoped and must never be reused across profiles. It omits other relevant traits — behavior on focus/active, error conditions, duplicate-URL handling, and any auth/permission 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?

Two short sentences, zero filler, and the required-parameter prerequisite is front-loaded right after the purpose statement.

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?

Output schema exists, so return values need not be explained. For a mutation tool with no annotations, the description covers purpose and the profile-scoping prerequisite well, but says nothing about side effects (does it steal focus?) or failure modes, leaving modest gaps.

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 83%, so most parameters are self-documenting. The one undocumented param, profile_id, is exactly what the description compensates for by explaining where to get it and how IDs relate to it. Other params (active, pinned, window_id, cookie_store_id) are left to 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 ("Create a new browser tab") that an agent can clearly separate from create_window and the tabs_* family. No explicit sibling callout, but the resource noun does the differentiation work.

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

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

Provides a real prerequisite workflow ("obtain profile_id from profiles_list"), which is useful context. However, it gives no guidance on alternatives — e.g., why use this versus navigation_go_to_url on an existing tab, or when to specify window_id vs letting it default.

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 so well: it discloses that no tab is activated or window focused, the Firefox 139+ requirement, that pinned tabs get unpinned, that private and non-private tabs cannot be mixed, and the partial-failure semantics (group created, styling retried via tabs_groups_update). Only a note on permissions or return shape beyond the failure case is absent.

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 and every sentence carries operational content. It is somewhat dense and could be tightened (the profile_id/ID-locality paragraph is slightly verbose), but nothing is redundant 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?

Given an output schema exists, return values needn't be spelled out, yet the description still covers the edge case where styling fails but the group is created. Prerequisites (Firefox version, profile_id source), behavioral constraints, and failure recovery are all present, making it complete for a 5-parameter mutation 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 coverage is 80%, so the baseline is 3, but the description adds real value: it explains where group_id comes from (tabs_groups_query) and where profile_id comes from (profiles_list), and warns that object IDs are profile-local and must not be reused across profiles. Color and title semantics are already covered by 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?

Opens with a specific verb+resource: 'Group existing tabs, optionally setting the group's title and colour.' It immediately distinguishes the two modes (creating a new group vs. adding to an existing one) and is clearly separable from siblings like tabs_ungroup, tabs_groups_update, and tabs_groups_query.

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 states when to omit group_id (create a group in the first tab's window) versus when to pass one sourced from tabs_groups_query (add to that group). It even names the follow-up tool if styling fails, giving concrete alternatives and conditions rather than leaving routing to inference.

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 at all, the description carries the full burden and mostly succeeds: it discloses the Firefox 139+ version gate, the mandatory profile_id, and that object IDs are profile-local and must never be reused elsewhere — a real correctness hazard. It doesn't cover ordering, scale, or whether results span private/container windows, which is why it isn't 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?

Purpose is front-loaded in the first line, followed by the differentiator against tabs_group and the prerequisite note. Four short sentences with no filler; the stray line break inside the first paragraph is cosmetic only.

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 don't need explaining, and the remaining description covers the two things that matter for a query tool: the version prerequisite and the profile-scoping of IDs. Filter capabilities are delegated to the schema, which is a reasonable split.

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 already 80%, so the baseline is 3; the description earns extra by explaining why profile_id is required, where to source it (profiles_list), and the critical semantic that all returned IDs are scoped to that profile. That profile-scoping rule is nowhere in the schema and directly changes how callers chain parameters.

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

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

States a specific verb and resource ('List tab groups with their IDs') plus scope ('in every window or filtered'), which immediately separates it from create/mutate siblings like tabs_group and tabs_groups_update. It also explains the tool's raison d'être relative to tabs_group, so an agent can distinguish it without opening schemas.

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

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

Gives explicit routing logic: use this when you need a group ID that tabs_group did not return. Prerequisites are spelled out ('profile_id is required: obtain it from profiles_list'). It stops short of naming exclusions (e.g. 'do not use to modify groups — see tabs_groups_update'), so not quite 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?

With no annotations, the description carries the full burden and does well: "Leaves the group's tabs where they are" discloses partial-update semantics (membership untouched), and the version requirement and at-least-one-field rule are behavioral facts the schema cannot express. It omits error/failure behavior and whether the change is reversible, keeping it below 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?

The mutation and its scope land in the first sentence, followed by the non-obvious semantic ('leaves the group's tabs where they are') before the boilerplate prerequisites. Every sentence carries information an agent needs; nothing is repeated from the schema.

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

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

Output schema exists, so return values need not be explained, and the description covers the mutation scope, the at-least-one-field rule, the Firefox prerequisite and profile scoping. The remaining gap is what happens on an invalid or stale group_id, which an agent calling a mutation would benefit from knowing.

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 80%, so the baseline is 3; the description earns above that by stating the cross-parameter constraint that at least one of title/color/collapsed must be supplied, which the schema (all nullable, default null) does not enforce. It also ties profile_id to profiles_list and warns that object IDs are profile-local and non-transferable, adding meaning beyond the bare integer 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?

"Change a tab group's title, colour or collapsed state" is a specific verb and resource with the mutable fields enumerated, so an agent knows exactly what is being altered. It does not explicitly name the sibling it differs from (tabs_group creates, tabs_groups_query reads), so it stops short of full sibling differentiation.

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?

"Give at least one of title, color or collapsed" states the precondition for a meaningful call, and "Requires Firefox 139+" plus "obtain it from profiles_list" give the agent prerequisites and the sourcing path for profile_id. It does not rule out alternatives or state what to do when the group does not exist, so no exclusion guidance.

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 behavioral burden well: 'List' establishes a read operation, and it explains the line format, active/pinned markers, and how window/index/pinned state feed into tabs_move. It does not explicitly state that no browser state is modified, but the read-only nature is strongly implied and reinforced by the output 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?

The description is front-loaded with the core purpose and then adds only relevant operational detail. The explanation of how window, index, and pinned state relate to tabs_move is useful but slightly longer than necessary for a list tool. Overall it is well structured with no fluff.

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 define return values, yet it still explains the line format and markers helpfully. It covers profile requirements, ID locality, filtering, and output semantics. It stops short of discussing pagination, ordering, or when to prefer a different tab-query tool, but nothing critical is missing for correct invocation.

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

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

Schema coverage is 67%, and the description adds important meaning beyond the schema: profile_id is required and sourced from profiles_list, and all IDs are profile-local. It also clarifies that window and cookie store are optional filters. The remaining schema descriptions already document the window_id and cookie_store_id behavior adequately.

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 precise verb and resource: 'List open browser tabs,' and immediately scopes it with optional filtering by window and cookie store. It is clearly distinguishable from sibling tools like list_windows, get_current_window, and tabs_groups_query without needing to inspect 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?

It gives a clear prerequisite: profile_id is required and must be obtained from profiles_list. It also warns that object IDs are local to that profile and must not be reused elsewhere. It does not explicitly say when to choose tabs_list over alternatives like tabs_groups_query, so it falls short of 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 so thoroughly: partial success is normal, the response reads "Moved {n} of {m}", Firefox silently declines some moves, the pinned-tab index rule is spelled out with a concrete example, cross-window moves require normal (non-popup) windows of matching private state, and profile_id must come from profiles_list with IDs local to that profile.

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

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

Front-loaded with the one-line purpose, then layered constraints in short paragraphs under six lines each. Every sentence — pinned-tab rule, window-type rule, profile_id rule — carries an actionable constraint, so nothing reads as 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-shape detail is not required, yet the description still explains the meaningful part of the result ("Moved {n} of {m}") and how to detect a failed move. For a 4-parameter mutation tool with cross-window side effects, the guidance on preconditions and partial failure is 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 75% and the description adds real meaning beyond it: the -1/end index convention implicit in reordering, the refusal of indices inside a leading pinned run, and order preservation for a tab_ids list. The index rule is partly duplicated from the schema text, but the cross-window and ordering semantics are genuine additions.

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 — move tabs to a new position, optionally across windows — in the very first line. It reads clearly distinct from siblings like tabs_list, tabs_create or create_window, which are referenced only as helpers.

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 frames both modes (reorder within a window vs. gather into another window) and names the workflow prerequisite: create the target window with create_window and pass its ID. It also directs the agent to tabs_list when it needs pinned state or current indices.

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 adds genuinely valuable context about identifier scoping (object IDs are local to a profile). But it doesn't disclose side effects an agent would care about: whether switching activates/focuses the containing window, what happens if the tab is in a background window, or failure modes for invalid tab_id.

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 with the core action front-loaded and the prerequisite guidance following. Nothing is padded or restated from the schema.

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

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

An output schema exists, so return values needn't be explained, and the ID-provenance rule is covered. But for a state-changing browser action with zero annotation coverage, the description leaves the agent guessing about side effects (window focus/raise) and error behavior.

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% — tab_id is documented in the schema, profile_id is bare there. The description compensates by telling the agent where to get profile_id and warning against cross-profile reuse, which is more than the schema provides. However, the baseline for a partially-covered two-parameter schema lands at 3 since no format/range detail is added.

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 — 'switch to a specific browser tab' — which is unambiguous and distinguishable from window-level siblings like focus_window and from tabs_list/tabs_create. It stops short of explicitly naming those alternatives, but the tab-vs-window scope is clear.

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 real prerequisite workflow: obtain profile_id from profiles_list, and don't reuse IDs across profiles. That is useful usage guidance. However, it never says when to use this versus focus_window, or whether the tab must already exist in an open window, so the when-to-use decision is only implied.

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

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

With no annotations, the description carries the full burden and does it well: it declares the no-side-effect guarantee ('Never activates a tab or focuses a window'), the cascade consequence ('Firefox deletes a group once its last tab leaves it'), a version requirement, and a cross-profile ID scoping warning.

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, front-loaded with the action and the most surprising consequence, then the safety guarantee, version, and profile sourcing. No filler; every sentence conveys something an agent would otherwise have to guess.

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?

Output schema exists, so return values need no explanation. For a small two-parameter mutation the description covers the side-effect profile, the group-deletion consequence, the version gate, and the ID scoping rule — nothing material 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 coverage is 50%: tab_ids is documented in the schema, but profile_id has no schema description and the description compensates by declaring it required, naming where to obtain it, and warning that object IDs are profile-local. It cannot add much to tab_ids since the schema already covers the accepted formats.

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 ('Remove tabs from their tab group') with unambiguous scope. It is clearly distinct from tabs_group (the inverse), tabs_close (closes tabs), and tabs_groups_update, so an agent can select it without opening 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?

Provides useful prerequisites ('Requires Firefox 138+', 'obtain profile_id from profiles_list'), but never states when to use this rather than tabs_close or tabs_groups_update, nor any when-not conditions. Usage is inferable from the purpose but not explicitly routed.

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 at all, the description carries the full burden, and it does add one genuinely non-obvious constraint: object IDs are profile-local and must never be reused across profiles. It omits other important behavior for a mutation tool — whether omitted/null parameters leave existing values untouched, whether the window must already exist, and 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?

Two sentences and a header line, with the hard requirement and the ID-scoping warning front-loaded before any optional detail. 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 an 8-parameter mutation tool with zero annotations and an output schema, the description covers the multi-profile scoping hazard well but says nothing about partial-update semantics (what null defaults mean) or error conditions. An agent could still call it, but with avoidable uncertainty about whether unsent fields are preserved.

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 88%, so the schema already explains top/left/width/height/state/focused in detail, including the focus-refusal rule. The description's only parameter contribution is the provenance rule for profile_id (the one field with no schema description), which is helpful but narrow — 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 ("Update window properties") that an agent can map cleanly onto the sibling set of window operations. It does not, however, distinguish this from focus_window or create_window in the description text itself; that routing only appears buried in the schema's `focused` parameter note.

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 supplies a real prerequisite — profile_id must come from profiles_list — which is useful operational guidance. It gives no when-to-use/when-not guidance relative to close_window, create_window, or focus_window, so the agent must infer that this is for mutating an existing window's geometry/state.

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