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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the useful detail that results include a frozen flag and subscription state, but nothing about auth, rate limits, or freshness.

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 compact sentence with no filler, and the most important payload (remaining traffic) is front-loaded. Slightly list-like but efficient.

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

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

An output schema exists, so return-value documentation is not required, and the description covers the conceptual payload. However, for a query tool sitting among several traffic-related siblings it gives no routing context, leaving a meaningful gap.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 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?

Names the concrete outputs (remaining traffic in bytes, subscription status, frozen flag), so an agent knows what resource it reports on. It doesn't differentiate itself from siblings like traffic_stats, so it falls short of a 5.

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

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

There is no guidance on when to call this versus traffic_stats or other siblings, and no stated preconditions. Usage must be inferred entirely from the description's content.

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 cover the safety profile (readOnly=false, destructive=false, openWorld=true), and the description adds real context on top: it is an account-mutating action ('Changes the account') and it discloses the non-obvious rejection edge case where a recently removed address may be refused as already whitelisted. Missing disclosure of what limits apply to ports_count and whether adding is idempotent.

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?

Front-loaded with the core effect in one sentence, then parameter clarifications, then the edge case. Tight enough, though the final sentence is slightly garbled ('can be refused as already whitelisted for a while') and could be clearer.

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 output schema means return values need not be explained, and the mutation semantics plus the rejection edge case are covered. Still, for an 8-parameter mutation tool with zero schema descriptions, the unaddressed 'name' and 'protocol' parameters leave the definition short of 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%, so the description must compensate: it explains ports_count's meaning and that country/region/city/isp are codes obtained via list_locations, which is genuinely useful. But 'name' and 'protocol' (the only enum parameter) are never explained, leaving a meaningful share of the 8 parameters undocumented.

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 — allow an IP to use the proxy without a password — which immediately distinguishes it from list_whitelist_ips and remove_whitelist_ip. The scope ('without a password') clarifies the real effect rather than just restating the name.

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?

Implied usage is clear from the purpose, and the note about codes coming from list_locations routes the agent to a prerequisite sibling. However, there is no explicit statement of when to use this versus remove_whitelist_ip or list_whitelist_ips, and no stated prerequisites (e.g. account/plan limits) beyond the location-code hint.

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 establish readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is clear. The description adds meaningful behavior beyond that: it sends no traffic through the tunnel, returns gateway status, exit IP, and elapsed time, and notes that a 407 can reflect a bad parameter as well as bad credentials. It does not discuss authentication or rate limits, but it is substantially more transparent than the annotations alone.

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 front-loaded and each sentence carries useful information: core action, traffic behavior, return values, error interpretation, and a mobile-specific routing note. There is no obvious filler, though the mobile note could be 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?

An output schema exists, so the description does not need to explain return values, though it helpfully summarizes them. Safety annotations cover the read-only profile. The major gap is that an 8-parameter tool with zero schema descriptions leaves most filter and session parameters unexplained, which is not complete enough for correct invocation in all 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?

The schema has 8 parameters and 0% description coverage, so the description carries the burden of explaining parameter meaning. It only hints at connection_type="mobile" and that mobile location codes come from list_locations; it never explains isp, ttl, city, filter, region, country, or session_id. This leaves most parameters semantically opaque.

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

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

The description states a specific action and resource: opening one connection through the proxy and reporting the result. It also clarifies that no tunnel traffic is sent, which helps distinguish a connectivity check from actual proxied requests. However, it does not explicitly name or contrast the sibling test_proxy_on_site, so it falls 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?

The description implies usage as a connectivity/credential check and gives a useful troubleshooting hint for 407 responses. It also directs mobile users to list_locations with connection_type="mobile". But it does not explicitly say when to use this instead of test_proxy_on_site, proxy_url, or other siblings, and gives no when-not guidance.

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

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

Goes well beyond the annotations by disclosing real behavioral facts: the call mutates the account, the password is generated server-side, and it is only returned in the response when the server permits revealing passwords, otherwise the user must read it in the dashboard. That conditional return behavior is exactly the kind of detail an agent cannot infer from readOnlyHint/destructiveHint/openWorldHint.

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?

Front-loaded with the purpose, then the password behavior, then the parameter caveat — a sensible ordering with little waste. 'Changes the account.' is an under-specified fragment but is short enough not to be a real 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 two-parameter mutation tool with an output schema already covering returns, the description covers creation semantics, the auth/reveal caveat on the generated password, and the traffic_limit unit convention. Only username constraints and any account-level preconditions are missing.

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

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

Schema description coverage is 0%, so the description must carry the load, and it does for the non-obvious parameter: traffic_limit uses the same unit as list_sub_users' traffic_limit/used_traffic, and omitting it means no limit. The username parameter gets no treatment (format, uniqueness, or constraints), which is the only meaningful gap.

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?

Starts with a specific verb+resource ('Create a sub-user') and adds distinguishing detail not in the name: the sub-user gets 'its own proxy login.' This separates it from update_sub_user and delete_sub_user, though it never names those siblings explicitly.

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

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

The intent (create a new sub-user) is implied by the verb, but there is no explicit guidance on when to use this versus update_sub_user, nor any prerequisites such as account plan limits or username uniqueness. The only conditional guidance given is parameter-level (omit traffic_limit for no limit).

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so safety is pre-established. The description adds valuable context beyond annotations: the proxy login stops working and the deletion is irreversible. It does not cover permissions or downstream side effects beyond login access.

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

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

Three short sentences, front-loaded with the action and followed by the most important consequences. Every sentence adds information with zero 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?

An output schema exists, so return values need not be explained. For a simple destructive tool, the description covers the essential effect and irreversibility, though it omits where to obtain the sub_user_id and whether any preconditions apply.

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 does not explain the required sub_user_id parameter at all. With only a self-explanatory name and no mention of format, source (e.g., list_sub_users), or constraints, it fails to compensate for the undocumented 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 gives a specific verb and resource ('Delete a sub-user') and clarifies the concrete effect on the proxy login. It is clearly distinct from siblings like update_sub_user or create_sub_user, though it does not explicitly name an alternative.

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

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

Usage is implied by the destructive verb and the warning that the action cannot be undone. However, it does not explicitly say when to use this versus update_sub_user or other alternatives, nor does it state prerequisites such as requiring an existing sub-user ID.

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 cover the safety profile (readOnlyHint=true, openWorldHint=true, destructiveHint=false), so the bar is lower, and the description adds genuinely useful behavior: the 100-row cap and the next_offset/offset continuation loop. It does not mention auth, rate limits, or errors beyond pagination.

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

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

Three short sentences, front-loaded with the purpose before the parameter rules and pagination mechanics. Nearly every clause earns its place, though the pagination sentence is slightly terse relative to its importance.

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?

An output schema exists, so return values needn't be explained, and the description still helpfully notes next_offset. For a 6-parameter tool it is largely complete, but the omission of limit and connection_type leaves a small gap.

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

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

Schema description coverage is 0%, so the description must carry the load. It explains the meaning of country_code and region_code per kind and the offset continuation, but never mentions limit or connection_type (an enum with residential/mobile), leaving two parameters undocumented.

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

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

States a specific verb+resource ('List locations available for targeting') and immediately frames the purpose: producing the codes that proxy_url consumes. This explicitly ties it to the sibling proxy_url and distinguishes it from unrelated siblings like traffic_stats or top_domains.

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?

Gives hierarchy-aware guidance: 'regions need country_code; cities and isps can be narrowed by country_code and region_code.' This tells the agent which parameters matter for which kind. It stops short of naming alternative tools or stating when not to call it, so it lands at 4 rather than 5.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description adds meaningful context beyond that: the pagination contract (start at 1, resume via next_page, empty result past the end) and the security-relevant guarantee that no passwords are returned.

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 short and front-loaded: the resource and payload come first, then the pagination behavior. Both sentences carry information, though the stray line break mid-sentence is cosmetic rather than wasteful.

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

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

An output schema exists, so return values need not be explained, and the description covers the one non-obvious interaction detail an agent needs (how to paginate). For a single-optional-parameter read tool, this is close to complete, with only sibling differentiation left implicit.

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 there is one parameter (page), so the description carries some burden. 'Paged from page 1' documents the starting convention, which is the only real semantic addition; it doesn't clarify whether page is 1-based offset semantics beyond the default, and next_page is referenced without being a declared input.

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?

Identifies the specific resource (sub-users of the account) and the payload (traffic usage and limits), and adds the exclusion 'No passwords.' The verb is only implied by the tool name, but the resource is clearly distinct from siblings like traffic_stats, top_domains, and proxy_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?

Gives explicit operational guidance for pagination: start at page 1, and when next_page is returned call again with it; a page past the end comes back empty. However, it offers no guidance on when to prefer this tool over siblings such as traffic_stats, which is implied but not stated.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered structurally. The description adds genuinely new behavior: the result is paginated starting at page 1, and a next_page value in the response signals more results, which is exactly the operational detail an agent needs to avoid treating the first page as complete.

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 padding. What the tool returns comes first, then the pagination protocol, which is the right front-loading for a list tool.

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

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

An output schema exists, so return-value documentation is unnecessary, and pagination — the main behavioral risk for a list tool — is covered. The one gap is the exact mechanics of passing next_page back as the `page` argument, which the description leaves slightly underspecified.

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% for the single `page` parameter, so the description must carry the load — and it does, explaining the default start at page 1 and instructing the agent to feed the returned next_page back in. Minor ambiguity remains over whether next_page is passed as `page` verbatim or is an opaque token.

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

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

The description names the resource precisely — IP addresses allowed to use the proxy without a password — plus the fields returned (ports, targeting). The list/read verb is implied rather than stated, but with the tool name and the add/remove siblings, an agent can tell exactly what this returns.

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 guidance covers pagination well ('paged from page 1', 'call again with next_page'), but says nothing about when to choose this over the sibling add_whitelist_ip / remove_whitelist_ip / check_proxy tools. The procedural guidance is clear; the sibling routing is left to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description is consistent with a non-mutating builder. Beyond the annotations it discloses genuinely useful behavior: the password is a placeholder unless the server allows revealing it, and session/exit-IP semantics. It does not describe the returned string shape, but an output schema exists to cover that.

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?

Front-loaded with the one-line purpose, then a tightly packed block of parameter semantics with zero filler sentences. It is dense but every sentence conveys a distinct, actionable fact.

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 9-parameter, zero-required, zero-coverage tool with an output schema, the description covers the decision-critical semantics (session, targeting, connection type, placeholder password). Only the protocol parameter and any explicit alternative-tool routing are missing, which are minor given the rest.

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 carries the full burden, and it does so for eight of nine parameters: session_id/ttl semantics, two-letter country, region/city/isp codes sourced from list_locations, filter example 'medium', and connection_type branching. The only gap is protocol (http vs socks5), whose enum is self-explanatory but never mentioned.

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 ('Build a NodeMaven proxy string'), which is clearly distinct from siblings like check_proxy, test_proxy_on_site and list_locations. An agent can tell instantly that this constructs a connection string rather than testing or listing anything.

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?

Gives concrete when-to guidance on the key decision: omit session_id for a fresh exit IP per request, or supply it to pin an exit for ttl. It also explains the mobile branching (take location codes from list_locations with connection_type='mobile'). It stops short of explicitly contrasting with check_proxy or test_proxy_on_site, so no true exclusions are stated.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=true, so the safety profile is carried by structured data and the bar for the description is lower. The description adds the ID provenance but nothing about irreversibility, whether removal immediately affects live proxy traffic, or error behavior for unknown ids.

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

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

A single front-loaded sentence with no filler; the action is stated first and the input requirement second. 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?

An output schema exists, so return values need no explanation, and destructive semantics are covered by annotations. The only meaningful omission is whether the removal is reversible and whether it takes effect immediately, which matters for a destructive one-param tool.

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

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

Schema description coverage is 0%, so the description must compensate, and it does meaningfully by telling the agent the required ip_id is the identifier returned by list_whitelist_ips or add_whitelist_ip. It still doesn't state the format of the id or what happens if a stale id is supplied.

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 ('Remove an address from the whitelist') and even identifies where the identifier comes from, which implicitly separates it from the sibling tools list_whitelist_ips and add_whitelist_ip. It stops just short of an explicit 'unlike add_whitelist_ip, this...' contrast, but the purpose is unambiguous.

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

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

Gives a concrete precondition for invocation: the ip_id must come from list_whitelist_ips or add_whitelist_ip, which routes the agent to the right sibling to obtain input. It does not state any when-not-to-use case or confirm that the removal is immediate, so it is strong 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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered; the description adds real value by specifying exactly what is overwritten (recorded traffic counters to zero) and that the change affects the account. It still doesn't say whether the reset is reversible or whether it is billed/irrecoverable, which keeps it below 5.

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

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

Two short sentences, the action statement first and the account-wide impact warning second. Nothing is padded and nothing needs restructuring.

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?

An output schema exists so return values need not be explained, and the annotations cover destructiveness. However, for an irreversible mutation the description omits permissions needed, the source of valid IDs, and any note on scope of effect beyond 'the account'.

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 and schema description coverage is 0%, so the description carries the burden; 'one or more sub-users' usefully confirms the array can hold multiple entries. It does not explain the ID format or provenance, so it only partially compensates for the coverage gap.

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

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

States a specific verb+resource: setting recorded traffic of sub-users to zero, which is clearly distinct from delete_sub_user or update_sub_user. It stops short of naming any sibling to contrast against, so a 4 rather than a 5.

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

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

No guidance on when to reset versus update_sub_user, no prerequisites, and no mention of where to obtain sub_user_ids (e.g., list_sub_users). The only contextual hint is 'Changes the account,' which is a caveat, not usage direction.

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 it read-only/open-world, and the description adds real behavioral context beyond them: a single GET, a 2 MB read cap, the page body is not returned, and refusals are surfaced as a block reason for 403/429/captcha/challenge. The JS-vs-browser caveat is exactly the kind of limitation an agent could not infer from structured fields.

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?

Opens with the core action, then layers returns and caveats in descending priority with no filler. The trailing mobile/list_locations sentence is useful but sits oddly detached from the location parameters it refers to.

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?

Return values are already covered by an output schema, and the description usefully summarizes them anyway. However, for a 9-parameter tool with no schema descriptions, leaving the proxy-selection parameters undefined is a material gap an agent will hit at call time.

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% across 9 parameters, so the description must carry the load, but it only addresses connection_type and indirectly points at location codes via list_locations. The meanings of isp, ttl, filter, session_id, and the country/region/city targeting hierarchy are left entirely unexplained.

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

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

States a specific verb+resource: sends one GET for a single page through a proxy and reports whether it answered, with the scope (2 MB cap, page body not returned) made explicit. It distinguishes itself from a generic health check by describing the block-reason reporting, but it never names the closest sibling (check_proxy) to draw a clean line.

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?

Gives clear situational guidance: this is a weaker test than a real browser, JS-dependent sites can refuse it yet still be served in a browser, and mobile targeting requires location codes from list_locations with connection_type="mobile". No explicit when-not-to-use versus check_proxy or proxy_url.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the default time window and the non-ISO date format constraint, which is genuine behavioral context, but says nothing about pagination, result size, or how limit interacts with the ranking.

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

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

Two tight sentences: the first front-loads what the tool returns, the second covers the time-window inputs and default. No filler, though the trailing blank line and the 'Pass period, or...' phrasing is slightly terse rather than polished.

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?

An output schema exists, so return values need not be described, and the time-window inputs are covered. Still missing for a 4-parameter tool: the meaning of limit, the enum semantics of period, and precedence when both period and start/end are supplied.

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 carries the burden and it does explain period, start and end, including the dd-mm-yyyy format warning. But it ignores the limit parameter entirely and never enumerates the period values (today, hours24) that the schema only exposes as a bare enum.

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 the resource clearly ('Domains reached through the proxy') and the ordering/aggregation ('largest traffic first, with bytes and request counts'), so the agent knows exactly what comes back. It does not explicitly differentiate itself from siblings like traffic_stats or proxy_url, but the scope is unambiguous.

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

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

It explains how to supply a time window (period, or start/end as dd-mm-yyyy) and notes the default is today, which is useful call-site guidance. However, it never says when to choose this tool over traffic_stats or proxy_url, and it doesn't say whether period and start/end are mutually exclusive.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavioral context: the output is 'parallel labels and data arrays' and dates must be dd-mm-yyyy rather than ISO. This is a real addition beyond annotations, though it does not touch auth, rate limits or error behavior.

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

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

Two short sentences with no filler; the purpose is front-loaded before the parameter notes. The 'parallel labels and data arrays' phrasing is slightly cryptic, which costs a point.

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?

An output schema exists, so return values need not be described. With three parameters at 0% schema coverage, the description covers the date format and default but leaves the period enum values and start/end pairing rules to inference, which is a clear gap for an agent invoking the tool.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden. It documents the start/end format ('dd-mm-yyyy (not ISO)') and the default ('today'), but never names the allowed period values (today, hours24) or notes that start/end are the alternative to period. It compensates partially, not fully.

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 resource and scope: 'Traffic used over time, as parallel labels and data arrays.' An agent can tell this returns time-series bandwidth data. However, it does not distinguish this from siblings like account_status or top_domains, which may also touch usage figures, so it falls short of a 5.

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

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

The only usage direction is parameter-shape guidance ('Pass period, or start and end... Defaults to today'). There is no statement of when this tool is the right choice versus alternatives, nor any when-not condition, so the guidance dimension is largely unaddressed.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so safety context is provided. The description adds the vague note that it 'Changes the account,' which hints at account-level impact but does not explain permissions, reversibility, or null-field behavior.

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

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

Two short sentences with no wasted text, and the core action is front-loaded. The brevity is appropriate for a simple update tool.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. However, with 0% schema description coverage, the description is still too thin on parameter behavior and account impact for fully confident 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 0%, so the description must carry parameter meaning. It maps loosely to traffic_limit and is_traffic_limited, but does not explain the required sub_user_id or the null/default semantics of the optional fields.

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

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

The description states a specific verb and scope: changing a sub-user's traffic limit or toggling that limit. This distinguishes it from siblings like reset_sub_user_usage, delete_sub_user, and list_sub_users, though it does not name any sibling 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?

It implies when the tool is used by describing the update action, but gives no explicit when-to-use, when-not-to-use, or comparison to alternatives such as reset_sub_user_usage. The agent must infer usage conditions from the tool name and sibling list.

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