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

The description details behavioral traits: uses browser's cookies and TLS fingerprint, bypasses auth and fingerprinting, and notes that body is auto-encoded for dict/list. Annotations only include openWorldHint=true, so the description carries the burden. It does not mention rate limits or potential side effects, but covers key aspects adequately.

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 concise and well-structured: a one-paragraph overview followed by an Args list and Returns line. No wasted words, front-loaded with purpose, and 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?

Given 6 parameters, 2 required, and an output schema present, the description is complete. It explains all parameters, the return format (status, status_text, headers, body, url), and context for using the session. The output schema likely provides further detail, so description need not elaborate.

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 compensates fully. It explains each parameter: method lists, url, headers, body (auto-encoding for dict/list, as-is for string), use_session (purpose), and timeout_ms (default). This adds significant meaning beyond the bare 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 purpose: 'Make an HTTP request using the active account's browser session.' It distinguishes itself from sibling tools like gv_open_url (navigation) and gv_eval_js (JavaScript execution) by specifying that it uses cookies and TLS fingerprint, and is faster for API data retrieval.

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 when to use the tool: when you need API data using the browser's session, bypassing cookie-based auth and TLS fingerprinting. It compares to navigating a page and highlights the speed advantage. It also allows turning off session via use_session. However, it could be more explicit about when not to use or list 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 indicate readOnlyHint=true, and the description does not contradict. It adds behavioral context by describing the two-layer check (cookie expiry + probe URL redirect) and the return fields, which is helpful beyond 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 around 10 sentences with clear sections for return values and args. Each sentence adds value without excessive verbosity. Could be slightly more concise, but structure is good.

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 presence of an output schema (not shown but indicated), the description covers return fields and provides necessary context for using the tool. It adequately addresses the complexity of a session health check.

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 optional parameter account_id is explained in the description: 'The account id to check. Omit to check the active account.' This adds meaning beyond the schema default of null and clarifies behavior.

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

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

The description clearly states the tool checks if the browser session is authenticated, with a specific verb and resource. However, it does not differentiate from the sibling tool 'gv_get_session_status', which may have similar functionality, preventing a higher score.

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 the browser context must be open (calling gv_open_account first) for an accurate check, and mentions behavior when closed. It also explains when to omit account_id. No explicit when-not-to-use, but clear guidance is provided.

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?

Discloses text matching (case-insensitive, substring), fallback to CSS selector, post-click wait for page settle, and humanize override behavior. Does not contradict annotations (openWorldHint). Minor omission: whether it scrolls element into view.

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?

Well-organized with sections, front-loaded purpose. The decision guide is valuable but adds length; no redundant sentences. Could be slightly tighter.

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?

Covers main workflow and parameters, and mentions output (target, humanize applied, page preview). Missing error handling details (e.g., element not found, timeout). Adequate for typical usage but not exhaustive.

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

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

Despite 0% schema coverage, the description fully explains all four parameters: target (visible text vs CSS), timeout_ms (default), humanize (boolean, default null, with actionable guidance), and delay_after_ms (randomized range).

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 clicks an element on the current page via visible text or CSS selector. It is unambiguous but does not explicitly differentiate from sibling tools like gv_fill_input or gv_scroll.

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

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

Provides a detailed decision guide for when to set humanize=true, covering login buttons, captchas, form submits, and trusted sites. However, lacks general guidance on when to choose this tool over 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?

Discloses key behavior: preserves persistent profile on disk so reopening reuses login. No annotations provided, so description carries full burden; it effectively communicates the non-destructive nature and resource impact.

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?

Highly concise: three brief sentences plus a simple arg description. The first sentence immediately states the core purpose, and no redundant 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 simple tool with one parameter and an output schema, the description covers the essential behavioral details (closing, session preservation, reuse). No gaps 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 only parameter, account_id, is described as 'The account id to close', which adds minimal value beyond the parameter name. Schema coverage is 0%, so the description should provide more detail (e.g., format, how to obtain 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?

Clearly states it closes the browser context for an account while preserving session. Differentiates from sibling tools like gv_delete_account (destructive) and gv_logout (session end) by specifying that the session is saved.

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

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

Explicitly says 'Use this to free resources when done with an account', providing clear when-to-use guidance. Lacks explicit when-not-to-use or alternative suggestions, 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 indicate destructiveHint=true; the description adds context about what gets destroyed (tempdir, browser process) and the fallback behavior for the active slot. This goes beyond 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 concise with a one-line summary followed by necessary details. Every sentence adds value, 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?

Given the tool's simplicity (one optional parameter), the description covers usage, behavior, and output (closed id and new active target). An output schema exists but the description complements it.

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

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

Schema coverage is 0%, but the description explains that session_id comes from gv_open_ephemeral and that omitting it closes the active session. This adds essential meaning 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 'Close an ephemeral session' with specific verb and resource. It distinguishes from sibling tools like gv_check_session and gv_get_session_status by focusing on closure.

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 when to use the tool (close ephemeral session) and provides guidance on omitting session_id to close the active one. It mentions fallback behavior but does not explicitly contrast with 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 that the tool generates a fresh pinned fingerprint and persistent profile but does not sign in, which is consistent with its purpose. Annotations include destructiveHint: true, but creating an account slot is not inherently destructive; the description does not contradict annotations, but it adds useful context about the creation process and return values.

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

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

The description is well-structured with a header, summary paragraph, and detailed argument list. However, it is verbose with lengthy parameter explanations that could be trimmed slightly without losing clarity. Still, it is efficiently written for the complexity involved.

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 17 parameters, no schema descriptions, and an output schema (though not detailed here), the description covers all parameters comprehensively and mentions return values (account id, resolved config, warnings). It is fully complete for an AI agent to understand and invoke the tool correctly.

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

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

With 0% schema description coverage, the description compensates fully by explaining every parameter's purpose, defaults, and allowed values (e.g., 'os: Defaults to server config', 'humanize: True (default in balanced) | False | float'). This adds significant value beyond the bare 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 'Create a new managed account slot with a locked fingerprint + advanced config' and distinguishes it from sibling tools like gv_sign_in by explicitly noting the account is not signed in yet. This makes the primary purpose and its specific role clear.

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

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

The description explicitly guides the user to call gv_sign_in next, indicating a sequential workflow. However, it does not explicitly mention when not to use this tool (e.g., if an account already exists or for other scenarios), missing some exclusionary 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 indicate 'destructiveHint: true', and description does not contradict. Adds context about persistent storage in ~/.ghostvault/providers.json and sharing across accounts, but lacks details on potential conflicts or error conditions.

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?

Description is well-structured with clear front-loaded purpose and organized Args section. Code snippets are helpful; slightly verbose but each sentence adds 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?

Given 9 parameters and 5 required, description covers all parameters and explains their roles. References output schema exists, so return values not needed. Mentions storage and usage across accounts, making it complete.

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

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

Schema description coverage is 0%, but the description provides detailed parameter explanations, including optional ones with defaults, adding critical meaning beyond the schema structure.

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

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

Specific verb 'Create' and resource 'custom login provider recipe'. Distinguishes from siblings like gv_delete_provider and gv_get_provider by stating it's for creation. Includes important constraint 'Cannot shadow built-ins.'

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

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

Explicitly states how to use the created provider with gv_create_account and gv_sign_in, providing context. Mentions storage location but does not explicitly state when not to use this tool versus 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?

Beyond the destructiveHint annotation, description details exactly what is removed (profile directory, encrypted archive, fingerprint file, DB row) and prerequisite (account must not be running). 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?

Every sentence adds unique value: deletion scope, what is removed, prerequisite, related sign-out note. 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?

Covers all necessary aspects for a destructive tool: effects, prerequisites, and related operations. Output schema exists so return values are not required in description.

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

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

Schema has 0% description coverage for the single parameter. Description adds 'The account id to delete' but lacks format or constraints. Minimal but adequate for a single string parameter.

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?

Title and description clearly state deletion of account and all its data. Distinguishes from sibling tools like gv_close_account, gv_lock_account, gv_create_account by specifying irreversible removal.

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

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

Explicitly states when NOT to use: 'Cannot delete a running account — lock/close it first.' Also directs to use gv_sign_out if session invalidation is needed, providing clear 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?

Annotation destructiveHint=true already signals destruction. Description adds that it deletes custom providers and that built-in cannot be deleted, providing useful context 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?

Extremely concise: two sentences and an Args section. No wasted words; every sentence adds 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?

Covers main action and key constraint (built-in providers not deletable). With an output schema present, return values are likely covered. Adequate for a simple delete 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?

Only parameter 'name' has no schema description. Description provides meaning: 'The provider name to delete.' This adds value beyond the schema's title alone.

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?

Clear verb 'delete' and resource 'custom provider' with distinction from built-in providers. Distinct from sibling tools like gv_create_provider and gv_update_provider.

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?

States when NOT to use (for built-in providers cannot be deleted). Implicitly suggests use for custom providers only. Does not explicitly name alternatives but context is clear.

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

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

Annotations declare readOnlyHint=true, and the description adds that the tool only scans and returns a recommendation, with no side effects. It also notes that the session is saved automatically, providing useful behavioral context beyond 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 well-structured with clear sections and front-loaded key info. It is somewhat lengthy but every sentence adds value; no redundancy. Could be slightly trimmed without losing clarity.

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 an output schema (implied), the description covers all necessary aspects: purpose, usage decision guide, parameter semantics, and behavioral notes. It is fully self-contained and actionable.

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

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

Despite 0% schema description coverage, the description fully explains the single parameter 'url': it is optional, navigates to that URL first, or scans the current page if omitted. This adds clear meaning 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 it scans the page for login options and returns a recommendation. It uses specific verbs ('Scan', 'Detects', 'Returns') and distinguishes from sibling gv_sign_in by stating usage before that tool.

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

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

Explicitly says 'Use this BEFORE gv_sign_in when you're not sure what the page offers' and provides a complete decision guide mapping recommendations to actions, including alternatives like asking the user.

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 mentions executing JavaScript in the page, implying side effects, but does not elaborate on potential risks (e.g., page modifications, error handling, async behavior). With 'openWorldHint: true' in annotations, the description adds modest context but could be more forthcoming about behavioral traits.

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 concise and well-structured: a one-line summary followed by bulleted use cases and clear parameter explanations. Every sentence adds value without 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?

Given the complexity of executing arbitrary JavaScript, the description covers the main functionality, argument usage, and return value. It does not discuss error handling or security implications, but the presence of an output schema (not shown) reduces the need for return value details. Slightly more completeness would be ideal.

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

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

Despite 0% schema description coverage, the description adds critical meaning: 'script' is defined as a 'JS expression or arrow function' and 'arg' as an 'Optional argument to pass to a function script.' This fully compensates for the lack of 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 clearly states 'Run JavaScript in the active page and return the result' with specific, concrete use cases (e.g., extracting CSRF tokens, reading localStorage). This uniquely identifies the tool and distinguishes it from sibling tools like gv_get_page_content or gv_fill_input.

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 explicit use cases and examples, guiding when to use the tool (e.g., extracting values, calling site functions). However, it does not explicitly state when not to use it or offer alternatives, which would improve clarity for the agent.

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

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

The description extensively discloses behavioral traits: instant paste vs humanize typing, account policy overrides, return values, and detectability. Annotations only provide openWorldHint, so the description carries the full burden and meets it excellently.

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 well-structured with sections for arguments, decision guide, and notes. It is somewhat lengthy but every section adds value. The front-loaded purpose and organized layout aid scanning.

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

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

Given the complexity (8 parameters, output schema exists), the description is complete. It covers all parameter semantics, usage context, behavioral details, and return values. No gaps are evident.

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 0% schema description coverage, the description fully explains all 8 parameters, including defaults, recommended values by scenario, and the effect of account-level settings. This adds significant meaning beyond the bare 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 'Fill a form input on the current page' with a specific verb and resource. It distinguishes itself from siblings like gv_click_element and gv_open_url by focusing on input field filling.

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?

While the description does not explicitly compare to alternatives, it provides clear context on how the tool finds inputs (label text then CSS selector) and includes a Decision Guide for when to set humanize=true. The implied use case is sufficiently clear for agents.

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, indicating a safe read operation. The description adds detailed behavioral context: it returns three specific fields (gate_enabled, unlocked, message) and describes the special case when no password is set ('gate is off and all profiles are public'). This goes beyond annotations and fully informs the agent.

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, both front-loaded. The first sentence states the purpose, the second specifies return values and edge case. Every sentence adds value without waste.

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

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

Given the tool's simplicity (0 parameters, no complex logic), the description fully covers what the agent needs: purpose, return type, and behavior in the default and edge cases. Annotations and output schema exist, so no further detail is necessary.

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

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

There are no parameters, so the input schema is trivially covered (100%). The description does not need to add parameter details. Baseline for 0 parameters is 4, and the description meets that without any redundant or missing info.

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 purpose: checking the status of a password gate ('active and unlocked'). It uses a specific verb ('Check') and resource, and the title 'Get Auth Status' reinforces this. Among 39 sibling tools, none overlap directly, so no confusion.

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 the tool (to check auth gate status), but does not provide explicit guidance on when not to use it or mention alternatives among siblings (e.g., gv_unlock, gv_setup_password). Context is clear but lacks 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 annotation readOnlyHint=true indicates a safe read operation. The description adds behavioral context: 'Cookie values longer than 20 chars are masked for security', which is beyond what annotations provide. Also specifies scope ('from the active browser context'). 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?

The description is short and front-loaded with the purpose. It uses a structured 'Args' section for parameter details. Every sentence adds value, with 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 description covers purpose, usage scenario, a key behavioral trait (masking), and parameter semantics. An output schema exists (not shown), so return values need not be detailed. For a simple read tool with two states (with or without domain), this 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 input schema has one optional parameter 'domain' with 0% description coverage. The description clearly explains its effect: 'If set, only cookies matching this domain are returned. If omitted, all cookies are returned.' This adds meaningful guidance 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 'Read cookies from the active browser context', which is a specific verb ('Read') and resource ('cookies from the active browser context'). It distinguishes from sibling tools like gv_get_page_content (content) and gv_check_session (session/auth status).

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

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

The description suggests using the tool 'for debugging sessions or understanding what the site has set', providing clear context. While it does not explicitly exclude alternatives, the sibling list shows no other cookie-reading tool, making the guidance adequate.

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 description adds value by specifying that values are masked. This goes beyond the annotation and provides behavioral insight. However, no other side effects or limitations are disclosed.

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

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

The description is extremely concise with only two sentences and a parameter line. It front-loads the purpose and avoids unnecessary words. Every sentence provides 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?

Given the tool's simplicity (one required parameter, read-only, with output schema), the description covers the essential behavioral aspect (masking). It does not explain the return format but that is expected from the output schema. Slightly incomplete due to lack of parameter detail but sufficient for minimal 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 description restates the parameter name 'account_id' with 'The account id.', adding no additional meaning beyond the schema. Since schema coverage is 0%, the description fails to compensate with details like format or examples.

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 'Show which credential keys are stored for an account (values are masked)', providing a specific verb (show) and resource (credential keys) with an important detail about masking. This distinguishes it from sibling tools like gv_set_credentials or gv_delete_account.

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 usage when needing to see stored credential keys, but lacks explicit guidance on when not to use it or alternatives. No prerequisites or exclusions are mentioned, which is acceptable for a simple read tool but not actively helpful.

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 value beyond the readOnlyHint annotation by detailing the content of log entries (timestamp, account, action, status, duration, error info). It is consistent with the annotation and does not contradict.

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 concise, front-loaded with the purpose, and includes only necessary details. Every sentence contributes to understanding.

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

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

For a simple read tool with one parameter and an output schema, the description is complete. It clearly explains what the tool returns and when to use it.

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

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

The description documents the single parameter 'n' with default and max (500), which the schema does not fully cover (only default). This compensates for the 0% schema description 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 'Return the most recent debug log entries (for troubleshooting)', specifying the verb and resource. The sibling tools are all distinct actions, so this tool is uniquely identified.

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 'Use this when something isn't working and you need to see what happened', providing clear guidance on when to use. It does not mention alternatives or when not to use, 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 mark readOnlyHint=true, so description doesn't need to emphasize safety. It adds context about screenshot benefits but does not cover potential limitations like page load timing or character limits beyond the default.

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: three short sentences plus parameter docs. Front-loaded with core purpose, then usage note, then parameter details. No fluff.

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

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

Covers all critical aspects: what it reads, optional image, usage guidance, and parameter meanings. Lacks output format description, but given no output schema and simple read operation, it is reasonably 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 has 0% coverage, but description compensates by explaining include_screenshot's purpose and specifying max_chars as max characters. This adds meaningful guidance beyond the schema's type and default.

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 verb 'Read' and the resource 'current page's text content', with an optional screenshot. It distinguishes itself from sibling tools like gv_screenshot and gv_get_page_links by specifying the exact 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?

Provides explicit guidance on when to set include_screenshot=true (captcha, image buttons, complex visual structure). However, it does not directly contrast with alternatives like gv_screenshot for standalone image capture, missing a clear 'when not to use'.

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 with this. It adds value by specifying the return format and the limit parameter's behavior, though it does not elaborate on other behavioral traits like whether it scrolls or handles dynamic content.

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 very concise: three short sentences that cover purpose, output format, and parameter details. Every sentence is necessary and well-placed.

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 low complexity and the presence of an output schema, the description is complete. It explains what the tool does, its return format, and the only parameter. No obvious gaps.

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

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

The input schema has 0% description coverage (no descriptions for parameters), so the description must compensate. It clearly explains the 'limit' parameter: 'Max number of links to return (default 50, max 100).' This adds essential semantic meaning beyond the schema's type and default.

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 'List the visible links on the current page,' using a specific verb and resource. It further clarifies the purpose by saying 'Use this to choose where to navigate next,' which distinguishes it from sibling tools like gv_click_element and gv_open_url.

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

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

The description provides a clear context for when to use the tool ('choose where to navigate next') but does not explicitly state when not to use it or mention alternatives. This is still helpful for an AI agent.

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

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

Annotations already mark readOnlyHint true; description adds that it returns full configuration with examples (login URL, cookies), providing context 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?

Very concise, front-loaded with the action, and includes a structured Args section with 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?

Given there is an output schema (unseen), the description adequately describes the return value (full configuration) and examples, but could mention it returns only one provider's details.

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 lacks descriptions (0% coverage), but the description's 'Args:' section explains the single 'name' parameter effectively, adding meaning over the schema alone.

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 shows one provider's full configuration, including login URL and cookies, distinguishing it from listing tools like gv_list_providers.

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 is clear that this tool is for retrieving details of a specific provider by name, but it does not explicitly say when not to use it (e.g., for listing all providers).

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?

ReadOnlyHint annotation already indicates safe read. Description adds return field list (id, name, email, etc.), which is useful but not behavioral beyond what annotations imply.

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

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

Three sentences covering purpose, parameter behavior, and return fields. No extraneous information, front-loaded with main action.

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?

Includes return field list, which covers output expectations. With output schema available, it is mostly complete. Could mention error cases or what happens if session doesn't exist, but not critical.

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

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

Schema coverage is 0%, so description must compensate. It explains that omitting account_id checks the active account, adding meaning. However, it doesn't describe the format or constraints of account_id, leaving it partially ambiguous.

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

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

States 'Check whether an account's browser session is running and authenticated', which is a clear verb+resource. However, sibling tool 'gv_check_session' exists and is not differentiated, so purpose is clear but not distinguished.

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

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

No guidance on when to use this tool vs alternatives like 'gv_check_session'. The hint about account_id omission is helpful but does not provide usage 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 and idempotentHint=true, so the safety profile is clear. The description adds valuable behavioral details beyond annotations: it lists the exact fields returned (id, label, email, status, browser context running, active account id), which helps the agent understand the output without needing to inspect the output schema.

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

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

The description is extremely concise: three sentences covering purpose, output details, and usage hint. Every sentence adds value, and there is no fluff or repetition.

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

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

Given the tool's simplicity (no parameters, safe read operation), the description is complete. It explains what the tool does, what it returns, and provides a key usage hint. The presence of an output schema does not reduce the need for the description, and the description complements it well.

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 the description does not need to provide parameter semantics. With 0 parameters and 100% schema coverage, the baseline is 4, and the description adds no redundant information.

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 specific verbs (List, discover) and resources (managed accounts, active account). It clearly states the tool's output (id, label, email, status, etc.) and distinguishes itself from sibling tools like gv_create_account or gv_delete_account.

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 'Use this first to discover account ids before calling other tools,' which provides clear when-to-use guidance. It does not explicitly mention when not to use, but given the simplicity of the tool and lack of direct alternatives among siblings, this 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 mark the tool as readOnly and idempotent. The description adds value by detailing the returned fields (name, max_login_level, etc.) and listing built-in providers, providing behavioral context beyond the annotations.

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

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

The description is concise with two sentences plus a short list. It front-loads the main action and returns fields. No unnecessary words, though the list format could be slightly more 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?

Given no parameters, strong annotations (readOnly, idempotent), and presence of an output schema, the description is fully complete. It explains what is returned and gives examples, leaving no gaps for effective use.

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 (0 params, 100% schema coverage). Per guidelines, baseline score for 0 parameters is 4. The description appropriately focuses on output rather 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?

Clearly states it lists all providers (built-in and custom) with capability flags, and distinguishes from sibling tools like gv_get_provider (single provider) and gv_create_provider. The specific verb 'list' and resource 'providers' are explicit.

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

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

The description does not explicitly state when to use this tool versus alternatives like gv_get_provider. Usage context is implied by the name 'list all', but no explicit when-to-use or when-not-to-use guidance is provided.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the saved session is kept and that reopening works without re-login, and notes it is the manual version of auto-lock. However, it does not mention any side effects (e.g., impact on tabs, ongoing processes) or rate limits, leaving gaps in comprehensive 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 concise and front-loaded with the core action. The 'Args:' section is somewhat redundant given the single parameter, but overall it is well-structured and 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?

Given the tool has only one required parameter and no enums, the description adequately covers purpose and usage. However, since an output schema is present, the description could mention what the tool returns to ensure full 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 description simply repeats 'The account id to lock' for the single parameter account_id, which adds minimal value beyond the schema's title 'Account Id'. With 0% schema description coverage, the description should provide more context about acceptable values or format but does not.

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

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

The description clearly states 'Lock an account — close the browser and re-encrypt its profile.' It uses a specific verb and resource, and distinguishes from siblings like gv_close_account and gv_unlock by explaining that the session is preserved for later reopening without re-login.

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 'Use it when you're done with an account for now but want to come back to it later without re-authenticating.' This provides clear context for when to use the tool. However, it does not mention when not to use it or explicitly compare with alternatives like gv_logout or gv_close_account.

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

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

With no annotations, the description fully discloses behavior: closing private contexts, switching to a public profile, and explicitly stating it does not sign out of Google. It also explains the effect on private profiles becoming hidden until unlocked. This is comprehensive for a zero-parameter 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?

Three sentences, no wasted words. The most important action ('Lock the private/public gate') is front-loaded. Each sentence adds distinct value: function, process, and caveat.

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 zero parameters and the existence of an output schema (not shown but present), the description is complete. It explains the effect, what happens to private profiles, and how to unlock. No gaps remain for an agent to interpret.

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 the baseline is 4. The description does not need to add parameter information, and it correctly focuses on behavior and context. The schema coverage is 100% (trivially), so no additional detail is needed.

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 specific verbs ('Lock', 'closes', 'switches') and resources ('private/public gate', 'private browser contexts', 'active account'). It clearly distinguishes this tool from siblings like gv_sign_out (signing out of Google) and gv_unlock (reversing the lock), stating explicitly what it does and does not do.

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 (to lock private profiles) and mentions that gv_unlock can reverse it. However, it does not explicitly state when not to use it or list alternative tools for similar operations, though the context of sibling tools provides some implicit guidance.

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

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

No annotations are provided, so the description carries the full burden. It discloses the core effect (profile becomes private/hidden) and the prerequisite (password gate active). However, it does not describe idempotency, side effects, error states, or what happens if the gate is not active. Additional details on return values (output schema exists but not detailed) or authentication needs would improve 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?

The description is exceptionally concise: two sentences and an args line. It front-loads the purpose with the condition, then provides the prerequisite. There is no irrelevant information, making it easy for an AI agent to quickly grasp the tool's function.

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

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

The tool has an output schema (not shown), so return values need not be described. However, the description does not mention that the action is reversible via gv_make_public, nor does it specify behavior if the profile is already private. Given the complexity (simple mutation with one parameter), the description is adequate but lacks a nod to related siblings and edge cases.

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

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

Schema description coverage is 0%, and the description only adds a brief explanation: 'account_id: The account id to make private.' This is minimal and does not provide format, source, or examples. The description should compensate for the lack of schema description, but it only adds a marginal clarification.

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 purpose: 'Mark a profile as private (hidden when the gate is locked).' It uses a specific verb ('mark') and identifies the resource ('profile'). The explanation of the condition ('when the gate is locked') distinguishes it from sibling tools like gv_make_public, which does the opposite.

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 provides a prerequisite: 'Requires the password gate to be active (call google_setup_password first).' This tells the agent when to use this tool (after setting up password gate) and implies a sequence. It does not, however, mention exclusions or alternative tools for different scenarios.

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

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

With no annotations, the description must disclose behavioral traits. It only says 'make public' but doesn't mention side effects, error conditions, or prerequisites (e.g., profile must exist). Minimal 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?

Description is extremely concise: one-line purpose followed by parameter explanation. No wasted words; front-loaded with key 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?

Tool is simple with one parameter and an output schema. Description explains what it does and the parameter, but lacks mention of preconditions (e.g., profile existence) or effects. Adequate but not fully complete.

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

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

Schema coverage is 0%, and description adds 'The account id to make public.' This provides some meaning beyond the schema's 'Account Id' but remains basic. For a single parameter, this is adequate but not enriched with format or source hints.

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?

Description clearly states the action: 'Mark a profile as public (accessible without unlocking).' It uses a specific verb and resource, and it distinguishes from sibling tools like gv_make_private.

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

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

No guidance on when to use this tool versus alternatives, no prerequisites or exclusions mentioned. Description only states what it does, not 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?

Beyond the openWorldHint annotation, the description reveals key behaviors: reuses existing saved session, no login window or waiting, and marks the account as active. No contradictions 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?

The description is concise at about 5 lines, front-loaded with the primary action, followed by differentiation, usage condition, side effect, and parameter. Every sentence adds value without 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 tool with one parameter, no nested objects, and an existing output schema, the description covers purpose, usage, and behavior adequately. Minor omission: no mention of return value, but not critical given schema.

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

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

The description adds minimal meaning for the single parameter account_id ('The account id to open'), which is only slightly more than the schema's title. Given 0% schema coverage, the description compensates to some extent but lacks detail on format or source.

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 'Open the browser context for an already-signed-in account', specifying the verb (open) and resource (browser context). It distinguishes itself from sibling tool gv_sign_in by noting that this tool reuses an existing session without a login window.

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

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

The description explicitly tells when to use: 'Use this after a sign-in has succeeded once and you've since closed the browser.' It contrasts with gv_sign_in and explains that it marks the account as active for subsequent tools, providing clear context for tool selection.

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?

Discloses no persistent profile, no DB row, session being active target, default headless/block_images, 5-min auto-close. Contradicts no annotations (openWorldHint is consistent).

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?

Well-structured with clear opening, parameter bullets, default guidance, and lifecycle notes. Every sentence adds value without 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?

Covers all aspects: purpose, use case, parameters, defaults, return value, lifecycle, and integration with sibling tools. Nothing missing for an AI agent.

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

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

Despite 0% schema coverage, description explains each parameter's purpose and defaults, adding significant meaning beyond schema types.

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 'Open a throwaway browser session for anonymous scraping' with specific verb and resource. Distinguishes from siblings like gv_open_account by emphasizing no login needed.

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

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

Explicitly says 'NO account needed', 'perfect for public pages', and provides lifecycle guidance (call gv_close_ephemeral). Defaults and overrides are 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?

Beyond the openWorldHint annotation, the description discloses auto-SSO behavior and that the page becomes the current page for subsequent tools. Does not mention tab management or error handling, but adds useful 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?

Two concise paragraphs plus an Args section; every sentence adds value. Front-loaded with purpose, 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?

Covers key details: navigation purpose, state change (current page), parameter meanings. Missing potential error conditions or interaction with account state, but output schema likely fills gaps. Adequate for a simple 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?

Despite 0% schema description coverage, the description explicitly lists both parameters ('url' and 'wait_until') with their purpose, accepted values, and default. Fully compensates for the schema's lack of 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 clearly states the tool opens a URL in the active account's browser with specific verb and resource. It distinguishes from siblings like gv_click_element and gv_get_page_content by noting that the page becomes the current page for those 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?

Provides clear context on when to use: before gv_get_page_content/gv_click_element, and mentions universal compatibility including auto-SSO. Lacks explicit when-not-to-use or alternative tool references.

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?

Description details behavior: pressing keys, holding, modifiers, delay. It mentions return value. No contradiction with annotations (openWorldHint). Could note potential side effects (e.g., page changes) but sufficient for a key-press 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?

Description is well-structured with sections and examples. Slightly verbose but every sentence adds value. Front-loaded with purpose and key usage guidance.

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

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

All parameters covered, usage explained, return value mentioned. No gaps given the tool's complexity. Output schema exists but description still states return type.

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

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

Schema coverage is 0%, but description fully explains each parameter: key with examples, modifiers as array of modifier keys, hold_ms for long-press, delay_after_ms. Adds meaning beyond schema defaults and types.

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 presses a single key or key chord. It distinguishes itself from sibling 'gv_fill_input' by noting what it can do that fill_input cannot, providing specific examples.

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 'Use this for things gv_fill_input can't do' and gives concrete examples like submitting a form with Enter, tabbing, dismissing a modal with Escape, etc., providing 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 set readOnlyHint=true, confirming read-only behavior. Description adds 'Gmail's DOM changes often — if this returns empty...' which warns of potential instability and suggests workaround. No contradictions.

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 serving a distinct purpose: action, return format, fallback strategy, and parameter details. No redundancy, well-structured, and front-loaded with 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?

Comprehensive for a simple read tool: describes return format with fields, parameter constraints, and fallback behavior. Output schema hinted by the fields listed. No gaps given the low 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?

Only parameter 'limit' described with default (20) and max (50). While schema provides default, description adds max constraint and clarifies it's the number of messages. Schema coverage is 0%, so description compensates significantly.

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?

Description clearly states 'Read the Gmail inbox of the active account' with specific verb and resource. It distinguishes from siblings like gv_open_url and google_get_page_content by focusing on reading inbox versus browsing or page interaction.

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 advises when to use alternatives: 'if this returns empty, use gv_open_url to mail.google.com and google_get_page_content (with screenshot) instead.' This provides clear fallback and context for when the tool may not be effective.

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 annotations (openWorldHint, destructiveHint), the description details that it opens a browser, injects an action recorder, waits for manual login completion, records steps to config, and notes security (password/OTP never recorded). This adds significant 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 well-structured with a clear first paragraph stating purpose, a security note, a bulleted 'When to use' section, and an Args list. It is front-loaded and every sentence adds value without repetition.

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

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

The description covers the core functionality, security, and usage scenarios but lacks explanation of the 'Level 3' concept and does not address error handling or cancellation behavior. However, given the tool's complexity and existence of an output schema, it is fairly 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 0%, but the description provides brief yet clear explanations for both parameters: account_id is 'the account id to use' and provider is 'Override the provider. Defaults to the account's provider.' This compensates for the lack of 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 clearly states the verb 'Record' and resource 'login flow for future automatic replay'. It distinguishes itself from siblings like gv_sign_in (which replays) and gv_set_credentials (which stores actual credentials) by emphasizing the recording and teaching aspect.

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 'When to use' section provides explicit scenarios: complex login flows, sites where login form is hard to describe, and when you want to teach once then automate. It implicitly contrasts with simpler methods like login_steps and mentions future gv_sign_in calls will replay the steps.

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 readOnlyHint=true, and description adds context (vision support, examples). No contradictions.

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

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

Two concise sentences plus parameter note; no wasted words, front-loaded with 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?

Covers purpose, usage, and parameter meaning. Lacks description of output, but title implies PNG.

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 no description but the tool description explains the full_page parameter's effect clearly.

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?

Description clearly states 'Capture a screenshot of the current page as a PNG image' and provides specific use cases like visually locating buttons or reading captchas.

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

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

Explicitly says to use when text snapshot is ambiguous, distinguishing from gv_get_page_content (text snapshot).

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?

Provides detailed behavioral traits: small bursts, varied distance, reading pauses, mimicking real users. Highlights reCAPTCHA v3 relevance. Adds significant value beyond the minimal openWorldHint 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?

Concise with a clear intro, explanatory paragraph, and structured Args list. Every sentence adds value without 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?

Covers all aspects: purpose, behavioral nuances, parameter explanations, and return values (direction, amount, humanize). No gaps given the presence of an output schema.

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

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

Despite 0% schema coverage, the description fully explains each parameter (direction, amount, humanize, delay_after_ms) with concrete details like 'each ~300px' and 'randomized delay', adding meaning 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?

Clearly states 'Scroll the active page' with a specific verb and resource. Adds 'human-like increments' to distinguish from basic scrolling, aligning with anti-detection context.

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?

Describes when to use (human-like scrolling to evade behavioral detection) but does not explicitly exclude alternatives like scrolling via JS or other tools. Context is clear but lacks explicit 'when-not-to-use'.

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 annotations (destructiveHint=true), the description adds that credentials are saved in an encrypted fingerprint bundle, providing security context. No contradictions 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?

Two paragraphs and an Args section with no fluff. Purpose is front-loaded. Every sentence adds 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?

Given the presence of an output schema, the description explains behavior and preconditions adequately. Could mention return value or errors, but output schema covers that.

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 0% schema description coverage, the description fully compensates by explaining that credentials keys must match credential_key in login_steps, and provides an example. This adds significant meaning 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 it stores credentials for Level 2 form auto-fill, with a specific verb ('store') and resource ('credentials'). It distinguishes from siblings by positioning itself as a prerequisite for gv_sign_in on providers with login_steps.

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

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

Explicitly states when to use: before gv_sign_in on a provider with login_steps configured. Does not list when-not-to or alternatives, but provides clear context for usage.

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 annotations (openWorldHint, destructiveHint), the description adds that it opens a browser window, is one-time setup, and uses PBKDF2-SHA256 hashing. It doesn't mention reversibility or prerequisites, but the added detail is valuable.

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 concise, with three short paragraphs that each add value. It front-loads the main action and uses bullet points for clarity. No wasted sentences, though minor redundancy in explaining the hash.

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 zero parameters and a simple action, the description covers purpose, behavior, and relationship to other tools. It lacks mention of what happens if password already set or if it can be reset, but these are gaps given the existence of an output schema.

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

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

No parameters exist, so schema coverage is 100%. The description does not need to add parameter information, and the baseline 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 clearly states the tool opens a browser window to set a password for the private/public gate, using specific verb 'open' and resource 'password'. It distinguishes from siblings by noting it's a one-time setup and relates to privacy features like google_make_private and google_unlock.

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 context on when to use this tool: it's a one-time setup before marking profiles private. It mentions the result (password storage) and links to related tools, but doesn't explicitly state when not to use it or 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?

The description adds extensive behavioral context beyond the annotations (only openWorldHint): it opens a real browser window, user completes sign-in without Ghostvault touching password, session saved automatically, blocks until completion or timeout, and auto-selects login level. 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?

The description is detailed and well-structured with paragraphs and a decision guide. Every sentence adds value, but it is somewhat lengthy. However, given the tool's complexity (two login levels, credential handling), the length is justified.

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 key aspects: blocking behavior, auto-login level selection, credential handling, and reference to sibling tools. It lacks mention of the return value/response, but since an output schema exists (summary signals), this is partially mitigated. 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?

Despite 0% schema description coverage, the description's Args section explains each parameter: account_id as required, provider with default behavior (defaults to account's provider), and credentials as optional with clear role in Level 2 auto-fill. This adds significant meaning beyond the schema's type-only definitions.

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 opens a sign-in window for user login including 2FA. It specifies the resource (sign-in window) and verb (open), and distinguishes from siblings like gv_detect_login_options and gv_set_credentials by explaining when to use each.

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 explicit decision guidance: for Google/SSO use Level 1, for providers with login_steps store credentials first via gv_set_credentials, and if unsure call gv_detect_login_options. It also differentiates between Level 1 and Level 2 login based on credential availability, giving clear when-to-use and when-not-to-use advice.

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, so the description adds value by detailing the side effects: opens browser, navigates, waits, closes, and forces re-authentication. This goes beyond the annotation by specifying the sequence and the case of missing logout URL, but could mention if cookies are cleared.

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 concise and well-structured: it starts with the core action, then lists steps and special cases, and ends with parameter docs. Every sentence adds necessary detail without 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?

Given the tool's complexity (browser automation) and the presence of an output schema, the description covers the main behaviors: session invalidation, browser operations, and fallback for missing logout URL. It could be slightly more complete by describing what happens to existing browser state, but overall it provides sufficient 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 input schema has 0% description coverage, so the description fully compensates by explaining each parameter: account_id is the account to sign out, and provider is an override that defaults to the account's provider. This adds essential meaning beyond the schema's type information.

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 purpose: signing an account out of a provider by invalidating the session server-side. The detailed steps (opening browser, navigating to sign-out URL, waiting, closing) and handling of missing logout_url further clarify its function. While siblings like gv_logout exist, the description is specific enough to distinguish its action.

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 what happens after sign-out ('account must sign in again before any browser tools work') and handles a special case (no logout_url), providing implicit context. However, it does not explicitly tell when to use this tool over alternatives like gv_logout, nor does it provide exclusions or prerequisites.

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