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

Annotations already carry the safety profile (destructiveHint=true, idempotentHint=true, readOnlyHint=false, openWorldHint=false), so the bar is lower. The description adds a genuine behavioral fact beyond them — that the operation resumes thread execution — plus a token-validity precondition, but it does not explain what is disrupted by the destructive mutation or the failure mode for invalid tokens.

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 compact sentences with no filler, and the action is front-loaded before the parameter note. The minor cost is that the second sentence spends its space on a parameter naming mismatch rather than a sharper usage 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?

For a two-parameter mutation tool with full schema coverage and no output schema, the description covers the core action and one precondition. It is adequate but leaves an agent guessing about batch limits, partial-failure behavior, and what the destructive update does to currently running thread state.

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 documents both 'body' and 'workspaceId', which sets the baseline at 3. The description adds a validity constraint ('valid tokens with existing workspace IDs') beyond the schema's 'cannot be null or empty', but it refers to the parameter as 'threadTokens', a name that does not match the schema's 'body', which introduces mild confusion rather than clarity.

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 the specified execution threads, allowing them to continue working'), and the plural scope plus the bulk_ name separates it from the single-thread continue_use_thread sibling. The phrasing 'update ... allowing them to continue' is slightly indirect about the real action (resuming threads), but still 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?

The description gives a precondition — tokens must be valid and belong to existing workspace IDs — which implies the contexts in which the tool will succeed. It never says when to prefer this over continue_use_thread or bulk_stop_thread, and there is no explicit exclusion or alternative routing.

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

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

Annotations already declare this is a non-read-only, non-idempotent, non-destructive mutation, so the safety profile is covered. Beyond that the description adds almost nothing behavioral: no statement about what happens on partial failure, whether count has an upper bound, or whether created profiles can be rolled back. 'Each profile can have its own configuration' also conflicts with the fact that only one flat parameter set is accepted, which muddies rather than clarifies 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?

Three short sentences, but the opening 'This method is used to create new multiple browser profiles' is wordy and grammatically awkward, burying the verb behind filler. The trailing optionality sentence is vague and low-value.

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 25-parameter bulk mutation with no output schema and no annotations beyond safety hints, the description should say at minimum whether all created profiles share the same configuration, what 'count' constraints exist, and what a caller gets back. Instead it claims each profile can differ while exposing only one parameter set, leaving the agent's expectations wrong about the tool's actual 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 description coverage is 100%, so the schema already documents all 25 parameters in detail, establishing the baseline of 3. The description names a handful of them (screen size, hardware emulation, language, timezone, proxy) but adds no format or constraint guidance beyond what the schema enumerates.

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 (create) and resource (multiple browser profiles) scoped to a workspace and folder. The plural 'multiple' implicitly distinguishes it from the sibling create_profile, but that contrast is never made explicit. A reader can tell what it does, though not clearly why to pick it over the single-profile sibling.

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

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

No when-to-use guidance relative to create_profile or the bulk_update_* siblings, and no prerequisites, count limits, or workspace/folder requirements. The only usage hint is the vague 'All fields are optional if another is not specified,' which does not tell an agent when this tool is the right choice.

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

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

Annotations declare non-readonly, non-destructive, non-idempotent, and closed-world behavior. The description adds a crucial behavioral trait: errors during individual proxy creation are ignored, implying partial success. This is useful context beyond annotations, though atomicity and batch limits 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?

Two short sentences, front-loaded with the action and then the error-handling note. No redundant or filler content.

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 covers purpose and a key failure mode, and annotations supply the safety profile. However, with no output schema, the description does not explain return values (though the title does) and omits batch size limits or atomicity guarantees, which matter for a bulk 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 description coverage is 100%, so all parameters (body, folderId, workspaceId) are documented in the schema. The description only mentions 'array of proxy data' which adds no semantic detail 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 the tool creates proxies from an array, clearly indicating a bulk creation operation. It distinguishes from create_proxy through 'array' and 'all specified proxies', though it does not explicitly name the single-create sibling.

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

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

No explicit guidance on when to use this bulk tool versus create_proxy or other alternatives, nor any prerequisites. The bulk context is implied by 'array' but not stated as a decision rule.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, and openWorldHint=false, so the mutation/non-idempotent profile is covered structurally. The description adds only the bulk scope and workspace targeting; it does not say whether created threads begin running immediately, whether there is a creation cap, or whether partial failure is possible.

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

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

A single efficient sentence with the bulk scope front-loaded. Minor padding in the opener 'This method can be used to', which could be trimmed to 'Starts execution threads in bulk...'.

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 tool with no output schema and full schema coverage, the essentials are present. Still missing: what is returned (thread objects? IDs?), the effect of omitting count (declared required in the schema text but absent from the required list), and any limit on how many threads can be created at once.

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

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

Schema description coverage is 100%, so both parameters (count, workspaceId) are already documented, including the -1 default-workspace convention. The description's 'for the specified workspace' adds no information beyond the schema, so the baseline of 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 ('start execution threads in bulk') and scopes it to 'the specified workspace', which distinguishes it from the singular create_thread and other bulk thread tools. However, the verb 'start' differs from the name's 'create', leaving slight ambiguity about whether threads are merely created or immediately launched.

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

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

No indication of when to prefer this over create_thread for a single thread, nor any prerequisites (e.g., a valid workspace, existing profiles). The sibling create_thread and bulk_continue_use_thread are never referenced, so the agent must infer the choice from names alone.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is fully covered structurally. The description adds nothing beyond that — it does not say deletion is permanent, what happens to profiles in use, or any auth/rate-limit constraints.

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

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

A single efficient sentence with no wasted clauses. It is slightly padded by the 'This method is used to' opener but otherwise front-loads the action and scope.

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 destructive bulk mutation with no output schema, the description omits whether deletion is irreversible, how partial failures are handled, and whether target profiles must be unlocked — meaningful gaps even though annotations cover the basic destructive flag.

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% for both parameters (body array of UUIDs, workspaceId with default -1), so the schema carries full meaning. The description adds no syntax or format detail beyond what the schema provides, which is the baseline-3 case.

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 several existing browser profiles at once'), and the 'several...at once' phrasing conveys the bulk scope that separates it from the single-profile delete_profile sibling. It is clear but never names or contrasts with any alternative tool.

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

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

There is no guidance on when to use this versus delete_profile or any other tool, no prerequisites, and no mention of workspace context needed to run it. The agent must infer the bulk-vs-single distinction from the name alone.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false and openWorldHint=false, so the safety profile is covered. The description adds the bulk-request nature and workspace scoping, but says nothing about whether deletion is reversible, whether invalid IDs abort the whole batch, or how partial failures are reported.

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 purpose front-loaded and the precondition second. No filler, though the second sentence is generic advice that could be more specific about failure handling.

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 destructive bulk mutation with no output schema, the description covers the basic contract and the annotations cover safety, but it omits batch-size limits, error semantics for invalid/nonexistent IDs, and whether partial deletion is possible. Adequate but with clear 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 description coverage is 100%: the body array (non-null, non-empty UUIDs) and workspaceId (-1 = default) are fully documented in the schema. The description only restates that IDs must be valid and exist in the workspace, adding no syntax, size-limit, or format detail beyond the schema. 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+resource with scope: 'sends a bulk delete request to the API to remove the specified proxies.' It is clearly distinguishable in kind from delete_proxy, but it never explicitly says it is the batched counterpart to the single-delete sibling, so sibling differentiation is only implied.

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

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

The only guidance is a validation precondition ('ensure that the provided proxy IDs are valid and exist in the specified workspace'). There is no statement of when to prefer this over delete_proxy or bulk_delete_profile, and no warning about irreversibility or what to do on partial failure.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the safety profile is covered. The description adds no behavioral detail beyond the action itself—nothing about what happens to existing instances, partial failures, or the effect of keepAlive—so it does little beyond the annotations.

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

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

Two concise sentences with the primary action front-loaded and no wasted words. It could be slightly better structured by separating purpose from validation, but it is efficient.

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 bulk mutation tool with 7 parameters and 100% schema coverage, the description covers the primary action and a key prerequisite. However, it omits bulk-operation failure semantics (e.g., what happens if some profile IDs are invalid) and does not address the keepAlive or feature-override behaviors, leaving notable 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 description coverage is 100%, so the input schema already documents every parameter in detail. The description mentions profile IDs and workspace ID but adds no syntax, format, or meaning beyond what the schema provides, making 3 the appropriate 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?

The description states a specific verb+resource: 'create browser instances in bulk for the specified profiles.' The word 'bulk' distinguishes it from the single-instance sibling start_browser_instance, but the alternative is not named explicitly, so it falls short of a 5.

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

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

It offers prerequisite guidance ('Ensure that the provided profile IDs are valid and that the specified workspace ID exists') but does not say when to use this tool versus start_browser_instance or bulk_stop_browser_instance. Usage is implied by 'in bulk' but not made explicit.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=true, so the safety profile is covered. The description adds real value beyond them by explaining the effect: instances are permanently closed and their resources released. It does not say what happens to the underlying profiles or to partial failures.

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 the action front-loaded and no filler. The second sentence slightly restates the first ('stops' / 'permanently closes') but earns its place by adding the destructiveness and resource-release 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?

With only two parameters, full schema coverage, and annotations carrying the safety semantics, the description supplies what is needed: bulk scope, target selection by profile UUID, and the permanent-close effect. Missing only edge-case behavior (nonexistent UUIDs, already-stopped instances), which is minor for a bulk 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 description coverage is 100%, so the body array (profile UUIDs) and workspaceId semantics are fully documented in the schema itself. The description only loosely maps to 'the specified profiles' and adds no new parameter meaning, so the baseline of 3 is appropriate.

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

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

States a specific verb ('stops'), resource ('browser instances'), and scope ('multiple ... associated with the specified profiles'). The bulk scope implicitly separates it from the singular stop_browser_instance sibling, but no sibling or contrast is named explicitly, so it falls short of full 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?

Usage is implied by the name and description: use this when several profiles' instances must be stopped at once. However, there is no explicit when-to-use vs. stop_browser_instance guidance, no stated prerequisites (e.g., instances must be running), and no handling guidance for invalid or non-running 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?

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds nothing beyond that: it does not say what happens to associated browser instances or profiles, whether partial failures are possible, or whether the operation is reversible.

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

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

A single front-loaded sentence with no waste, but also no added substance. Sized appropriately for a simple bulk operation.

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 destructive bulk mutation with no output schema, the description is too thin. It omits what a stopped thread means for any running browser instance, error behavior on invalid tokens, and whether the action 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 description coverage is 100%, so both the thread-token array and the workspaceId default are already documented in the schema. The description adds no additional meaning about token format or batching limits; 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 ('stops multiple execution threads'), and the plural 'multiple' implicitly distinguishes it from the sibling stop_thread. It does not, however, explicitly name or contrast with that sibling.

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

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

No guidance on when to use this bulk variant versus stop_thread, nor any prerequisites or conditions for batching. The agent must infer the usage pattern entirely.

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

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

Annotations already declare readOnly=false, destructive=false, idempotent=false, openWorld=false, so the safety profile is covered. The description adds nothing beyond that: no batch atomicity semantics (all-or-nothing vs. partial failure), no note that assigning a preset overwrites existing preset assignments, and no permission/auth context.

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

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

A single front-loaded sentence with no filler or redundancy. It is efficient, though it is essentially a restatement of the title rather than a substantive expansion.

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 bulk mutation tool with no output schema and no annotations covering batch behavior, the description should address partial-failure handling, batch size limits, or what 'update the preset' actually changes on each profile. None of this is present, leaving the agent under-informed about the operation's consequences.

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

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

Schema description coverage is 100%, so all three parameters (body, presetId, workspaceId, including the null-removes-preset semantics) are documented in the schema itself. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb (updates), resource (preset configuration for browser profiles), and bulk scope (one or more profiles at once), which distinguishes it from single-profile and non-preset siblings. It does not explicitly name its closest siblings (bulk_update_profile_proxy, bulk_update_profile_tags), but the resource 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?

No when-to-use or when-not-to-use guidance. With three near-identical bulk_update_profile_* siblings, an agent gets no help choosing between preset, proxy, and tags variants, nor any prerequisites (e.g., preset must exist, profiles must be accessible).

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds the dual-mode assignment behavior, but it does not disclose permission requirements, whether running browsers are affected, partial-failure behavior across many profiles, or rate limits — meaningful gaps for a bulk mutation.

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 the bulk scope front-loaded and no filler. The second sentence largely re-expresses what the schema already says about the two proxy modes, so it is useful framing rather than strictly additive, keeping it just short of a 5.

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

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

There is no output schema, so return values need not be explained, and annotations cover the non-destructive read/write profile. However, for a 5-parameter bulk mutation the description omits what happens on invalid profile IDs, whether the operation is atomic across profiles, and whether the bulk update affects other proxy settings — leaving the agent with only the minimum viable picture.

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

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

Schema description coverage is 100%, so the schema already documents profile IDs, workspace, proxyServerId, proxyContainerId, and maxProfilesPerProxy. The description restates the two proxy-assignment modes at a high level without adding format, precedence, or mutual-exclusivity detail beyond what the schema's own descriptions say — the baseline 3 for full coverage is appropriate.

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

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

The description states a specific verb (updates), resource (proxy settings), and scope (one or more browser profiles at once), so an agent can distinguish it from siblings like bulk_update_profile_preset and bulk_update_profile_tags. It is clear, but it never names those siblings or explicitly contrasts itself with them, which is what a 5 would require.

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

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

Usage is only implied: the two assignment modes ('set a specific proxy server' vs 'assign proxies from a container') hint at when each path applies, but there is no explicit when-to-use, when-not-to-use, prerequisite, or alternative-tool guidance (e.g. update_proxy vs this bulk variant).

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that - no mention of replace-vs-merge semantics, permission requirements, or what happens to profiles not matched by an 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?

It is a single, front-loaded sentence with no filler or redundancy in structure. It is arguably too thin for the operation, but on the conciseness axis itself it is efficient.

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 bulk mutation tool the description is thin, but annotations carry the safety profile and the schema is fully documented, so an agent can still call it correctly. The missing usage/context layer keeps it at minimum-viable rather than 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?

With schema description coverage at 100%, the schema already documents all three parameters (profile ID array, the null/empty/array tag semantics, and workspaceId with its -1 default). The description provides no additional parameter meaning, so the baseline 3 applies.

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

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

The description states a verb (updates) and resource (tags for browser profiles) plus scope (one or more at once), so the purpose is decipherable. However, it is essentially a restatement of the title ('Updates tags for multiple browser profiles') with 'at once' added, and it never distinguishes itself from tag-adjacent siblings like update_profile or bulk_update_profile_preset.

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

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

There is no when-to-use guidance, no mention of prerequisites, and no routing to alternatives such as update_profile (single) or the other bulk_update_profile_* variants. The agent is left to infer all usage context from the name alone.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, openWorldHint=false, and destructiveHint=false, so the mutation and non-idempotent nature are covered structurally. The description adds useful context about the required IP-change URL, but says nothing about expected latency, whether the new IP is returned, or failure behavior — a gap for an operation whose whole purpose is a side effect.

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 the action front-loaded and the precondition immediately after; nothing is padded. The lead-in 'This endpoint' is minor filler, but overall it is efficiently structured.

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 no output schema and no annotations about results, the description should ideally state what the agent gets back (e.g., new IP, async status) and roughly how long the change takes. It covers the prerequisite but leaves the post-call expectations undefined for a non-idempotent mutation.

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

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

Schema description coverage is 100% and both parameters (proxyId, workspaceId) are documented in the schema, so the baseline is 3. The description only alludes to 'the specified mobile proxy' and never mentions workspaceId, so it adds no semantics beyond the schema.

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

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

States a specific verb and resource ('triggers an IP change for the specified mobile proxy'), which is an action no sibling tool performs, so the agent can distinguish it immediately. The scope is bounded to mobile proxies and to a single named target.

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 one real prerequisite ('The proxy must have a valid IP change URL configured'), which is the key precondition for the call to succeed. However, it gives no guidance on when to use this versus other proxy tools (e.g., update_proxy) or what happens when the precondition is unmet, leaving usage 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?

Annotations already declare readOnlyHint=false, destructiveHint=false and idempotentHint=false, so the safety profile is partly covered. The description adds the workspace scoping of the cleanup but does not say which cached artifacts are removed, whether the profile itself is preserved, or whether the operation is repeatable. Note: removing cached data arguably conflicts with destructiveHint=false, but cache regeneration is a defensible exemption, so this is borderline rather than a clear contradiction.

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

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

A single sentence that front-loads the action and target. It is slightly padded by the "This method can be used to" construction, which could be trimmed without loss.

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

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

There is no output schema, so the description should ideally indicate what the caller gets back or what state the profile is left in. It covers the scope but leaves the effect of the cleanup, and the identity of the "cached data," unspecified for a mutating tool.

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

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

Schema description coverage is 100%, so both profileId and workspaceId (including the -1 default) are fully documented in the schema. The description's reference to "the specified workspace" merely paraphrases the schema, so the baseline 3 applies.

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

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

States a clear verb and resource: cleaning cached data for a browser profile, scoped to a workspace. It is distinguishable from delete_profile or update_profile at a glance, though it does not explicitly name or contrast with any sibling tool.

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

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

"This method can be used to..." gives no when-to-use guidance, no prerequisites, and no mention of alternatives such as delete_profile or recover_profile. The only usage signal is implicit in the word "clean up".

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is carried structurally. The description adds nothing on top — it never explains what state is destroyed, whether the thread must exist, or what 'continue work' actually mutates.

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

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

It is a single short sentence with no padding, but that sentence is pure duplication of the title and conveys no information an agent did not already have, so concision buys nothing here.

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 destructive, non-idempotent-looking thread mutation with no output schema and no annotations explaining return or error behavior, the description leaves core questions unanswered: what continuing a thread does, what happens to an expired or running thread, and what the result is.

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

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

Schema description coverage is 100%: threadToken and workspaceId are both documented in the schema, including the -1 default semantics. The description adds no syntax, format, or constraint beyond that, so the baseline 3 applies.

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

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

The sentence restates the title almost verbatim: 'continue work of the execution thread associated with the thread token.' It does name a verb (continue) and a resource (execution thread), but offers no differentiation from siblings like bulk_continue_use_thread, create_thread, or stop_thread, and 'continue work' is never defined.

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

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

No when-to-use, when-not-to-use, prerequisites, or alternatives are given. An agent cannot tell from this text whether to call this versus bulk_continue_use_thread, create_thread, or start_browser_instance.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the write nature is covered. The description adds a genuinely useful side-effect disclosure beyond the annotations: existing cookies in the target profile are overwritten. It omits prerequisites (locked/running profile behavior) and what happens when the source has no cookies, so it is not a 5.

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

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

Two tight sentences, action first and the important side effect second. Every sentence earns its place and there is no bloat 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 small mutation tool with no output schema and full schema coverage, the essential operation and its overwrite side effect are covered. However, prerequisites and edge-case behavior (missing source cookies, locked profiles) are absent, leaving the definition only minimally adequate.

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

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

Schema description coverage is 100%, so profileId, workspaceId, and targetProfileId are already documented in the schema, including the -1 default for workspaceId. The description adds nothing about parameter usage or constraints, so the baseline 3 applies.

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

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

The description states a specific verb (copies) and resource (cookies) plus the direction (source profile to target profile), so the core action is unambiguous. It does not explicitly distinguish itself from the adjacent import_cookies/export_cookies siblings, which an agent might otherwise confuse with it, so it stops short of a 5.

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

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

There is no guidance on when to use this tool versus the obvious alternatives (import_cookies, export_cookies, run_cookie_robot). No prerequisites are stated, such as whether source/target profiles must be stopped or unlocked. The agent gets no routing help.

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

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

Annotations already declare a non-read-only, non-idempotent, non-destructive, closed-world mutation, so the safety profile is covered. The description adds nothing beyond that: it doesn't say whether an existing extension with the same ID is replaced, whether the file must exist on disk, what errors occur on failure, or what permissions are needed. For a write tool it carries no extra behavioral context.

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

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

It is a single front-loaded sentence with no wasted words, which is structurally fine. But the sentence merely mirrors the title, so its brevity reflects under-specification rather than efficient communication.

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 mutation tool with no output schema, the description should at least note that only presetId is required and filePath is optional, and what happens to pre-existing extensions. None of that is present, and the description never mentions the file input at all despite 'from_file' in the name.

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

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

Schema description coverage is 100%: filePath, presetId, and workspaceId all carry inline descriptions and the workspaceId default (-1) is documented. The description adds no formatting or constraint detail beyond the schema, so the baseline of 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?

Tautological: description restates name/title.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of create_extension_from_web as the alternative for web-sourced extensions. Usage is only weakly inferable from the phrase 'file extension', so this is essentially 'no 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?

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the mutation profile is covered by structured data. The description adds nothing on top of that: it does not say whether the URL is fetched server-side, what happens when the same extension is added twice, or whether the preset is mutated in 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?

It is a single short sentence with no padding, so it is not bloated. However, because it merely echoes the title, the sentence does not really earn its place as a separate description field.

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 mutation tool with no output schema, the description leaves the agent without the return shape, error behavior, or the distinction from create_extension_from_file. Annotations cover safety hints, but the functional context is essentially absent.

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

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

Schema description coverage is 100%, and the schema documents url, presetId, and workspaceId (including the -1 default convention) clearly. The description contributes no additional parameter meaning, so the baseline 3 applies when the schema carries the full load.

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?

Tautological: description restates name/title.

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

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

There is no when-to-use guidance, no statement of prerequisites (e.g. whether the preset must exist), and no mention of the alternative create_extension_from_file for local packages. The agent must infer the choice between web-based and file-based extension creation entirely on its own.

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

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

Annotations already disclose the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false), so the bar is lower. The description adds one useful behavioral fact — 'All presets are cloud-based' — but says nothing about required auth, whether the new preset is auto-assigned to a profile, or what the response contains.

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 with the action front-loaded and no filler. The middle sentence is slightly run-on ('group extensions, bookmarks, manage them together and assign them to profiles'), but overall it is tight and earns its space.

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 mutation tool with full annotation coverage, 100% schema coverage, and no output schema, the description supplies adequate domain context about what presets are and that they live in the cloud. It stops short of explaining creation side effects or profile assignment behavior, which would have made it fully complete.

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

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

Schema description coverage is 100%, so name, iconName, and workspaceId are already documented by the schema itself. The description adds no additional parameter meaning — the 'cloud-based' note does not clarify workspaceId semantics — so the baseline of 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?

The first sentence states a specific verb+resource ('Creates a new preset') and the following sentences explain what a preset actually is, which helps an agent understand the object being created. Differentiation from siblings is implicit rather than stated; there is only one create_preset among the siblings, but the description never contrasts it with get_presets or delete_preset.

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 explains the concept of presets (group extensions/bookmarks, assign to profiles) which implies the usage context, but gives no explicit when-to-use or when-not guidance and names no alternatives. An agent can infer it is the creation entry point for the preset family, but nothing is spelled out.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the safety profile is covered. The description adds useful context beyond annotations: what a browser profile conceptually is ('a set of parameters for browser configuration ... with different fingerprints'), and that a unique identifier is returned for updating or deleting. It does not disclose any permission requirements, rate limits, or side effects of creation.

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 correctly, but the description runs to four sentences and includes a somewhat generic definitional aside ('Browser profile is a set of parameters...'). The statement 'All parameters are optional if another is not specified' is awkward and marginally wasteful.

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 26-parameter tool with no output schema, the description partially compensates by explaining that a unique profile identifier is returned upon creation. However, it leaves significant gaps: how defaults interact across dozens of optional fingerprint fields, whether creation requires/consumes a license or proxy, and how it relates to bulk or preset-based creation are all unaddressed.

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

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

Schema description coverage is 100% and every one of the 26 parameters is thoroughly documented in the schema itself, so the baseline is 3. The description only names a few example categories (screen size, hardware emulation, language, timezone, proxy) without adding syntax, defaults, or interaction rules beyond what the schema already provides.

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: 'creates a new browser profile in the specified workspace and the folder.' It is clear what the tool does, but it does not differentiate itself from siblings like bulk_create_profile or create_preset, which an agent could confuse with it.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no named alternative (e.g. bulk_create_profile for multiple profiles, or create_preset to reuse config). The sentence 'All parameters are optional if another is not specified' is vague and reads more like a caveat than usage 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?

Annotations already declare this is a non-read-only, non-idempotent, non-destructive creation. The description goes beyond them by disclosing the tariff/quota ceiling on folder count and the validity preconditions on workspace ID and location, which are real operational constraints. It still omits what happens on failure or whether the call is safe to retry.

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 and precondition are correctly front-loaded, but the middle sentences describing a folder's identifier, name, location and profile quantity are largely expository filler already covered by the schema and don't help an agent invoke the tool. Four sentences for a simple three-parameter create is longer than needed.

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

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

There is no output schema, yet the description never says what the call returns (presumably the new folder's identifier), which an agent would need for chaining. Annotations cover the safety profile and parameters are fully documented, so the remaining gap is the return value and the absence of alternative-routing context.

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

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

Schema description coverage is 100%, so the schema already defines name, location (with the Local/Cloud enum and default) and workspaceId (-1 for default). The description restates location values and the folder's attributes without adding format, length, or uniqueness rules for the name parameter, so 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?

The first sentence gives a clear verb+resource ('creates a profile folder'), and the name plus surrounding description distinguishes it from create_proxy_folder and create_profile. However, it never explicitly names or contrasts with the sibling 'create_proxy_folder', so sibling differentiation is only implied by the noun.

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 precondition ('caller must ensure that the specified workspace ID and location are valid') and a quota constraint ('profile folders count is limited by tariff'), which implies when the call is appropriate. But there is no explicit when-to-use/when-not guidance and no routing to alternatives such as create_proxy_folder or the bulk/update variants.

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

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

Annotations already disclose the mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the safety burden is largely covered. The description does add one piece of behavioral value that no structured field supplies: it returns the generated unique identifier, which matters since there is no output schema. It says nothing about whether duplicate names are allowed or what happens on invalid proxyUri.

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, but the first opens with the filler phrase 'This method is used to' and pushes the actual verb back, and it largely repeats the title. The second sentence (return value) earns its place; the first is 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?

For a five-parameter mutation tool the description covers the essentials only because the schema is fully annotated and annotations declare the safety profile. The genuinely useful addition is the return-value note, but required-parameter reality (name cannot be null or empty while the schema lists zero required fields) and failure behavior are left unaddressed.

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

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

Schema description coverage is 100%, so all five parameters (name, folderId, proxyUri, ipChangeUrl, workspaceId) are already documented with defaults and constraints in the schema. The description adds no syntax, format, or inter-parameter semantics beyond that, so the baseline 3 applies.

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

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

The description states a specific verb (add) and resource (a new proxy entry), so an agent can tell what the tool produces. However, it offers no differentiation from close siblings such as bulk_create_proxy (multi-create) or update_proxy (modification), leaving the agent to infer the boundary 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?

There is no guidance on when to use this tool versus bulk_create_proxy, update_proxy, or the folder-creation siblings, and no prerequisites or preconditions are mentioned. The sentence 'using the provided configuration parameters' restates the schema rather than saying anything about when this call is appropriate.

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

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

Annotations already declare it is a non-read-only, non-destructive, non-idempotent write. The description adds value beyond them by disclosing that a unique identifier is returned at creation and is reused for update/delete, which is important since no output schema exists. It does not discuss naming conflicts or permissions, but the annotation bar is already met.

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

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

Purpose is front-loaded in the first sentence, which is good, but the second sentence about proxy folders being a container "used for better organization" is explanatory filler that does not help an agent call the tool. The remaining content is reasonably tight.

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 no output schema, the description usefully covers the creation result (the returned folder identifier) and the prerequisite validation of workspace ID and location, and annotations cover the safety profile. It omits only secondary concerns such as duplicate-name 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 description coverage is 100%, so name, location (with enum and default) and workspaceId (-1 = default workspace) are fully documented in the schema. The description only echoes that workspace ID and location must be valid, adding no syntax or constraint detail. 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 ("creates a new proxy folder") and additionally explains what a proxy folder is, so the agent knows the entity is a container for proxies. It is distinguishable from siblings like create_profile_folder. It does not, however, explicitly contrast itself with those 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 gives one prerequisite ("The caller must ensure that the specified workspace ID and location are valid") but never says when to create a folder versus using an existing one, or what happens on duplicate names. Usage is only implied by the create verb.

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

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

Annotations already declare this is a non-read-only, non-idempotent, non-destructive, closed-world write, so the safety profile is covered. The description usefully adds lifecycle context (threads can be continued or stopped), but omits what happens on repeated invocation and, importantly, never says a thread identifier is produced for later use.

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 action and followed by lifecycle context; nothing is padded. The middle sentence is slightly garbled ('used to start, work with a browser instance'), a minor polish issue rather than bloat.

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-optional-parameter tool with no output schema, the description covers purpose and lifecycle adequately. However, because no output schema exists, the description carries the burden of telling the caller that a thread handle is returned for continue/stop, and it does not.

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

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

Schema description coverage is 100% and the only parameter's semantics (workspaceId, -1 = default) are fully documented in the schema. The description's phrase 'in the specified workspace' adds nothing beyond the schema and documents no format or constraint details, so the baseline 3 applies.

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

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

States a specific verb+resource ('runs a new execution thread in the specified workspace'), which separates it from continue_use_thread and stop_thread. It does not distinguish itself from bulk_create_thread or start_browser_instance, which are the closest siblings an agent could confuse it with.

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 thread's role (start/work with a browser instance) and explicitly routes to continue_use_thread and stop_thread for the follow-up lifecycle steps. It stops short of saying when to prefer this over bulk_create_thread or why a thread is needed instead of start_browser_instance directly.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered externally. The description adds zero behavioral context beyond that – it does not say what is destroyed, whether the removal is permanent, or whether the extension is detached from all presets or only the referenced one.

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

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

A single short sentence is not conciseness here – it is under-specification. There is no front-loaded substance because there is no substance at all.

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 destructive, three-parameter mutation with no output schema, the description should at minimum explain scope and irreversibility. It instead repeats the title, leaving the agent to rely entirely on annotations and 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 description coverage is 100%, with presetId, extensionId and workspaceId all documented in the schema, so the baseline of 3 applies. The description contributes no additional parameter 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?

Tautological: description restates name/title.

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

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

There is no when-to-use guidance, no prerequisites (e.g. must the extension be removed from a preset first?), and no mention of alternatives such as delete_preset. The agent must infer everything from the name.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds nothing beyond that — no statement of irreversible loss, no cascade effects, no confirmation requirements — so it exceeds the minimum but contributes no behavioral context.

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

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

The single sentence is short and front-loaded, but it restates the name rather than conveying information, so it does not earn its place. This is under-specification rather than genuine conciseness.

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 destructive delete tool with no output schema, the description omits what an agent needs: whether deletion is recoverable, whether the preset must be unused, and how workspaceId scopes the target. Annotations cover the write/destructive profile but not the operational context.

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

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

Schema description coverage is 100%: presetId and workspaceId are both documented in the schema, including the -1 default workspace convention. The description adds no parameter meaning, so the baseline of 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?

Tautological: description restates name/title.

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

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

There is no when-to-use guidance, no mention of prerequisites, and no reference to alternatives such as create_preset, get_presets, or bulk_update_profile_preset. The agent must infer entirely from the tool name.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds nothing beyond them: it does not say whether deleted profile data (cookies, extensions, fingerprints) is unrecoverable, whether recover_profile can undo it, or what happens to associated resources.

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

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

It is a single short sentence with no padding, which is good, but it merely duplicates the title word for word and therefore does not earn its place as added information.

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

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

For a destructive mutation tool with no output schema, the description should at minimum cover consequences and recovery options. With annotations covering only the generic safety hints, an agent is left without the deletion semantics it needs to call this responsibly.

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

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

Schema description coverage is 100%, with both profileId and workspaceId (including the -1 default meaning) documented in the schema. The description contributes no additional parameter meaning, so the baseline of 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?

The description states a specific verb and resource ('deletes an existing browser profile'), so the purpose is not vague. However, it is a verbatim restatement of the title and offers no differentiation from siblings such as bulk_delete_profile, delete_profile_folder, or recover_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?

There is no guidance on when to use this tool versus bulk_delete_profile for multiple profiles, nor any prerequisites such as required permissions or whether the profile must be stopped first. The agent must infer all usage context from the name alone.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so safety and idempotency are covered. The description only restates a generic precondition ('must match the existing folder') and never discloses what happens to the profiles contained in the folder — the single most important behavior for a destructive delete that has a '..._with_contents' counterpart.

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?

Short and front-loaded, but the opening sentence ('This method is used for deleting a profile folder') largely restates the title and wastes the space that could have carried the missing behavioral detail. Not verbose, but not efficient either.

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 destructive tool with several overlapping delete siblings and no output schema, the description is too thin. It omits the folder-contents semantics and the alternative-tool routing an agent needs to invoke it safely.

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

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

Schema description coverage is 100%, so both workspaceId (default -1) and profileFolderId (uuid) are fully documented in the schema. The description adds only a light existence precondition for profileFolderId and nothing about workspaceId, so 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 (deleting) and resource (a profile folder), so the basic operation is unambiguous. However, it fails to distinguish itself from the near-identical sibling delete_profile_folder_with_contents, leaving the agent unable to tell the two apart from the description 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?

No when-to-use guidance, prerequisites, or alternatives are given. The critical question of when to pick this over delete_profile_folder_with_contents or delete_profile is never addressed, and no conditions or exclusions are 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?

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description still adds real value beyond them by disclosing the cascade scope (profiles inside the folder are destroyed) and the precondition that the ID must match an existing folder in the given workspace. It stops short of saying whether the deletion is recoverable, despite a recover_profile sibling 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 sentences, front-loaded with the destructive scope and with zero filler. The second sentence is slightly awkwardly worded ('must match the existing folder in the specified workspace') but remains compact and useful.

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 100% schema coverage, full annotation coverage of the safety profile, and no output schema, the description supplies the one thing structured data cannot: what actually gets destroyed. The main residual gap is recoverability/irreversibility, which is relevant given the recover_profile sibling.

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 both parameters (including the -1 workspaceId default) are already fully documented in the schema, establishing the baseline of 3. The sentence about profileFolderId needing to match an existing folder adds a validation precondition, but it is framed as a general constraint rather than clarifying parameter behavior or format.

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 ('deletes a profile folder') and adds the critical scope detail that all contained profiles are deleted too, which distinguishes it in substance from the sibling delete_profile_folder. However, it never names that sibling explicitly, so the differentiation must be inferred from the 'and all profiles it contains' clause.

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

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

The phrase 'and all profiles it contains' implies the use case (delete folder plus contents rather than folder alone), but there is no explicit when-to-use guidance, no mention of delete_profile_folder as the non-cascading alternative, and no note about prerequisites such as stopping running browser instances first.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds the precondition that the ID must match an existing proxy in the given workspace, which is useful context, but it says nothing about failure behavior or what happens to profiles bound to the deleted proxy.

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 that are front-loaded with the action and scope. It is slightly redundant, restating the 'by the specified ID' idea from the title, but nothing is padded or 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?

For a destructive delete tool with annotations covering safety and no output schema, the description is adequate: it names the resource, the key parameter, and the existence precondition. It stops short of covering side effects (e.g., effect on profiles referencing the proxy) or error behavior, which a delete operation would benefit from.

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

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

Schema description coverage is 100%, so both parameters are already documented, establishing the baseline of 3. The description's note that proxyId must exist in the specified workspace adds mild semantic value about the workspaceId relationship but no syntax or format detail 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 ('deletes a proxy from the list by the specified ID'), so the operation is unambiguous. It does not, however, explicitly differentiate itself from the closely named sibling bulk_delete_proxy, leaving the agent to infer singular vs. bulk from the name 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?

The description offers no when-to-use guidance or alternatives, even though bulk_delete_proxy and delete_proxy_folder sit in the same sibling set. The stated precondition ('must match an existing proxy') is a constraint, not usage routing.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered structurally. The description adds that the folder must exist within the specified workspace, but it does not explain what happens to folder contents, permissions, or failure behavior for non-empty folders.

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

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

The description is two short sentences and front-loads the deletion action. It is efficient overall, though "This method" is mild filler and the second sentence could more directly state the 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 destructive folder-deletion tool, the description covers the basic action and the existence prerequisite, and annotations carry the destructive/idempotent safety context. However, it omits the critical distinction from delete_proxy_folder_with_contents and does not clarify whether a non-empty folder will be rejected or what happens to contents.

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

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

Schema description coverage is 100%, so the schema already documents both workspaceId and proxyFolderId. The description reinforces that proxyFolderId must reference an existing folder within the workspace, but adds little parameter detail beyond that.

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

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

The description states a specific verb and resource: it deletes a proxy folder. It does not distinguish this tool from the sibling delete_proxy_folder_with_contents, which is an important nearby alternative, so it stops short of a 5.

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

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

It gives a prerequisite that proxyFolderId must match an existing folder in the workspace, but it does not say when to use this tool rather than delete_proxy_folder_with_contents or other deletion tools. The usage is only implied by the tool name and operation.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the base safety profile is covered. The description adds valuable scope detail—that all contained proxies are deleted—which goes beyond the generic destructive flag, though it does not mention irreversibility, permissions, or behavior on a missing folder.

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 compact sentences, front-loaded with the action and its scope, with 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 destructive mutation tool with full annotation coverage and no output schema, the description covers what gets deleted and the required parameter. It omits, however, the crucial routing guidance against delete_proxy_folder, so an agent could choose the wrong tool and cause unintended data loss.

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 baseline is 3. The description adds a meaningful validity constraint not present in the schema: proxyFolderId must reference an existing folder within the specified workspace, implying failure otherwise.

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 ('deletes a proxy folder and all proxies it contains') and defines the 'with contents' behavior, which implicitly separates it from delete_proxy_folder. However, it never names or explicitly contrasts the sibling tool, leaving some differentiation to inference.

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

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

There is no guidance on when to use this tool versus the many alternatives, notably delete_proxy_folder, which is a critical distinction given the destructive scope. The only contextual statement is a parameter precondition ('proxyFolderId must match the existing folder'), not a when-to-use rule.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the safety profile is covered. The description adds the JSON output format, but never clarifies whether cookies are returned inline or written to a file, nor what happens for an unknown profileId — a notable omission given readOnlyHint=false is unusual for what reads like a pure export.

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 the core action front-loaded and no filler. The second sentence is mildly redundant with the title's framing but still carries the intended-consuming use cases.

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

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

There is no output schema, so the description carries the burden of explaining the return, and 'JSON format' is only a partial answer — it does not say whether cookie data, a file path, or a download token comes back. Adequate for a two-parameter tool but leaves a real question open.

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

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

Schema description coverage is 100% for both parameters, so profileId and workspaceId (including the -1 default) are already fully documented in the schema. The description adds no extra semantics beyond 'existing profile', so the baseline 3 applies.

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

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

Specific verb+resource: exporting cookies from an existing profile, with the output format (JSON) stated. It does not, however, distinguish itself from the sibling cookie tools (import_cookies, copy_cookies), so an agent must infer the boundary itself.

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?

'Can be used for backup or transfer purposes' describes the value of the output, not when to select this tool over import_cookies or copy_cookies, which are the obvious confusable siblings. No prerequisites or exclusions are 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?

Annotations already declare readOnlyHint=false, destructiveHint=false, and non-idempotent behavior, but the description adds no context beyond the title. It does not explain whether focusing requires a running instance, whether it changes browser state, or what happens if the profile is not active.

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

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

The description is a single front-loaded sentence with no wasted words, but it merely repeats the title and is under-specified for the tool's operational 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?

For a simple two-parameter UI action with full schema coverage and annotations, the description is adequate but incomplete. The key missing context is that this focuses an existing browser window rather than starting one, and what happens if no window is running.

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

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

Schema description coverage is 100%, and the schema fully documents profileId and workspaceId including the default workspace convention. The description adds no parameter-level meaning beyond the schema, so the baseline of 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?

Tautological: description restates name/title.

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

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

There is no guidance on when to use this tool versus alternatives like start_browser_instance or set_browser_instance_visibility. It also does not state the prerequisite that the browser instance must already be running.

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

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

Annotations already disclose readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the safety profile is covered by structured data. The description adds the useful condition that the lock is held by another machine, but omits the consequence for that other machine (session termination, whether the other machine must be stopped first).

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

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

A single sentence with the key qualifier (locked by another machine) front-loaded and no redundant restatement. The lead-in 'This method can be used to' is slightly padded but negligible.

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 tool with full schema coverage, no output schema, and a clear mutation intent, the description gives enough to invoke it correctly. Only the side effect on the currently holding machine is left unstated, which is a minor gap rather than a blocker.

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

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

Schema description coverage is 100% with only two simple parameters, so the schema already documents profileId and workspaceId fully. The description's mention of 'specified workspace' matches the schema but adds no new syntax or format detail; 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 (force unlock) and resource (cloud browser profile) with a clear pre-condition (currently locked by another machine) and scope (specified workspace). It is not, however, differentiated from the nearby recover_profile sibling, so an agent cannot tell which to prefer from the description 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?

The phrase 'currently locked by another machine' implies when this tool is applicable, so usage is inferable. But there is no explicit guidance on when to choose this over recover_profile, nor on prerequisites such as permissions or the state the profile must be in.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile, so the bar is lower. The description nonetheless adds a genuinely non-derivable constraint: results apply only to browser instances launched via the API. It does not, however, describe the returned payload or pagination behavior beyond what the schema states.

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 sentences, front-loaded with the purpose and ending on the high-value scope caveat. Mostly tight, with minor redundancy in 'with detailed information' that adds little.

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

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

With no output schema, the description carries the burden of describing what is returned, yet 'detailed information' is vague and the pagination semantics (start/total interplay, default 1000) are left to the schema. For a 6-parameter list tool with no output schema, this is adequate but leaves a real gap in return-value expectations.

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

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

Schema description coverage is 100%, so every parameter is already documented with defaults and types (start, total, sorting, processId, profileId, workspaceId). The description's mention of profile/process filtering, sorting, and limiting simply restates the schema and adds no syntax or format detail. 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?

The description states a specific verb ('returns the list') and resource ('browser processes available for the current user'), so the core purpose is unambiguous. However, it never distinguishes itself from the singular sibling get_running_browser_instance, and it drifts between 'browser processes' and the tool name 'browser instances', which muddies the boundary with that sibling.

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

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

It implies usage by enumerating the filtering, sorting, and limiting options, which suggests a list/query scenario. But there is no explicit guidance on when to call this versus get_running_browser_instance in the sibling set, and no prerequisites or exclusions are 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, covering the full safety profile. The description adds nothing beyond the annotations - no return format, no auth or rate-limit context - and effectively restates the title.

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

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

A single short, front-loaded sentence with zero filler, appropriate for a trivially simple no-parameter read.

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 no output schema, the description should ideally state what is returned (bare version string vs structured object) and how it relates to get_product_version. The safety and simplicity are covered by annotations, so the gap is modest but real.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline is 4 for a no-param tool.

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

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

The description names a specific verb ('returns') and resource ('the current version of the browser engine'), so an agent knows exactly what it fetches. However, it does nothing to distinguish itself from the close sibling get_product_version, which could plausibly be confused with a browser-engine version lookup.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of the near-identical sibling get_product_version. Usage is only implied by the tool name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds nothing on top of that — no mention of pagination defaults, result caps, or that filtering is optional — so it contributes no behavioral context beyond the annotations.

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

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

It is a single short, front-loaded sentence with no filler, which is structurally fine. But the sentence is an exact restatement of the title, so it earns its place only marginally — brevity here comes from under-specification rather than discipline.

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 six-parameter paginated list tool with no output schema and no required parameters, the description should at least explain filtering and paging behavior or what the returned collection contains. Instead it repeats the title, leaving the agent to infer everything about scope, defaults, and return shape.

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

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

Schema description coverage is 100% across all six parameters (id, name, start, total, presetId, workspaceId), so the schema carries parameter semantics entirely. The description adds no filter syntax, default behavior for workspaceId=-1, or pagination details, making the baseline 3 appropriate.

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

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

Tautological: description restates name/title.

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

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

There is no guidance on when to use this tool versus alternatives, no indication of pruning/filtering intent, and no prerequisites (e.g., whether a workspace context is required). Nothing in the text routes the agent among the many sibling read tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds nothing beyond that: it does not say what the limits represent, whether they change over time, or what happens when workspaceId is omitted (the schema default -1 handles that instead).

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

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

A single, front-loaded sentence with no filler or repetition. It is economical, though its brevity contributes to the under-specification noted in other dimensions.

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 read-only, single-optional-parameter tool with full annotation coverage and no output schema, little is strictly required. However, the central ambiguity — what 'current limits' actually contains — is left unresolved, which is the one thing the description should have clarified.

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

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

Schema description coverage is 100% and the single parameter is fully documented in the schema, including the -1 default meaning. The description only echoes 'specified workspace', adding no syntax or semantic detail beyond the schema, so the baseline 3 applies.

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

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

The description gives a clear verb and resource ('returns the current limits'), but 'limits' is undefined — it could mean plan/tariff quotas, proxy limits, or profile limits, especially with get_tariff in the sibling set. There is no differentiation from siblings that might also surface quota-like data.

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

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

There is no when-to-use guidance, no mention of prerequisites, and no alternatives (e.g., get_tariff for plan-level information). The agent must infer the use case entirely.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without the description. The description does add one piece of non-annotation context — that results are scoped to the current user's accessibility — but says nothing about pagination, ordering, or result shape.

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

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

It is a single short, front-loaded sentence with no padding. But the sentence duplicates the title almost exactly, so it is under-informative rather than economical — brevity without added value.

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 read-only, zero-required-parameter tool this is close to adequate, and annotations carry the safety profile. With no output schema, however, the description leaves the return values (preset fields, filtering, pagination) entirely unexplained.

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

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

Schema description coverage is 100%: the single workspaceId parameter is fully documented in the schema, including the -1 default-workspace convention. The description adds no parameter meaning of its own, so the baseline 3 applies.

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

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

Tautological: description restates name/title.

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

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

There is no when-to-use guidance, no mention of the alternative siblings (create_preset, delete_preset), and no stated prerequisites. The 'current user' scope is the only hint about when this applies, which is weak 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds nothing beyond that — no mention of what the returned version string looks like or whether it reflects the API/server vs client.

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

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

A single short sentence with no padding, front-loaded with the resource and action. It is efficiently sized for a trivial no-arg tool, though that efficiency comes at the cost of substance.

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 no parameters, no output schema, and rich annotations, the only remaining gap is what 'product version' actually denotes and how it differs from get_browser_version. The definition is adequate to invoke but thin on disambiguation.

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

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

The tool takes zero parameters, so there is nothing for the description to document; baseline 4 applies. The schema is empty and correctly so.

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 is a near-verbatim restatement of the title/name: 'returns the current version of the product' under a tool called get_product_version. It gives no distinguishing detail versus the sibling get_browser_version, leaving the agent to infer the difference.

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

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

There is no guidance on when to call this instead of get_browser_version, get_limits, or get_tariff. The only implicit cue is the word 'product,' which is not explained.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description contributes nothing beyond that—no note on what 'detailed information' includes, whether a missing profile errors, or any rate/permission context.

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

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

It is a single short sentence with no wasted words, but that brevity comes from under-specification rather than economy—the sentence carries no information beyond the title.

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

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

There is no output schema, so the description should indicate what is returned; 'detailed information' is too vague for an agent to know the shape of the response. For a read tool with no return-value documentation, this leaves a real 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 description coverage is 100% with only two parameters, both fully documented in-schema (profileId as UUID, workspaceId defaulting to -1). The description adds no additional meaning, so the baseline 3 applies.

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

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

Tautological: description restates name/title.

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

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

There is no when-to-use guidance: nothing tells the agent to prefer this over get_profiles for a single lookup, or how it relates to update_profile/delete_profile. No prerequisites (e.g., needing a valid profileId or workspace context) are mentioned.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful default behavior (first page, default order) but says nothing about permission requirements, maximum result bounds, or response shape.

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 followed by the optional behaviors and default. Slightly redundant with the title but free of filler.

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

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

For a read-only listing tool with no output schema and fully documented parameters, the description gives an agent enough to invoke it correctly, including the default paging behavior. It could mention permissions or result caps but is otherwise complete.

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

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

Schema description coverage is 100%, so every one of the 7 parameters (id, name, start, total, sorting, location, workspaceId) is documented in the schema with defaults and format guidance. The description adds no parameter details beyond noting that filtering, sorting, and limiting exist, so 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?

The description states a specific verb and resource ('retrieves a list of folders available in the specified workspace'), and the name/title scope it to profile folders. It does not explicitly distinguish itself from the similar sibling get_proxy_folders, but the resource is otherwise 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?

It describes that the filters, sorting, and result limiting are optional and what happens by default ('returns the first page of profile folders in the default order'). However, it never says when to prefer this over get_profiles or get_proxy_folders, so usage 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered without the description. The description adds that attributes are returned and that filtering is optional, but says nothing about pagination behavior or result limits, which are relevant for a list 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 with no filler, and the core purpose is front-loaded. Slightly verbose framing ('This method retrieves...') costs it the top score but nothing is wasted.

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

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

There is no output schema, but the description indicates that profile attributes are returned, and the schema fully documents all nine parameters including pagination and tag-operator semantics. For a filtered-list tool this is close to complete, though pagination defaults and page-size behavior go unmentioned 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 description coverage is 100%, so all nine parameters are already documented in the schema, including enum values, defaults, and sorting string format. The description only names the filterable fields (ID, name, tags, sorting) and adds no syntax, default, or interaction detail beyond the schema, so 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 (retrieves a list of profiles with their attributes) and scopes it to a workspace and folder. It does not explicitly distinguish itself from the sibling get_profile (singular) or explain why an agent would pick this over that, so it falls short of a 5.

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

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

Usage is only implied: 'It is possible to optionally filter results by ID, name, tags, and sorting' suggests a filtered-list use case. There is no explicit when-to-use, when-not-to-use, or routing to alternatives such as get_profile for a single record.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world behavior. The description adds only the default-paging behavior, which is marginally useful but lacks detail on result limits, total counts, or ordering guarantees beyond what the schema defaults imply.

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 capability and ending on default behavior. The phrase "provides functionality for" is mild filler, but there is no real bloat.

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 paginated list tool with full schema coverage, complete annotations, and no output schema, the description covers purpose, filterable dimensions, and default behavior adequately. Minor gaps around result limits are already handled by schema defaults.

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 fully documents all 8 parameters, making baseline 3 appropriate. The description aggregates the filterable fields (workspace ID, folder ID, proxy ID, name, sorting) but notably omits proxyUri, so it adds little beyond the schema and is slightly incomplete.

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 clear resource (proxies) and the operations applied (filtering, sorting, pagination), so an agent knows this is a listing tool. It does not explicitly contrast itself with siblings like get_proxy_folders or the single-proxy mutations, but the read/list intent 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?

The final sentence describes default behavior when no parameters are supplied ("default page of proxies in standard order"), which is genuinely useful context. However, there is no explicit when-to-use vs alternatives guidance and no named alternative for retrieving a single proxy.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds one non-obvious behavior -- default pagination and sorting when parameters are omitted -- but says nothing about return volume limits or filter interaction.

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 purpose. There is mild redundancy between the title's 'filtering, sorting, and pagination options' and the body's restatement of the same capabilities, but nothing is bloated.

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

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

For a read-only list tool with full schema coverage and no output schema, the description covers purpose, optional refinement, and default behavior. Missing only differentiation from sibling list tools, which is the main residual gap.

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

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

Schema description coverage is 100%, so every parameter (id, name, start, total, sorting, location, workspaceId) is already documented, including the sorting string format and the -1 workspace convention. The description adds no parameter meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('get the list of proxy folders'), which is clearer than the bare name. However, it never distinguishes itself from near-identical siblings like get_profile_folders or get_proxies, leaving the agent to infer the resource boundary from the name 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?

It describes how optional parameters refine results and what happens when none are supplied ('first page ... default sorting order'), which gives useful invocation context. But it offers no when-to-use guidance relative to the sibling folder/proxy list tools and no 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?

Annotations do not cover error behavior, and the description usefully discloses that the call throws when no instance is running — a genuinely additive detail. However, it says nothing about the error type/message, what the returned instance object contains, or why a getter carries readOnlyHint=false. The annotation/description pairing is odd but not directly contradictory.

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

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

A single short sentence with no waste, but it is not front-loaded with the primary behavior — it leads with the exception case and omits the success path entirely, which is the wrong emphasis for a getter.

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 no output schema and no annotations describing the return value, the description is the agent's only source for what this call produces, and it is silent on that. Nothing explains the payload shape or how it differs from the sibling list-style browser instance 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 100%, so both profileId and workspaceId (including the -1 default meaning) are already fully documented in the schema. The description adds no parameter-level semantics beyond that, so the baseline 3 applies.

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

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

The description only states the failure mode ('Throws if no browser instance is currently running for the given profile') and never says what the tool does on success or what it returns. The actual purpose is carried entirely by the title, and the description does not distinguish this tool from the sibling get_browser_instances (plural).

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

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

There is no guidance on when to call this versus get_browser_instances, focus_browser_instance, or start_browser_instance. The only usage signal is implicit: the tool is meant for profiles that already have a browser running, but that is left for the agent to infer.

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

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

The description says the tool "Retrieves" status, which is unambiguously a read operation, while the annotations declare readOnlyHint=false. This is a direct semantic conflict on the read/write axis and warrants the annotation-contradiction flag. No other behavioral context (polling behavior, what happens on an unknown run ID, auth needs) is provided.

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

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

It is a single short sentence with no filler, so it is not bloated. But it duplicates the title verbatim, meaning the sentence does not earn its place by adding information; concision here reflects under-specification rather than discipline.

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

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

There is no output schema, so the description is the only place an agent could learn what "per-profile status" returns (per-profile objects, state fields, terminal vs running states) and it says nothing. For a status-query tool with no return documentation and no usage guidance, the definition is incomplete.

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

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

Schema description coverage is 100%: the body UUID and workspaceId (with -1 default meaning default workspace) are both fully documented in the schema, including the pointer back to RunCookieRobot. The description adds nothing about parameters, but with full schema coverage the baseline of 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?

Tautological: description restates name/title.

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

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

There is no explicit when-to-use, when-not-to-use, or named alternative. The phrase "previously started script run" weakly implies this is a polling tool that requires a run created by run_cookie_robot, but the agent must infer that. No guidance on polling cadence or terminal states.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds only that the tariff is 'current' and scoped to a specified workspace, which is minimal but useful context beyond the annotations and 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?

One sentence, front-loaded with the action and resource, no redundant clauses. Appropriately sized for a simple getter.

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 one-parameter read-only getter, the annotations and schema cover invocation adequately. However, with no output schema, the description does not explain what the tariff response contains, leaving a small gap for the agent.

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

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

Schema description coverage is 100% and the sole parameter is fully documented in the schema, including the default -1 meaning default workspace. The description references workspace scoping but adds no format or syntax detail beyond what the schema provides, so 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?

The description states a specific verb ('returns') and resource ('the current tariff') scoped to a workspace. It is clear enough to distinguish from siblings like get_limits because no other tool returns tariff data, though it does not explicitly name any sibling.

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

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

There is no guidance on when to prefer this tool, what prerequisites exist, or what alternatives exist. An agent must infer usage from the purpose alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds no behavioral context beyond that - no pagination behavior, no note about the default 1000 result cap or performance implications, no description of what the returned thread entries contain.

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 front-loaded sentences with no padding, and the primary purpose comes first. It is efficient but so terse that it carries little information for its length.

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?

Six optional parameters, no output schema and no indication of the returned thread shape or pagination semantics. Workspace scoping is mentioned but the -1 default-workspace convention and the large default page size are left entirely to the schema, making this only minimally sufficient.

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

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

Schema description coverage is 100%, so baseline is 3. The description touches on token/type filtering, result limiting and sorting, but adds no meaning beyond the schema - it never clarifies the vague sorting string format, and it omits workspaceId and pagination start entirely.

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 ('retrieves') and resource ('list of execution threads') scoped to a workspace, which is clear. It does not, however, contrast itself with nearby siblings like get_browser_instances or get_running_browser_instance, leaving a small ambiguity for an agent picking among retrieval 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?

The second sentence only restates available filters, limits and sorting rather than saying when to choose this tool over alternatives such as get_browser_instances. No prerequisites, no exclusions, no alternative routing is given.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds the prerequisite-for-subsequent-queries context, but says nothing about pagination behavior or result size despite having start/total parameters.

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, and the core purpose is front-loaded. The first sentence is a near-verbatim restatement of the title, which is mildly redundant but not harmful.

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

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

For a read-only list tool with full schema coverage and no output schema, the description covers what is returned and why it matters (prerequisite for later queries). It is sufficient to call the tool correctly, though it could note that filters are optional and results are paginated.

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

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

Schema description coverage is 100%, so all five parameters (id, name, roles, start, total) are already documented in the schema. The description adds no filtering or pagination semantics beyond what the schema provides, which is the expected baseline of 3 when the schema does the heavy lifting.

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 ('retrieves') and resource ('list of workspaces') with the scope qualifier 'accessible to the current user', so an agent knows exactly what it returns. It does not need to differentiate from siblings since no other workspace-list tool exists in the sibling set, but it also does not explicitly say so.

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?

'This information is required to execute most subsequent queries' gives a useful ordering hint (call this before other queries), which is more than nothing. However, there are no explicit when-not conditions and no named alternative, so it stays at implied usage rather than clear 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?

The description states 'Cookies will overwrite existing cookies in the profile,' which is a non-additive, data-replacing update, yet the annotation declares destructiveHint=false (defined as additive-only updates). This directly contradicts the annotation, so per the rubric it scores 1 and is flagged.

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 with no filler; the purpose is front-loaded and the overwrite warning is placed where it matters. The middle sentence re-states the format already given in sentence one, which is minor 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 3-parameter mutation with no output schema, the description covers purpose, format, and the overwrite side effect. It omits error/permission behavior and what is returned, and the misleading 'cookies parameter' naming leaves an agent to reconcile it against the 'body' property.

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 documents profileId, body, and workspaceId, giving a baseline of 3. The description adds a JSON-validity requirement but refers to a 'cookies parameter' that does not exist in the schema (the actual parameter is 'body'), which is slightly confusing rather than clarifying.

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 ('importing cookies into an existing profile in JSON format'), which is clear enough to separate it from export_cookies and copy_cookies. It does not name or contrast any sibling explicitly, so it stops short of a 5.

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

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

Usage is implied (import cookies into an existing profile) and it adds one relevant caution — existing cookies will be overwritten — but there is no explicit 'use this instead of copy_cookies/export_cookies when...' guidance or stated prerequisites (e.g., profile must exist/be unlocked).

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

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, non-idempotent). The description adds one genuinely useful behavior detail: the move is scoped 'within the workspace,' which implies cross-workspace moves are impossible. It says nothing about what happens if targetFolderId does not exist, whether the operation is atomic across multiple profile IDs, or what happens to profiles already in the folder.

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

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

A single sentence with no filler, and the action and destination are front-loaded. It is slightly redundant with the title but not wasteful.

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 mutation with full schema coverage and annotations carrying the safety profile, the definition covers the essential who/what/where. Remaining gaps (failure behavior for invalid folder IDs, partial-move semantics) are modest, and no output schema means 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 description coverage is 100%, so the schema already explains body (array of profile IDs), workspaceId (-1 = default), and targetFolderId (destination). The description only restates 'one or more browser profiles' and 'specified target folder,' adding no format, constraint, or default information beyond the schema. 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?

The description states a specific verb (moves) and resource (browser profiles) plus the destination (target folder), so it is clearly differentiated from read-only siblings like get_profiles and from update_profile, which changes profile attributes rather than location. It does not explicitly name or contrast with any sibling, 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives (e.g., update_profile for attribute changes, or folder-creation siblings to ensure the target exists). An agent must infer that this is the reorganization tool purely from the name and description.

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