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 states the output (exit IP and location) but fails to disclose behavioral details such as whether the proxy is actually used to make a request, any side effects, error handling, or performance implications. The description is too minimal to be transparent.

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

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

The description is a single sentence, efficiently conveying the core purpose. There is no filler or repetition. While it could benefit from additional structure, it is concise.

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 6 parameters with no output schema or annotations. The description only mentions the return value (exit IP and location) but not the format or behavior for different protocols (http, https, socks5). It fails to address error cases or prerequisites, leaving the agent with incomplete context.

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

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

Schema description coverage is 100%, so parameters are individually described. The tool description adds no additional meaning beyond the schema—it does not explain how parameters relate (e.g., connectionString vs. host/port/username/password). Given high coverage, a 3 (baseline) is appropriate.

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

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

The description clearly states the verb 'Check' and the resource 'proxy connection', and specifies the output: 'exit IP and location'. It effectively distinguishes this tool from siblings like 'create_rotating_proxy_connection' and 'list_static_proxies', which have different purposes.

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. With siblings like 'check_proxy', 'create_rotating_proxy_connection', and 'list_static_proxies', the description could have clarified the appropriate scenario (e.g., testing a specific proxy vs. managing proxy lists), but it does not.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses a key constraint ('Rejected while a CDP client is connected') and that the URL allows watch and control, but omits permissions, side effects, whether it creates a persistent resource, or URL lifetime. For a tool whose name suggests creation, this leaves important behavioral gaps.

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

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

Two sentences, no waste, front-loaded with the core purpose followed by a critical rejection condition. Every sentence earns its place and the structure makes the key limitation immediately visible.

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

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

For a simple one-parameter tool with no output schema and no annotations, the description covers the purpose and a crucial operational constraint. It could mention URL lifetime or permission requirements, but it is largely complete given the tool's simplicity and the absence of an output schema to explain return values.

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

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

Schema description coverage is 100% and the single parameter (sessionId) is fully documented in the schema. The description adds no syntax, format, or selection guidance beyond what the schema provides. Baseline 3 is appropriate when the schema does all parameter documentation.

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

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

The description states a specific verb (Get) and resource (URL a human can open to watch and control a running Cloud Browser session). It clearly distinguishes from siblings like list_browser_sessions, get_browser_session, stop_browser_session, and create_browser_session, though it does not explicitly name any alternative. The scope is precise and front-loaded.

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 it (when a human needs to watch and control a running session) and provides a when-not condition ('Rejected while a CDP client is connected'). However, it does not name alternatives or explain when to prefer this over get_browser_session or other session tools. Implied usage with one exclusion, but no explicit routing.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses billability ('stop the session when done to stop billing') and the returned connectUrl contract, which are real behavioral facts. However, it omits auth/permission requirements, lifetime limits, and what happens to state after the session ends, so the disclosure is partial.

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 tightly packed sentences with the purpose front-loaded and no filler. 'The smallest request is {}' is terse but earns its place by flagging that all 8 params are optional. Minor density is the only cost.

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

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

For a complex 8-parameter session-creation tool with nested objects and no output schema, the description covers the critical missing piece (the returned connectUrl and how to connect to it) plus the billing lifecycle. Remaining schema-documented behaviors (persist TTL, settings reuse, runtime timeouts) are adequately handled by the rich schema.

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

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

Schema description coverage is 88%, so the schema already documents almost all parameters (proxy, browser/fingerprint, persist, runtime, storage, settings, startUrl). The description only adds that an empty request is valid ('smallest request is {}'), which is marginal beyond the schema's required:[] declaration, so the baseline 3 fits.

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

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

Specific verb + resource: 'Start a Cloud Browser with a Floppydata proxy attached.' The billing/connection framing makes it clear this is a session-creation tool. It does not name any sibling (e.g., create_browser_live_view) to sharpen the distinction, so it stays at a clear-but-undifferentiated 4.

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?

'Drive it with Puppeteer/Playwright using the returned connectUrl' and 'Stop the session when done to stop billing' imply the lifecycle (start → connect → stop), which is implied usage rather than explicit when-to-use guidance. There is no explicit statement of when this tool is preferable to alternatives or what conditions to avoid.

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 provided, so description carries full burden. It only states the tool 'builds' a string, but does not disclose whether the string is returned, requires authentication, or has any side effects. Minimal behavioral insight.

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?

Single sentence, front-loaded with key information. No fluff, but could be more structured (e.g., bullet points).

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 has 8 parameters and no output schema. Description is very brief; does not explain return value (presumably a string) or how rotation options work. Needs more detail for completeness.

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

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

Schema description coverage is 100%, so the schema already documents parameters. The description adds the context of 'copy-paste' and lists attributes, but adds little beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Build one copy-paste rotating proxy connection string' with explicit attributes. It is specific but does not differentiate from siblings like list_rotating_proxy_locations.

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. Siblings include list_rotating_proxy_locations, but no context 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?

With no annotations provided, the description carries the full behavioral burden. It usefully discloses the blast radius ('Persistent browser settings are kept'), which distinguishes it from a destructive settings wipe, but omits irreversibility, permission requirements, and the failure behavior for non-ended sessions.

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

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

Two short sentences, front-loaded with the action and scope, with the sibling pointer placed last. No filler or redundancy.

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

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

For a single-param delete with no output schema, the description covers purpose, the preserved-settings side effect, and the alternative tool. The remaining gap is mutation semantics (permanence/irreversibility), which matters more here because there are no annotations to signal 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 description coverage is 100% and the single sessionId param is fully documented in the schema with format and pattern constraints. The description adds no syntax or format meaning beyond it, so the baseline 3 applies.

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

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

States a specific verb and resource ('Delete an ended Cloud Browser session from history') and scopes it precisely to ended sessions. It also names the sibling it is not (delete_browser_settings), so an agent can discriminate without opening either schema.

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

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

Explicitly routes the settings case to delete_browser_settings and constrains scope to 'ended' sessions. It does not state what to do with a still-running session (e.g., stop_browser_session first) or that deletion is only valid post-termination, so guidance is clear but not exhaustive.

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

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

With no annotations, the description carries the full burden and does well: it discloses irreversibility ('Permanently delete'), the exact scope of destruction (settings, cookies, storage), and the failure condition (active session). It omits auth/permission requirements and whether the failure is an error or a silent no-op.

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

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

Two sentences, zero filler, with the destructive scope and the failure condition front-loaded. Every clause earns its place.

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

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

For a one-parameter, no-output-schema tool with no annotations, the description covers the essentials an agent needs: what is destroyed, that it is permanent, and when it will fail. Only minor gaps remain (error/return behavior after failure), which are not required to invoke it correctly.

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

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

Schema description coverage is 100% and the single settingsId parameter is fully documented in the schema with format and pattern constraints. The description adds no additional meaning about the identifier beyond what the schema already provides, so the baseline 3 applies.

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

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

The description gives a specific verb ('Permanently delete') and resource ('saved Cloud Browser settings and browser state (cookies, storage)'), which is enough to tell it apart from delete_browser_session in practice. However, it never explicitly contrasts itself with the sibling session-deletion tool, so it falls just short of full sibling differentiation.

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

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

It states a clear precondition for use: the call fails while a session using the settings is running, which is actionable guidance for an agent. It does not name alternatives (e.g., delete_browser_session) or say when to prefer this over them, so no explicit exclusion guidance.

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

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

No annotations provided. Description does not disclose behavioral traits like rate limits, authentication needs, error handling, redirect behavior, or content size limits. For a fetch tool, critical gaps remain.

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, front-loaded with action and usage. No irrelevant 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?

No output schema and description lacks details on return format, error behaviors, or limitations. With 5 parameters and no annotations, more context is needed for correct invocation.

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

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

Schema description coverage is 100%; all 5 parameters have descriptions. The tool description adds no extra meaning beyond what the schema already provides, so baseline 3 is appropriate.

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

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

Clearly states the action 'Fetch', the resource 'public web page', and specifies output as 'HTML of a URL'. Distinguishes well from sibling proxy- and account-focused 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?

Explicitly states 'Use this when the agent needs the HTML of a URL.' Provides clear context but lacks explicit when-not-to-use or alternative suggestions.

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 must carry the full burden. It states 'Get' which implies a read-only operation, but does not disclose any potential side effects, authentication requirements, rate limits, or behavior when the optional product filter is omitted.

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

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

The description is a single sentence that directly states the tool's action and scope. No filler or redundancy; every word earns its place.

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

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

Given the tool's simplicity (single optional parameter, no output schema), the description provides sufficient context for an AI agent to understand its purpose. However, it could be improved by briefly noting that no balances are returned if the filter yields no results.

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

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

Schema description coverage is 100% with 'Optional product filter.' The description adds value by explicitly listing the product types (Web Data, rotating proxy traffic, static proxies) which matches the enum values and clarifies the context of the balances.

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 'Get' and specifies the resource 'account balances' for three distinct product types. It immediately distinguishes itself from sibling tools like 'list_static_proxies' or 'fetch_web_data' by focusing purely on balance 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?

No explicit guidance on when to use this tool versus alternatives. The description implies usage for retrieving balances, but does not mention scenarios where it should or shouldn't be used, nor does it reference alternative tools.

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

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

No annotations are provided, so the description carries full burden of behavioral disclosure. It only lists returned fields but does not mention read-only nature, authentication needs, or what happens with invalid parameters.

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

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

Two dense sentences effectively front-load the purpose and key response fields. Slightly more detail on parameter effects would not harm conciseness.

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

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

Given no output schema, the description partially explains return fields but omits details on 'requestedRange' behavior and how filters affect results. Adequate for simple usage but incomplete for complex queries.

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

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

Schema coverage is 100%, so the schema already documents all 6 parameters. The description adds no additional meaning beyond the schema for parameters, meeting the baseline of 3.

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

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

Description clearly states the tool's action 'Get account usage rollups' and lists specific response fields. The tool name and context differentiate it from proxy management siblings.

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

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

No explicit guidance on when to use vs. alternatives. The purpose is implicit from the tool name and description, but no when-not-to or prerequisite info 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?

With no annotations, the description carries the full burden, but it does disclose two useful traits beyond the schema: the connectUrl is freshly signed (not cached) and it is only returned 'while the session is running', hinting at a failure condition. It omits auth/permission requirements and any rate-limit or error behavior for stopped/expired sessions.

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

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

Two short sentences with zero filler; the core action is front-loaded and the return-value note follows immediately. Every sentence earns its place.

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

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

There is no output schema, so the description must hint at returns, and it does identify the key payload (connectUrl) plus the running-session precondition. The undefined term 'state' leaves the full response shape somewhat ambiguous, but for a one-parameter getter this is close to 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?

Only one parameter (sessionId) and schema coverage is 100%, so the schema already documents its format and UUID pattern. The description adds no meaning beyond that, which matches the baseline 3 for fully documented schemas.

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

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

States a specific verb and resource ('Get a Cloud Browser session's state'), which clearly separates it from list_browser_sessions, create_browser_session, and stop_browser_session. It does not, however, explicitly name a sibling or state that it operates on a single session by id, so differentiation is inferable rather than stated.

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

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

The mention of returning a connectUrl implies the use case (retrieving an attachment URL for a running session), but there is no explicit when-to-use guidance, no prerequisites, and no named alternative such as list_browser_sessions. Usage is implied rather than spelled out.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose two useful traits beyond the schema: results are ordered newest first and paging is cursor-based. It omits auth/permission requirements, whether the operation is read-only (only implied by 'List'), rate limits, and what the returned session records contain.

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

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

A single front-loaded sentence with zero filler: the resource is named first, then ordering and pagination. Every clause carries information an agent can act on.

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

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

For a zero-required-parameter read tool this covers the essentials, but with no annotations and no output schema the description could have stated the read-only nature and that responses include session records plus a nextCursor for continued paging. The pagination hint is present but the return shape is left to inference.

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

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

Schema description coverage is 100%, so all three parameters (limit, cursor, status) are already documented in the schema, including the enum values and the nextCursor reference. The description adds only the generic notion of cursor pagination and does not enrich parameter meaning beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb (List) and resource (Cloud Browser session history) with added scope detail: ordering ('newest first') and pagination mode ('cursor pagination'). The plural resource and 'history' framing distinguish it from the singular sibling get_browser_session, though no sibling is named explicitly.

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

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

Usage is only implied by the phrase 'session history' — an agent can infer this is for enumerating past sessions, and the ordering/pagination hints suggest it is the paging entry point. There is no explicit when-to-use, when-not, or reference to alternatives such as get_browser_session for a single record, nor any note on using the status filter.

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 implies a read operation and associates locations with proxy types, but does not disclose aspects like coverage, staleness, or side effects. It is adequate but not rich.

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?

Single sentence, no wasted words. Front-loaded with the verb and resource, perfectly concise.

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?

Simple tool with one parameter and no output schema. The description covers the basic purpose but does not specify output format (e.g., array of objects with country, city, state) or any limitations. Adequate but could be more 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 100%, so baseline is 3. The description does not add meaning beyond the schema; it does not relate the 'type' parameter to the listed locations explicitly. No extra value added.

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

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

The description clearly states the tool lists countries, cities, and states for rotating proxy connection generation. The verb 'list' and resource 'locations' are specific, and it distinguishes from siblings like list_static_proxies and create_rotating_proxy_connection.

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 like list_static_proxies or check_proxy. No mention of prerequisites, 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?

No annotations exist, so the description should disclose behaviors. It only says 'list' and 'includes connectionString' but does not mention read-only nature, rate limits, or whether all proxies are returned. The term 'owned by the account' implies filtering but is insufficient.

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?

Single sentence that conveys the essential information without any superfluous words. Highly front-loaded 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?

For a parameterless list tool with no output schema, the description states the resource and what is included (connectionString). It could mention pagination or format but is adequate for a simple list.

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 zero parameters, so 100% schema coverage. The description adds that connectionString is included, which is helpful. Baseline 4 is appropriate.

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

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

The description clearly states the verb 'List' and the resource 'static proxies owned by the account', specifying that it includes connectionString. It easily distinguishes from siblings like list_rotating_proxy_locations.

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 is provided on when to use this tool vs alternatives, or prerequisites. The description only states what it does, not when it's appropriate.

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

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

With no annotations, the description carries the full burden. It usefully discloses two behavioral traits: the session persists browser state, and the call is idempotent ("Safe to call more than once"). It does not say whether stopping is blocking, whether the saved state can later be resumed, or what happens to in-flight work.

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

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

Two short sentences with zero waste, front-loading the action and then the side effect, with the idempotency note last. Nothing needs trimming or reordering.

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

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

For a simple one-parameter tool with no output schema and no annotations, the description covers the action, the side effect, and retry safety. It stops short of clarifying the semantics of "persistent browser state" or how this differs from delete_browser_session, which is the one gap an agent would hit.

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

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

Schema description coverage is 100% for the single required sessionId parameter, so the schema already documents it. The description adds no format, sourcing, or lookup details beyond what is structured, making 3 the correct baseline.

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

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

Specific verb and resource ("Stop a Cloud Browser session") plus the side effect of saving persistent browser state. This implicitly separates it from the sibling delete_browser_session, but the distinction is never made explicit, so an agent must infer it.

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

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

No explicit when-to-use or when-not-to-use guidance, and no mention of the closely related delete_browser_session as an alternative. The only hint is that stopping preserves state, from which the agent must infer that deleting would not.

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