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

Annotations are limited to openWorldHint=false and destructiveHint=false. The description adds valuable behavioral details: duplicates are detected and skipped silently, a 500-per-call limit, and that only three fields are required. This goes beyond the annotations and helps the agent understand side effects and 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?

The description is extremely concise: two sentences, front-loaded with the core action. Every sentence adds useful information: the operation, the limit, required fields, and duplicate handling. No wasted words.

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

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

With one parameter and no output schema, the description covers the key aspects: what it does, limits, required fields, and duplicate behavior. It does not detail the return value or error handling, but for a create-like operation with a well-structured schema, this seems adequate. Sibling tools are differentiated, and the behavior is clearly scoped.

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

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

Schema description coverage is 0%, so the description must compensate. It does mention the three required fields, which aligns with the schema, but it does not explain optional parameters or values like proxy_type enums. The schema itself contains descriptions for nested fields, so the description adds some value but not comprehensive parameter guidance.

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: 'Save one or more proxies' with a specific verb (save) and resource (proxies). It distinguishes from sibling tools like list_proxies, update_proxy, and delete_proxy by focusing on adding new entries. The mention of 'max 500 per call' and duplicate handling further clarifies scope.

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

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

The description provides clear context for when to use the tool (adding proxies) and specifies required fields ('proxy_type / proxy_host / proxy_port are required') and a constraint (max 500). However, it does not explicitly state when not to use it or mention alternatives, though the operation is straightforward and sibling tools are distinct in purpose.

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 adds context about what is verified (client reachability, Local API, API key). It does not elaborate on error behavior or return format, but for a simple diagnostic check, this is adequate.

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 action, and no redundancy. Every word 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?

Given the tool has no parameters, a read-only annotation, and no output schema, the description sufficiently covers purpose and usage context. It explains why and when to use the tool, which is complete for its simple scope.

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 description has no parameter burden. Baseline for 0 parameters is 4, and the description doesn't need to explain any input semantics.

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 verifies FlashID client reachability and API setup, using a specific verb ('verify') and resource. It distinguishes from siblings like 'check_proxy' by focusing on the FlashID desktop client and API key setup.

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 'Call this first when any other tool fails, to diagnose the setup' provides explicit conditional usage guidance. It clearly tells the agent when to invoke this tool relative to others, even though it doesn't name alternatives.

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

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

Annotations already indicate the operation is read-only, and the description adds useful behavioral context: 'May take up to a minute for slow proxies' and that it works with 'saved or not' proxies. This provides latency and scope hints beyond the structured 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?

The description is just two sentences, front-loaded with the primary action and outcome, followed by a relevant caveat. There is no redundant or filler content; every word contributes 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?

The description covers the core purpose, return value summary, and a latency caveat, which is adequate for a simple tool. However, it lacks parameter explanations and does not differentiate from the sibling tool check_connection, which could be similarly used. Given no output schema, the return info is only high-level.

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 low (20%), only describing the port parameter. The description does not explain host, type, username, or password fields, nor does it compensate for the lack of schema descriptions. The phrase 'saved or not' hints that parameters can be provided directly, but no field-level semantics are given.

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 connectivity') with a clear resource ('a proxy') and distinguishes from siblings by noting 'saved or not' (works with ad-hoc proxies). It also specifies the return value ('detected exit IP and geo info'), making the tool's purpose unmistakable.

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

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

The description clearly implies when to use this tool: to verify a proxy's connectivity and get its exit details, whether the proxy is saved or not. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to decide between this and other proxy-related tools like list_proxies or check_connection.

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 provide idempotentHint=true and destructiveHint=false. The description adds the 'by profile UUID' scoping, which is useful, but it does not go beyond that to describe error behavior, effects on profile data, or what happens when a browser is not running. Given the annotations, this is adequate but not exceptional.

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 sentence with no filler, effectively conveying the tool's purpose in minimal words. It earns every character and is well 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?

This is a simple one-parameter tool with clear annotations (idempotent, non-destructive). The description explains what it does and the schema covers the parameter. Minor gaps like error handling or behavior for missing UUIDs are not critical, but a slightly more detailed description could have noted that closing is a no-op for non-running browsers, though that is implied by idempotentHint.

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 input schema fully describes the single parameter 'profile_uuids' as 'Profile UUIDs to close', and the description echoes 'by profile UUID'. No additional semantic value is added beyond what the schema already provides, 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 clearly states the action (close), the resource (running browsers), and the identifying key (profile UUID). It effectively distinguishes this from siblings like open_browser and list_running_browsers by specifying both the operation and its scope.

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

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

The phrase 'running browsers' implies that this tool is for browsers already open, and that one might first use list_running_browsers to get UUIDs. However, the description does not explicitly mention when to use this tool versus alternatives, nor does it note any exclusions or prerequisites.

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

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

Annotations indicate destructiveHint=false and openWorldHint=false, but the description adds no behavioral details beyond the basic 'create' action. It does not mention error behavior on duplicate names, whether parent folders are created, auth requirements, or return values. The description is silent on these important aspects for a mutating 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?

The description is a single short sentence, which is concise but under-specified. It does not waste words, but it also fails to include valuable context that could be added without significant expansion. It is not tautological, but it borders on being too sparse to be informative.

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

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

Given the tool has no output schema and only one parameter, the description still omits critical information such as return values, error handling, and any constraints on the folder name. It does not explain the purpose of a 'profile folder' within the broader system, leaving the agent with an incomplete understanding of the tool's 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?

The schema has 100% coverage for the single parameter 'name' with a generic description 'Folder name'. The tool description does not add any additional semantic meaning to the parameter, so the baseline of 3 applies since the schema carries the burden of parameter documentation.

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 'Create a profile folder' clearly states the verb (create) and resource (profile folder), which distinguishes it from sibling folder operations like update_folder and delete_folder. It is specific enough to convey the core function, though it lacks any additional context about what a profile folder is.

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 no guidance on when to use this tool, any prerequisites, or how it compares to alternatives such as create_profile or list_folders. There is no mention of checking for existing folders or when it should be invoked instead of other create operations.

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?

Beyond the annotations (openWorldHint=false, destructiveHint=false), the description discloses that omitted fingerprint fields are auto-generated as a coherent random fingerprint, explains proxy modes (static vs rotating), notes advanced field merging behavior, and states the return value (profile_uuid). This adds meaningful 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?

Four focused sentences, front-loaded with the primary action. Every sentence provides value: defaults, proxy binding, advanced overrides, and return value. 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?

Given the complexity (8 parameters, nested objects, no output schema), the description covers the required parameter, defaults, proxy modes, advanced overrides, and return value. It could mention what happens if proxy is omitted entirely, but the schema already handles that. Overall, it is sufficiently complete for a create tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds extra meaning by clarifying that `proxy` static refers to saved proxies from list_proxies and rotating is dynamic residential, and that `advanced` follows the FlashID Local API shape. This goes beyond the schema 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 'Create a browser profile,' making the verb and resource explicit. This clearly distinguishes it from sibling tools like update_profile, delete_profile, and get_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 explains key usage details ('Only `system` is required', 'Bind a proxy via `proxy`', 'Fine-grained fingerprint control goes in `advanced`') but does not explicitly contrast with alternatives or state when not to use. The usage context is implied rather than explicitly differentiated from update_profile.

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

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

The annotation `destructiveHint: true` already signals destructive behavior, but the description adds no further context. It does not disclose whether the deletion is reversible, whether it affects subfolders, or any permission requirements. Given the sibling 'permanently_delete', this ambiguity is significant.

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, concise sentence that is easy to parse and front-loads the primary action. While minimal, it is not wordy and effectively communicates the core purpose.

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 one parameter and no output schema, the description still leaves critical gaps. It does not explain the deletion behavior (soft vs. permanent), recovery options, or how it relates to sibling tools like 'restore_from_trash' and 'permanently_delete'. This is insufficient for a destructive tool.

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

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

The schema description coverage is 100% (the only parameter `folder_uuid` is described as 'Folder UUID'), so the schema already provides full parameter semantics. The description adds no additional meaning beyond that 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 'Delete a folder' clearly states the action and resource. However, it does not distinguish this from the sibling 'permanently_delete', which may be a more permanent deletion method. Thus it lacks clear 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?

There is no guidance on when to use this tool versus alternatives like 'permanently_delete' or 'restore_from_trash'. The description does not mention whether the folder is moved to trash, nor any prerequisites or consequences.

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, but the description adds valuable context that this is a soft delete (move to Trash) and that the profile can be recovered with restore_from_trash, exceeding the basic destructive flag.

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 front-load the action and recovery note. Every word earns its place with no unnecessary elaboration.

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

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

For a simple single-parameter destructive operation, the description effectively conveys the key behavior (soft delete) and the recovery path. No output schema exists, and annotations cover the safety profile, so the description is sufficiently 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?

The schema covers the only parameter profile_uuid with a basic description, so the baseline is 3. The description does not add any additional parameter meaning or usage details.

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 'Move' with the resource 'profile' and destination 'Trash', clearly distinguishing it from sibling tools like permanently_delete (permanent deletion) and restore_from_trash (the reverse operation).

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 context that the operation is recoverable via restore_from_trash, implying a non-permanent delete. However, it does not explicitly mention the sibling permanently_delete as the alternative for permanent deletion, so it lacks an explicit exclusion.

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 annotation already indicates destructiveHint=true, but the description adds a specific irreversible trait ('This cannot be undone'), which is more granular than the annotation. This provides useful behavioral context beyond what structured data offers.

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 exceptionally concise, consisting of two short sentences. It front-loads the action and purpose, with every word earning its place and zero 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 simple one-parameter delete tool with a destructive annotation, the description is largely complete. It states the action, the irreversibility, and the target. It could mention return values or impacts on running browsers, but these are not essential given the tool's simplicity.

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 input schema fully documents the sole parameter with 100% coverage, including its source ('from list_proxies'). The description adds no additional parameter meaning, so a 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 clearly states the action ('Delete') and the target resource ('a saved proxy'), distinguishing it from sibling tools like add_proxies, update_proxy, and list_proxies. It is specific and 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 no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or conditions. Usage is only implied by the delete verb, with no explicit context or exclusions.

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

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

Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds that values are 'coherent' and that it's for previewing, but does not disclose output structure or other behavioral details like whether required_types affects generation beyond the schema.

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

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

Two sentences, front-loaded with the main purpose, and every sentence adds value: the first states the action, the second gives usage context and alternative. No unnecessary words.

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

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

The tool is simple (read-only random generation) and the description covers purpose, usage, and alternative. However, without an output schema, the description could have explicitly described the return format, but it hints at 'preview values' and 'fill advanced manually', which is sufficient for an agent to understand the result. It lacks any mention of required_types, but that is a parameter semantics concern rather than overall completeness.

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 covers only 50% of parameters with descriptions (system_version and required_types have descriptions, system_os and gpu_adapterinfo_vendor do not). The description does not add any parameter-level meaning, only referencing 'an OS' broadly. It does not explain gpu_adapterinfo_vendor or how required_types works, so it fails to compensate for incomplete schema coverage.

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 'Generate a coherent set of random fingerprint values for an OS' with a specific verb and resource, and explicitly distinguishes it from create_profile by noting that create_profile auto-generates omitted fingerprint fields.

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 'Rarely needed' and names create_profile as the alternative that auto-generates these fields, and states it is 'Useful to preview values or fill advanced manually,' giving clear when-to-use 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 openWorldHint=false, so the description need not repeat safety. It adds the constraint that both 'system' and 'gpu_vendor' are required for type=webgl, but it does not describe the output format or error behavior, leaving some gaps.

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

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

The description is two sentences, front-loaded with the purpose, and every sentence adds value. The conditional note is concise and directly relevant.

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 strong annotations, the description provides the core purpose and the main constraint (webgl). It does not describe the return structure, but the simple 'list' nature implies an array of values. Overall it is fairly complete for the tool's complexity.

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 67% (system and gpu_vendor have descriptions). The description reinforces the webgl dependency that is already present in the schema, and it adds minimal meaning for 'type' by indicating it selects the fingerprint field. It adds little 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 uses the specific verb 'List' and clearly identifies the resource: 'selectable values for a fingerprint field'. It also distinguishes the tool from sibling 'generate_random_fingerprint' by noting its use for 'manual fingerprint configuration'.

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 context for when to use the tool ('for manual fingerprint configuration') and a specific conditional instruction for type=webgl. It does not explicitly name alternatives or exclusion cases, but the context is sufficient.

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 is consistent. It adds valuable behavioral context by disclosing that cookie_data is omitted by default due to size, and that include_cookie controls this. This goes beyond the safety annotation and explains a key output trait.

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

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

Two sentences, no waste. The first sentence front-loads the core purpose and key included elements; the second adds an important conditional detail. Perfectly sized.

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 2 parameters, no output schema, and read-only annotations, this description fully covers what the tool returns and the key conditional behavior. No missing context for an agent to use it correctly.

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

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

Schema description coverage is 100% with both parameters documented. The description enriches include_cookie by explaining why cookies are omitted (large size) and clarifies profile_uuid's role in fetching a profile's full config, providing rationale 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 'Get the full configuration of a profile' with specific resources (fingerprint, proxy, folder), distinguishing it from sibling tools like list_profiles and get_fingerprint_options. It also explicitly notes the cookie omission behavior, which adds clarity.

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 this tool is for retrieving full profile configuration, while list_profiles likely provides summaries. It does not explicitly state when to use alternatives, but the context of 'full configuration' and the cookie omission note gives clear 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?

Beyond the annotations (readOnlyHint=true), the description adds no behavioral context. It does not mention pagination, filtering behavior, or the response format, which is a significant omission for a list tool with optional 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?

The description is a single, clear sentence with no wasted words. It is appropriately sized for a simple list operation, and the structure is front-loaded with the core purpose.

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

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

Given the tool has three optional parameters and no output schema, the description is too sparse to be complete. It does not explain pagination, keyword filtering, or what the response contains, leaving the agent to infer critical 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?

The description provides no information about the parameters. Since schema coverage is only 67% (keyword lacks a description), the description does not compensate for the gap, leaving the agent without guidance on the keyword parameter's meaning or usage.

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 'List profile folders' uses a clear verb and resource, distinguishing it from sibling tools like list_profiles or list_trash. However, it is extremely terse and provides no additional context about the scope or nature of the listing.

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 no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites, exclusions, or related tools. This is a clear gap in 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 safety profile is covered. The description adds useful behavioral context beyond the annotations by noting that running state is omitted and that pagination/search are supported. However, it doesn't describe the response envelope or any rate limiting, which would be additional value.

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 core purpose and a key differentiator. No wasted words; every phrase 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 list operation with no output schema, the description clearly states the resource, the filtering/search capabilities, and the important exclusion of running state. It could have mentioned the structure of the paginated response (e.g., whether it returns a total count), but the core behavior is adequately covered given the annotations.

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 67%, with page, keyword, page_size, and folder_uuid already described in the schema. The description adds the context of pagination and search but does not clarify the meaning of sort_by or sort_order, which lack schema descriptions. Since the description doesn't compensate for the undocumented parameters, it only meets the 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 clearly states it lists browser profiles with pagination and search, immediately distinguishing it from list_running_browsers by explicitly noting running state is excluded. The verb 'list' and resource 'browser profiles' are specific and 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 explicitly tells the agent when not to use this tool: 'running state is not part of this list — use list_running_browsers for that.' This names the alternative tool directly and provides clear exclusion criteria, making usage guidance strong.

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 description doesn't need to repeat safety. It adds value by noting the returned proxy_uuid is intended for binding, which gives insight into the output structure. No contradictory behavior is disclosed.

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

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

Two sentences with no unnecessary words. The first sentence states the action, and the second gives a practical follow-up. Well-structured and 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?

This is a simple read-only list tool with schema and annotations covering most context. The description implies the response contains proxy_uuid, which is enough to complete the binding workflow. It could be slightly more explicit about the response format, but given the simplicity, it is sufficiently complete.

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

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

Schema coverage is 75%, which is moderate. The description doesn't delve into parameter meanings but the schema already documents most properties (tab, page, page_size). The keyword parameter lacks a schema description, yet the description doesn't compensate. The main focus is on output usage rather than input parameters, so a 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 clearly states 'List saved proxies' with a specific verb and resource, and distinguishes itself from sibling proxy tools (add_proxies, delete_proxy, check_proxy, list_proxy_regions). It also provides a concrete next step (using proxy_uuid for binding), which clarifies the tool's role in the workflow.

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

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

The description explicitly says to use the returned proxy_uuid to bind a proxy to a profile via create_profile or quick_update_profile, giving a clear context for when this tool is useful. It does not mention exclusions or alternatives, but the primary use case is well articulated.

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 readOnlyHint=true, so the safety profile is clear. The description adds meaningful behavioral detail: without arguments it returns country codes/names, and with `country` it returns the state/city subtree. It also clarifies the distinction between `code` (for region) and `value` (for state/city), which is helpful for callers.

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, with the first sentence stating the core functionality and the second providing usage guidance. It is front-loaded, contains no fluff, and every sentence contributes 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 list tool with one optional parameter and no output schema, the description fully explains the behavior in both argument scenarios, the structure of output data, and how to apply the results in profile creation/update. This is complete for its complexity, and the presence of annotations further reduces the need for 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?

The schema already provides 100% coverage for the single `country` parameter, describing its type and effect. The description adds integration-oriented semantics by explaining how to use the returned fields in other tools, which goes beyond the schema's basic parameter description and enriches understanding of the parameter's role.

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 tool's purpose: returning proxy regions for rotating residential proxies. It specifies the exact output types (countries, states/cities) and how the optional `country` parameter changes the results, making it distinct from sibling tools like list_proxies.

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

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

Explicitly explains when to use the tool: when configuring proxies in create_profile or quick_update_profile, and how to map the returned `code` and `value` fields to proxy.region, proxy.state, and proxy.city. This gives concrete, actionable usage context beyond just listing regions.

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 nature is known. The description adds the specific output fields (ws.puppeteer, ws.selenium, debug_port), which is useful context that goes beyond the raw annotation. It does not promise additional behavior, and there is no 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?

The description is a single, well-structured sentence that is front-loaded with the action ('List currently running browsers') and immediately provides the key output details. No filler words; every part 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 no-parameter, read-only list tool with no output schema, this description is fully sufficient. It states what is listed and the important fields returned. There are no hidden parameters, side effects, or complex preconditions, so no additional context is needed.

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 schema coverage is 100% and there is nothing to document. The description does not need to explain parameter syntax, and the baseline of 4 applies since no parameters 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 states the tool's function: 'List currently running browsers' and specifies exactly what information is returned (automation endpoints ws.puppeteer / ws.selenium / debug_port). It uses a specific verb and resource, and is distinct from sibling tools like list_profiles or open_browser.

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 clear context for when to use this tool: when you need to see which browsers are currently running and their automation endpoints. It does not explicitly name alternatives or exclusions, but the purpose is unambiguous enough to guide selection. Sibling tools like list_profiles serve a different function, implying this is the go-to for running browser instances.

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 safety is known. The description adds the trash scope but does not disclose pagination behavior or return format. No 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?

The description is a single clear sentence with no redundant words. It front-loads the action and subject effectively.

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, but with optional pagination and keyword filtering parameters and no output schema, the description does not fully clarify how these parameters affect results or what the response structure is. It is 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?

The schema descriptions cover page and page_size, but keyword has no description. The tool description adds no parameter semantics, leaving the purpose of keyword ambiguous. Schema coverage is 67%, not high enough to fully compensate.

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 'List profiles currently in the trash (recycle bin)' clearly states the action (list) and the resource (trash profiles). It distinguishes from sibling tool list_profiles by explicitly scoping to 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 description implies this tool is for viewing trashed profiles but does not explicitly state when to use it versus list_profiles or other trash-related tools like restore_from_trash. Usage context is implied by the phrase 'in the trash'.

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 openWorldHint=false and destructiveHint=false, but the description adds behavioral details beyond that: it waits until ready, returns specific endpoint formats, and notes the possibility of a long first launch due to kernel download. This goes beyond the structured data.

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

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

The description is three sentences long, front-loads the core action, and each sentence contributes essential information: the action, the return endpoints, and timing behavior. There is no redundant or wasteful text.

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

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

The tool has no output schema, but the description explicitly details the return values (ws.puppeteer, ws.selenium, debug_port) and the wait behavior. It gives an agent everything needed to invoke the tool and understand what to expect, especially given the single parameter and available annotations.

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 a full description for the single parameter (profile_uuid: 'Profile UUID to open'), giving 100% schema coverage. The tool description does not add further parameter-specific semantics, 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 begins with 'Launch the browser for a profile and wait until it is ready,' a specific verb+resource statement that clearly distinguishes this from sibling tools like close_browser or list_running_browsers. The mention of returned automation endpoints further nails down the tool's role.

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 context about when the tool is used (to launch a browser and get automation endpoints) and includes practical timing information (first launch may take minutes). It does not, however, explicitly state alternatives or exclusions, so it misses the top bar for explicit when/when-not guidance.

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

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

Annotations already set destructiveHint=true, but the description adds crucial context: 'This cannot be undone' and 'Only affects profiles already in trash'. This goes beyond the annotation by warning of irreversibility and preventing misuse outside the trash scope, providing robust behavioral transparency.

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 sentence front-loads the action and scope, and the second adds irreversibility and a scope constraint. Every word 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 tool with only two optional parameters and no output schema, the description covers all essential aspects: purpose, modes, irreversibility, and scope. A minor gap is the lack of explicit behavior when both all=true and profile_uuids are provided, but the implied exclusivity mitigates this.

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 baseline is 3. The description adds semantic value by explaining the two modes (specific via profile_uuids, bulk via all=true) and implying they are alternatives, which the schema does not enforce. This clarifies the relationship between the two parameters beyond their raw 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 starts with an emphatic 'PERMANENTLY delete profiles from trash', which clearly states the action, resource, and scope. It also distinguishes from sibling tools like delete_profile (which likely moves to trash) and restore_from_trash by emphasizing irreversibility and the trash-only scope.

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

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

The description implies when to use this tool: when you want to permanently erase profiles already in trash, as opposed to initial deletion or restoration. It provides clear prerequisites ('Only affects profiles already in trash') and two usage modes, but does not explicitly name alternatives or exclusions beyond that.

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 are minimal (openWorldHint=false, destructiveHint=false). The description adds behavioral context beyond annotations: it explains partial update semantics ('Send only the fields to change') and the special root-folder behavior ('folder_uuid 0 moves the profile out of its folder'). This is helpful and not covered by 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?

The description is two sentences, with the first sentence announcing the purpose and scope, and the second providing a key usage instruction and special value. Every word earns its place; 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 tool with 5 params, a nested proxy object, and no output schema, the description covers the essential purpose, usage, and a special case. It does not mention what happens after update (e.g., response shape) or explicitly point to update_profile for fingerprint changes, but the 'non-fingerprint' wording implicitly covers that. A short pointer to the full update tool would make it more complete, but it is sufficient 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 60%, with descriptions for folder_uuid, proxy, and profile_uuid. The description compounds this by clarifying that only fields to be changed need to be sent, and by listing the editable fields. It also reiterates the folder_uuid special value. This adds meaning beyond the schema alone, especially the partial-update semantics.

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 'Lightweight partial update of non-fingerprint info: name, note, folder and/or proxy.' It uses a specific verb ('update') with a clear scope (non-fingerprint fields) and lists the fields. This distinguishes it from the sibling 'update_profile' by limiting to non-fingerprint fields.

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 context: use this for partial updates, sending only the fields to change. It implies 'when not to use' by restricting to non-fingerprint info, but it does not explicitly name the alternative tool (update_profile) or provide explicit exclusions. This is clear context but lacks explicit alternatives.

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

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

The description discloses the core behavior (restore) and the two invocation modes, but it does not address edge cases like providing both profile_uuids and all=true simultaneously, or what happens if the specified profiles are not in trash. The annotations are minimal, so the description carries some burden but fails to cover these behavioral nuances.

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 sentence, front-loaded with the action, and efficiently conveys both invocation modes without any fluff 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 tool with only two optional parameters and no output schema, the description covers the essential purpose and modes. However, it misses the potential conflict when both parameters are supplied and does not hint at any error conditions or prerequisites, leaving a small gap in completeness.

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 rephrases the parameter meanings ('specific ones via profile_uuids' and 'everything via all=true') but does not add new semantics such as exclusivity or format constraints 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 clearly states the action (restore) and resource (profiles from trash), and differentiates it from sibling tools like permanently_delete and list_trash by specifying the two modes of operation (specific UUIDs or all).

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 context for when to use the tool (to restore profiles from trash) and outlines the choice between specific and bulk restore. However, it does not explicitly mention alternatives or exclusions, such as using list_trash to inspect trash first or avoiding this tool for permanent deletion.

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 discloses that the tool modifies the star flag (a state change) and explicitly states the return value ('Returns the new stars_status'), which goes beyond the annotations that only provide openWorldHint=false and destructiveHint=false. This is useful 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 description is a single, concise sentence that front-loads the action and result. There is no filler or redundant information, making it highly 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 simple tool with one parameter and no output schema, the description adequately covers the core behavior, the return value, and the star status meaning. No critical information is missing for an agent to use it correctly.

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

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

The input schema already fully describes the single parameter (profile_uuid) with high coverage (100%). The tool description does not add additional semantics beyond what the schema provides, so a 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 clearly states the action ('Toggle the star flag') and the resource ('profile'), with the additional detail of returning the new stars_status. This distinguishes it from sibling tools like update_profile or quick_update_profile, which handle general profile updates.

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 usage context is implied by the name and description: use this tool when you want to star/unstar a profile. However, there is no explicit guidance on when to prefer this over alternative update methods, nor any mention of 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?

The description adds no behavioral context beyond the annotations. Annotations already declare idempotentHint=true and destructiveHint=false, but the description does not provide any additional side effects, error conditions, or practical caveats. It merely restates the action.

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, concise sentence that directly states the action. Every word earns its place, with no redundant fluff. It is appropriately sized for a simple tool.

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

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

Given the tool's simplicity (2 params, 100% schema coverage, no output schema) and existing annotations, the description is sufficient for an agent to understand its purpose and invoke it correctly. The context is minimal but complete for a straightforward rename operation.

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

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

Schema coverage is 100% with both parameters (name and folder_uuid) having descriptions. The tool description adds no extra parameter information, so the baseline of 3 applies as 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 'Rename a folder.' uses a specific verb ('Rename') and resource ('folder'), clearly distinguishing it from sibling tools like create_folder and delete_folder. It unambiguously states the tool's core 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?

The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. While the name implies usage for renaming folders, there is no explicit context or comparison with sibling 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 indicate non-destructive and non-open-world, so the bar is lower. The description adds valuable partial-update semantics (omitted fields keep current value), which is critical behavioral context beyond annotations. No 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?

Extremely concise: two sentences, front-loaded with key behavior and a pointer to a simpler sibling. Every word earns its place with no 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?

The description explains the update semantics, references quick_update_profile, and points to external docs for advanced overrides. Given the rich schema and annotations, it is sufficiently complete, though it doesn't describe the response format.

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 it carries the parameter documentation burden. The description adds the partial-update behavior and references the advanced field structure, but does not add much beyond the schema's own 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?

Clearly states it is a partial update of a profile and lists examples of fields, distinguishing it from the sibling quick_update_profile. The verb 'update' and resource 'profile' are specific and 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?

Explicitly instructs to prefer quick_update_profile for simple field changes (name/note/folder/proxy), implying this tool is for more complex or comprehensive updates. This provides clear when-to-use vs alternative 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 discloses the partial-update behavior, which is key context. Annotations already indicate non-destructive behavior (destructiveHint=false) and a closed schema (openWorldHint=false). However, it does not mention potential side effects, error handling, or requirements beyond the schema, so transparency is moderate.

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, concise sentence with no redundant wording. It front-loads the core action and the critical usage detail, making it highly efficient and easy to parse.

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

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

The description covers the essential purpose and partial-update semantics, and annotations provide safety information. However, with no output schema and no mention of return values or error scenarios, it is slightly under-specified for a tool with 9 parameters, though adequate for a straightforward update 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?

With schema description coverage at only 22%, the description helps by clarifying that only provided fields are updated and the rest remain unchanged. It does not explain individual parameter meanings, but field names are largely self-explanatory, and the partial-update note adds value beyond the schema.

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

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

The description clearly states the action ('partial update') and the resource ('saved proxy'), and the scope ('send only the fields to change') differentiates it from full replacement or deletion. It is unambiguous and distinct from sibling proxy tools like delete_proxy or add_proxies.

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 'send only the fields to change' provides clear guidance that the tool is used for modifying an existing proxy without sending the entire object. It implies usage for updates to a saved proxy, though it does not explicitly state alternatives or exclusions, making it clear but slightly incomplete.

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