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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it states that checks run sequentially ('one after another'), warns about the time cost ('up to about ten seconds each'), explicitly says 'Changes nothing' (reinforcing read-only), and discloses that profiles without a proxy are reported as such. This is useful operational detail that annotations don't provide.

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 with no wasted words. The core action is front-loaded, the timing caveat is placed early, and the safety guarantee ('Changes nothing') and edge-case behavior ('Profiles without a proxy are reported as such') are each given a single efficient sentence. Every sentence earns its place.

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

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

For a simple one-parameter tool with no output schema, the description covers the essential operational context: what it does, how long it takes, that it's non-destructive, and how missing proxies are handled. The only minor gap is that it doesn't describe the return format or how results are presented, but given the tool's simplicity and the annotations covering safety, this is a small omission.

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 the 'profiles' parameter fully. The description adds the semantic nuance that omitting the parameter checks every profile available to the agent, which is a meaningful addition beyond the schema's 'omit to check every profile' phrasing. However, since the schema already covers the parameter well, the description's contribution is modest, warranting the baseline 3.

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

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

The description clearly states the tool's function: testing proxies for profiles, with a specific verb ('Test') and resource ('proxies of several profiles'). It also distinguishes itself from siblings by mentioning the batch behavior (multiple profiles or every profile) and the fallback when no list is given, which differentiates it from the singular 'check_proxy' 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?

The description explicitly explains when to use this tool: to test proxies of several profiles or all profiles, and notes the alternative behavior when no list is provided. It also implies a contrast with the singular 'check_proxy' sibling by focusing on batch operations. The timing warning ('up to about ten seconds each') gives clear context for when this tool is appropriate versus a faster single-check alternative.

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

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

Annotations already declare readOnlyHint=true, and the description reinforces this with 'Changes nothing' while adding useful behavioral context: it makes a real request, can take up to about ten seconds, and reports connectivity, IP, country, and latency. This exceeds the annotations' safety-only coverage without contradicting them.

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 compact sentences with no filler: the first states the action and expected outputs, the second adds side-effect and timing constraints, and the third routes to the sibling tool for multi-profile use. Every sentence earns its place and the key info is front-loaded.

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, low-complexity tool with no output schema, the description covers everything an agent needs: what it does, what it returns, that it is non-destructive, how long it may take, and when to choose the sibling tool. No critical gap remains.

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 already documents that 'profile' is the exact name returned by list_profiles. The description adds little beyond specifying the single-profile scope, so the baseline of 3 is appropriate; the schema carries the parameter-semantics burden.

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

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

The description uses a specific verb ('Test'), identifies the resource ('one profile's proxy'), and enumerates the delivered information: whether it answers, exit IP and country, and latency. It also clearly distinguishes itself from the sibling check_proxies, so an agent can immediately tell which tool is which.

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

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

The description explicitly tells the agent when to use the alternative tool: 'For several profiles use check_proxies instead.' It also clarifies the single-profile scope and the approximate time cost, giving clear decision criteria without requiring schema inspection.

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

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

Annotations already indicate the tool is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds valuable behavioral context: the profile is created on disk, it is not launched, it fails on duplicate names, and it is 'allowed for the agent.' It does not contradict annotations and provides a clear side-effect picture beyond the boolean hints.

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

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

The description is three sentences with zero filler. The core action and primary constraint (name uniqueness) are front-loaded, and the alternative tool is named early. Every sentence earns its place, and the structure makes it easy to scan.

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 covers the essential outcomes: success (profile created and allowed) and failure (name already taken). It also clarifies the tool's limitation (does not launch) and points to relevant siblings. Minor omission: it does not state what the return value is on success, but that is unlikely to be critical for a creation tool. Overall, it is sufficiently complete for correct invocation.

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

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

Schema coverage is 100%, so the schema already documents all five parameters thoroughly. The description adds one extra piece of semantic context: that proxy, note, and category can be set later via set_proxy and profile_note, which implies they are optional at creation time. This goes slightly beyond the schema's per-field descriptions, so a 4 is justified.

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

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

The description states a specific verb and resource ('Create a new, empty Chrome profile on disk') and immediately distinguishes it from a sibling ('It is not launched: call start_profile for that'). It also mentions the failure condition that differentiates it from list_profiles. This gives an agent a precise, unambiguous understanding of what the tool does.

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

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

The description explicitly states when not to use this tool ('It is not launched: call start_profile for that') and provides a prerequisite check ('use list_profiles to see existing names') to avoid a known failure. It also notes that proxy, note, and category can be set later with set_proxy and profile_note, guiding the agent on alternative workflows. This is exemplary 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 readOnlyHint=true, and the description reinforces that with 'Read-only.' It adds valuable non-obvious behaviors: the owner-allowed visibility scoping via the 'API' column, the exact list of returned fields, and that the proxy password is hidden. This exceeds the minimum bar set by the read-only annotation.

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

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

Three sentences with no filler: purpose is front-loaded, the field list is compactly enumerated, and the critical 'call it first' usage note lands at the end. Every sentence earns its place.

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

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

For a 0-param, read-only list tool with no output schema, the description is complete: it states what is listed, the visibility constraint, every returned field, and the security-relevant detail that passwords are hidden. An agent has everything needed to call it correctly and interpret its result.

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 explain about arguments. Per the baseline for 0-param tools, a 4 is appropriate; the description needs only to describe the operation and result, which it does thoroughly.

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

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

The description opens with a specific verb+resource: 'List the browser profiles the owner has allowed for the agent.' It further distinguishes itself from siblings by clarifying scope ('other profiles are invisible here'), marking itself read-only, and positioning itself as the prerequisite for all other profile 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 description gives explicit when-to-use guidance: 'Call it first: every other tool takes a profile name exactly as listed here.' This clearly points to the tool as the entry point for all profile operations. It does not, however, name a specific alternative for a given condition or state an explicit 'when not to use' case, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true, and the description reinforces this with 'Read-only'. It adds extra behavioral context by stating 'File contents are never shown' and that it reports whether the program is installed, which goes beyond the annotation.

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

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

The description is two sentences, front-loads the resource and purpose, and wastes no words. Every clause adds 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 zero-parameter, read-only tool with no output schema, the description fully specifies what is returned (file name, program, installed status) and its constraints. No missing information for correct invocation.

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

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

The tool takes no parameters, so there is nothing to add beyond the schema. The baseline score of 4 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 (list) and resource (scripts in Morfiade's folder), and specifies exactly what information is shown: file name, the program that runs it, and whether that program is installed. It clearly distinguishes itself from siblings like list_profiles and list_trash by focusing on scripts.

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 makes the tool's purpose unambiguous, but does not explicitly state when to use it versus alternatives. However, the context is clear: it is the only script-listing tool among siblings, so an agent would naturally select it when script info is needed.

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 repeats the readOnlyHint annotation but adds useful context beyond it, including the exact output fields and the connection to restore_profile. For a simple read-only list operation, this is sufficient behavioral disclosure.

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

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

The description is two concise fragments/sentences with no filler. The scope is front-loaded, the output details are compact, and the cross-reference to restore_profile earns its place.

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

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

With zero parameters and no output schema, the description covers what the tool returns and how to use the result. Nothing essential for invoking or understanding this tool is missing.

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

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

The tool has no parameters, so there is no parameter ambiguity. The baseline of 4 applies because the description doesn't need to explain parameter semantics that do not exist.

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

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

The description clearly identifies the resource: profiles in the recycle bin, and what information is returned: name, deletion time, and disk usage. It also distinguishes itself from siblings like list_profiles and restore_profile by the trash scope and the read-only note.

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

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

It explicitly says the returned names are meant for use with restore_profile, which provides a direct follow-up action. It does not explicitly contrast against list_profiles, but the recycle-bin scope makes the intended use obvious.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false. The description goes further by specifying that a passed field overwrites the old value, an omitted field persists, and a call with neither optional field performs only a read. This transparently discloses the mutation semantics and the no-mutation path.

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 each carrying distinct information: the core purpose, the read condition, and the parameter/overwrite semantics. No repetition of schema details and no unnecessary fluff.

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

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

The tool is simple, annotations are rich, and invocation behavior is fully explained. However, since there is no output schema, the description does not explicitly state what a read operation returns (e.g., the note and title structure). This is a minor but real gap for an agent that relies on expected return values.

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 value by connecting the optional parameters to behavior: omitting both yields a read, and each omitted field preserves its prior value. This reinforces and extends the schema's 'omit to keep' descriptions.

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

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

The description opens with 'Read or write a profile's note', giving a specific verb and resource. It clearly differentiates this tool from siblings like profile_tags or list_profiles by targeting the note content, and it explicitly explains the read versus write modes based on parameter presence.

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

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

It states that omitting title and note triggers a read, and passing a field overwrites while omitting keeps the existing value. This gives clear when-to-use guidance for both modes, but it does not explicitly mention alternative tools or when not to use this one, so it misses a 5.

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

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

Even though destructiveHint=true already flags mutation, the description goes further by explaining the whole-set replacement semantics: omitted tags are removed, an empty list clears all tags, and reading requires omitting tags. This is valuable behavioral context beyond the annotations and prevents the common mistake of treating the tool as additive.

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 with no filler. The core behavior is front-loaded ('Read a profile's tags, or replace them all'), and each subsequent sentence adds a distinct edge-case or usage 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?

For a two-parameter tool with no output schema, the description covers the key scenarios: read mode, replace mode, removal of omitted tags, empty-list clearing, and how to add a single tag. It doesn't explicitly describe the return value of a read, but the behavior is simple enough that this is a minor gap.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful nuance on top: it explains the conditional behavior of tags (omit vs. present vs. empty) and gives explicit guidance for appending a tag by reading first and passing the old list plus the new tag. This goes beyond the schema's already good parameter descriptions.

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 operation on a specific resource: read or replace a profile's tags. It clarifies the dual-mode behavior immediately, and the resource is clearly distinct from sibling tools like list_profiles, profile_note, and trash_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?

The description gives clear conditional usage: omit tags to read, provide tags to replace, pass an empty list to clear. It even provides a concrete recipe for adding a single tag. It does not name alternatives, but no sibling tool overlaps with tag management, so this is clear context without exclusions.

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

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

With no meaningful annotation coverage (all hints false), the description carries the full burden and discloses key behaviors: cookies and sessions are restored, name collisions are resolved by renaming to 'name (2)', nothing is overwritten, and the response reports the final name. This is substantial transparency beyond a bare 'restore' statement.

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 with no filler: the first states the action and scope, the second states the collision behavior and output. The most important safety detail ('nothing is overwritten') is front-loaded alongside the rename behavior.

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 tool with no output schema, the description covers the goal, the key edge case, and the fact that the response names the final profile. It stops short of spelling out error cases or explicitly telling the agent to find candidates via list_trash, so there is a small completeness gap.

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

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

The single parameter is already fully described in the schema with 100% coverage, and the description adds no new parameter-format or constraint detail beyond referring to the profile by name. Baseline 3 is appropriate because 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 uses an explicit verb ('restore' / 'bring back') and target ('profile'), and specifies the source ('recycle bin') and scope ('with its cookies and sessions'). This makes it distinct from siblings like trash_profile and list_trash.

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 'Bring a profile back from the recycle bin' gives clear context for when to use this tool: recovering a previously trashed profile. It does not explicitly name alternatives or exclusions, such as what to do when the profile is not in the trash, which keeps it from a 5.

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

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

Annotations already mark the tool as destructive and idempotent; the description adds crucial behavioral nuance beyond that: the effect is deferred until the next launch, and running profiles are unaffected until restarted. This goes beyond what annotations convey and helps the agent anticipate side effects.

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

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

The description is two sentences: the first states the core action and the removal case, the second covers timing and verification. Every clause earns its place, and the most critical information is front-loaded. There is no redundancy or fluff.

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

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

For a setter with three parameters and no output schema, the description covers the action, the effect timing, and the recommended verification step. It also implicitly signals that existing proxies are overwritten, and the schema handles format details. Nothing an agent needs to call it correctly is missing.

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

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

The schema already provides full descriptions for all three parameters (100% coverage), including the empty-string removal behavior and the default protocol. The description adds no additional parameter-specific information, so the baseline 3 applies; it does not need to compensate for gaps.

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: 'Save a proxy in a profile's settings, replacing the current one; an empty string removes it.' This clearly distinguishes it from siblings like check_proxy (which verifies) and list_profiles (which lists), leaving no ambiguity about the tool's function.

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

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

It provides clear timing guidance ('Takes effect on the next launch: a running profile keeps its old proxy until stop_profile and start_profile') and recommends a follow-up action ('Run check_proxy afterwards to see whether it works'). It does not explicitly enumerate when not to use it or name alternative setters, but the context is strong enough for an agent to decide.

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

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

Annotations already indicate mutation, open-world, and non-idempotent behavior, and the description adds substantial detail: real Chrome window, cookie/session/proxy isolation, the new-tab behavior for running profiles, a one-minute latency bound, and the licensing requirement. No important behavioral surprises are hidden.

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

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

Four sentences, each carrying a distinct fact; the core action is front-loaded and the caveats (delay, license, no post-launch driving) are grouped at the end. Nothing is redundant.

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

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

For a state-changing launch tool with no output schema, the description conveys the critical launch behavior, edge case, timing, prerequisites, and limitation. An agent has enough context to invoke it correctly and know what to do next.

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 profile and url. The description adds useful operational context (e.g., URL opens in a new tab when the profile is already running), but it only minimally elaborates on parameter-specific semantics beyond what the schema 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 opens with a concrete action and resource: 'Launch a profile: opens its real Chrome window...' It clearly distinguishes the tool from siblings like list_profiles, status, and stop_profile, and explains the already-running edge case. This makes the tool's role unambiguous.

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

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

It states when the tool is appropriate (launching a profile or opening a URL) and when it is not: the agent cannot drive the page afterwards. It names browser_command as the alternative and notes that the owner must enable it separately, plus the license prerequisite and potential delay.

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

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

The readOnlyHint annotation already covers read-only safety, and the description adds useful behavioral context: it is instant and serves as a liveness check. This goes beyond the structured annotations without contradicting them.

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

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

Two short sentences: the first packs the tool's output content, the second gives the key usage directive. Every phrase earns its place and the most important operational guidance is front-loaded.

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

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

For a zero-parameter, read-only health-check tool, the description covers purpose, output content, behavior, and when to call it. No output schema is needed because the description already states the key returned information.

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

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

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter meanings, and it correctly focuses on output and usage instead.

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

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

The description clearly states what the tool reports: Morfiade version, profile counts, and running profile counts. It lacks an explicit verb like 'returns' or 'lists', but the resource and scope are unambiguous and distinct from profile-management 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 explicitly says to use this tool to check that the manager is reachable before anything else, which is strong contextual guidance. It does not name alternative tools or exclusion conditions, but for a zero-parameter status check none are really needed.

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

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

The description goes well beyond the annotations by explaining that cookies, sessions, and history persist, anything not submitted is lost, and calling it on a stopped profile is safely idempotent and reports already_stopped. This adds valuable non-obvious behavior without contradicting 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?

Three focused sentences: the primary action, the persistence guarantee, and the idempotent edge case. No filler or redundancy, and the most important information is front-loaded.

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

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

For a single-parameter tool with no nested objects and no output schema, this description is complete. It covers the expected behavior, non-deletion guarantees, the stopped-profile case, and the return signal. Nothing needed for correct invocation is missing.

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

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

Schema description coverage is 100%, with the parameter 'profile' already clearly documented as requiring the exact name from list_profiles. The description adds no additional parameter-level detail, so the baseline score 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?

The description states a specific verb and resource: 'Close a running profile's Chrome window.' This clearly distinguishes stop_profile from sibling tools like start_profile, status, and trash_profile. The scope is precise and actionable.

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

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

It provides clear usage context: it applies to a running profile and is harmless on a stopped profile. It does not explicitly name alternatives or say 'use start_profile to reopen', but the intended use case is evident and edge-case behavior is addressed.

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

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

Annotations already indicate destructiveHint=true, but the description adds essential detail: the insertion cannot be undone and requires manual field focus. It also explains behavior for windows without a pinned line. These go beyond the annotations and give the agent a precise mental model of side effects.

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

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

The description is compact but dense; every sentence adds value: the main action, the manual precondition, the irreversibility, and the fallback behavior. It is front-loaded with the primary action and avoids redundancy. Slightly complex due to multiple clauses, but 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 tool with two parameters, full schema coverage, no output schema, and annotations, the description covers the essential workflow: prerequisites (sync_spread), human interaction requirement, side effects (cannot undo), and behavior for edge cases (windows without pinned lines). An agent can invoke it correctly without additional 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 coverage is 100%, so both parameters (set and leader) are documented. The description adds context about the leader's role (the window with cursor receives the values) and the default behavior, but this is mostly a restatement of the parameter description. It does not substantially deepen parameter understanding 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 clearly states the tool's action: inserting each window's pinned value into the field focused in the leading window. It distinguishes itself from sync_spread by focusing on the insertion step and mentioning the prerequisite. The verb 'type' and the resource 'input field' make the purpose 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 provides clear usage context: it must be called after sync_spread, and a person must click into the field first. It implies this is the insertion step, though it does not explicitly contrast with sibling sync tools beyond mentioning sync_spread. The precondition is clearly stated.

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

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

The description usefully discloses that listing shows line count and free lines and that values are 'never shown'. However, with all annotations false, it leaves create-mode behavior vague: what happens if a set name already exists, whether creation returns a result, or whether sets can be modified later.

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 with no wasted words. The core purpose and both invocation modes are front-loaded, and the critical safety-relevant detail that values are never shown is included.

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 annotation support, the description partially compensates by describing list output. It remains incomplete for the create path: no mention of duplicate-name behavior, any errors, or what creation returns.

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%, with descriptions already explaining name and lines, including 'one per window. The description mostly restates the same parameter semantics and domain examples, adding only the 'line count/free lines' detail that is more about output than parameters.

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

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

The description clearly identifies the resource ('value sets for distributing across windows') and gives specific behaviors: list existing sets with line counts/free lines, or create a new set with name and lines. It is clear enough to distinguish 'sets' from sibling tools like sync_windows or sync_insert, though it never names an alternative explicitly.

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

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

The description clearly explains the two usage modes: no arguments for listing, and name plus lines for creating. This is clear practical context, though it does not explicitly say when to prefer a sibling tool over sync_sets.

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

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

Annotations already mark idempotentHint=true, but the description goes further by explaining the actual repeat behavior and its consequence: windows that already hold a line keep it, preventing account/email mismatches. It also discloses that the tool reports assignments and does not type. No contradiction with annotations.

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

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

Three sentences with no filler: the first states the core function, the second disambiguates from sync_insert, and the third explains idempotency. The most important information is front-loaded.

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, idempotent assignment tool with no output schema, the description covers the operation, the key sibling alternative, and the return behavior ('report who got what'). It could clarify edge cases around 'free' and 'ready', but nothing essential is missing.

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

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

Schema description coverage is 100%, so the two parameters (set and profiles) are already documented in the schema. The description adds domain context like 'free line' and 'ready window' but does not provide extra parameter syntax or format details, 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?

The description states a specific action and resource: pin one free line of a set to each ready window and report who got what. It also explicitly distinguishes itself from the sibling tool sync_insert ('Types nothing; that is sync_insert'), so an agent can tell them apart.

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 names sync_insert as the alternative and clarifies that this tool does not type, which gives clear routing guidance. It does not discuss other siblings like sync_windows or sync_sets, but the contrast plus the repeat-safety note provides adequate usage context.

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

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

Annotations already declare readOnlyHint=true, so the 'Read-only' mention is redundant, but the description adds useful context: it lists reasons for windows that cannot participate, and indicates the output includes current values. This goes beyond the annotation and gives an agent a sense of what to expect from the response.

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 concise sentences. It front-loads the core purpose, then adds the reason-listing behavior and the usage directive. 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 zero-parameter, read-only tool with no output schema, the description covers the purpose, usage timing, and output nature (windows with values and reasons). An agent can confidently decide when to call it and interpret the result.

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

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

The tool has zero parameters, so the baseline of 4 applies. The description needs no parameter explanation since there are none to clarify.

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 explicitly states the tool lists open profile windows, which ones can participate in value distribution, and the value each holds. It also notes that non-participating windows are listed with reasons. This clearly distinguishes it from sibling tools like sync_spread and sync_insert, which perform the actual distribution, by framing sync_windows as a read-only inspection step.

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

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

The description explicitly instructs to call it before sync_spread and sync_insert, giving a clear temporal ordering. It also implies the tool is for checking eligibility and current values before any distribution, which is a distinct use case among the sync-related siblings.

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

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

With readOnlyHint=false and destructiveHint=false, the annotations already indicate a non-read, non-permanent mutation. The description adds substantial behavioral detail: profiles keep cookies and sessions, running profiles are closed first, and emptying the bin is unavailable to the agent. These go beyond the annotations and provide crucial operational 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?

Three sentences, each carrying distinct value: primary action, non-destructive guarantee + recovery path, and two behavioral constraints (closing running profiles, no emptying). No filler or redundancy; the most important information is front-loaded.

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

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

For a single-parameter tool with no output schema and annotations already covering mutation/non-destructiveness, the description explains what happens to the profile, how it can be recovered, the effect on running instances, and an agent-side limitation. An agent has everything necessary to invoke this tool correctly.

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

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

Schema description coverage is 100%: the 'profile' parameter is already documented as 'Profile name exactly as list_profiles returns it'. The tool description adds no further parameter-specific guidance, so it meets the baseline of 3 without exceeding it.

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

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

The description uses a specific verb and resource ('Move a profile to Morfiade's recycle bin') and immediately clarifies what it is not ('Nothing is erased'), which distinguishes it from deletion and from restore_profile. It also notes that a running profile is closed first, differentiating it from a plain stop_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?

The description implies the use case: temporarily removing a profile while preserving cookies/sessions, with restore_profile as the recovery path. It explicitly states the agent cannot empty the bin, which sets expectations. It does not explicitly name alternatives or say 'use this when…', but the context is clear enough for an agent to choose it over stop_profile or deletion.

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