ProxyRange

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

Annotations already declare this a safe, read-only, idempotent, closed-world operation, so the safety profile is covered. The description adds genuinely non-obvious behavioral detail that annotations cannot express: first-purchase offers, coupons and upper bounds are excluded, providers with a Concerning sourcing check are dropped, and a market median is included in the result — these materially affect how an agent should interpret the output.

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 core claim (lowest regular checkout prices, ranked) is front-loaded, and the methodology clauses that follow are load-bearing rather than filler. The single long sentence carrying all the exclusion rules is dense, but trimming it would lose information an agent needs to trust the ranking.

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

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

With an output schema present, return shape need not be explained, and annotations cover the safety profile. What remains — pricing basis, exclusion rules, and the median that appears in results — is fully stated, leaving no material gap for a zero-required-parameter read-only 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 100%, so every parameter (limit, needs, basketGb) is already documented with ranges, enums and per-value meaning. The description only restates the 1/10/100 GB options and the existence of a requirements filter, adding no syntax or interaction detail beyond the schema — 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 names a specific resource (regular checkout prices for 1/10/100 GB of residential proxy traffic) and an explicit ranking methodology, so an agent knows exactly what comes back: a price ranking, not a provider catalog. It does not, however, contrast itself with siblings like compare_providers or find_providers, which plausibly return ranked or filtered provider lists, so the sibling distinction is left to inference.

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?

'Optionally only providers meeting given requirements' implies the use case (find the cheapest option subject to hard constraints), which is more than nothing. But there is no explicit when-to-use/when-not statement and no alternative tool is named, even though find_providers and compare_providers overlap heavily with a filtered ranking.

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 readOnly/idempotent/non-destructive, so the safety profile is covered. The description still adds real behavioral context beyond that: the comparison is limited to regular prices (excluding promo pricing), which materially affects what the agent can claim the output means, plus the scope of checked attributes including sourcing checks and shared infrastructure.

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?

Purpose is front-loaded in the first clause, which is good. But the remainder is a single run-on sentence stringing together roughly fifteen comma-separated attributes with no grouping or priority, making it harder to scan than a shorter summary plus a shortlist would be.

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 read-only annotations cover side effects. What remains unstated is edge-case behavior — an unknown/ambiguous provider name, or whether one of the listed comparison dimensions can be missing for some providers — which matters for a 2-4 element input.

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% and the property description already explains that ids, names, websites, and former names (e.g. 'Smartproxy') are accepted. The description's only parameter-adjacent fact, 'two to four providers', is already encoded as minItems=2/maxItems=4, so it adds nothing 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?

Names a specific operation (side-by-side comparison) on a specific resource (2-4 residential proxy providers) and enumerates the dimensions compared, so an agent knows this is the multi-provider comparison tool rather than the single-provider get_provider or the narrower cheapest/shared_infrastructure lookups. It never names those siblings explicitly, so the boundary with 'cheapest' and 'shared_infrastructure' — both of which are partially subsumed here — is left for the agent to infer.

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: the 'two to four providers side by side' phrasing signals the multi-provider comparison case, and the schema's minItems/maxItems reinforce it. There is no explicit when-to-use, when-not-to-use, or pointer to alternatives for a single provider or a cheapest-only question.

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 readOnly, idempotent, non-destructive and closed-world, so safety needs no restating. The description does add real behavioral value: result ordering (regular prices first, lowest first; first-purchase offers and upper bounds flagged afterwards) and per-result provenance (proxyrange.com link plus price-check date). However, it says nothing about empty-result behavior, whether filters are ANDed, or how one-sided filters like maxPriceUsd interact with basketGb.

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 resource and its filter set, which is good. But the single sprawling parenthetical re-lists all seven parameter dimensions already fully documented in the schema, so a meaningful share of the text does not earn its place.

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

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

With an output schema present, the description need not explain return shapes, and it correctly confines itself to scope, ordering, flagging and provenance. For a zero-required-parameter read tool that is close to complete; only the omission of filter-combination semantics and sibling routing keeps it from a 5.

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

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

Schema description coverage is 100% and the schema already explains every parameter, including the enum groupings and units. The description's parenthetical largely restates those same dimensions rather than adding syntax or interaction rules; the one genuinely additive note is that ordering and flagging relate to the 1/10/100 GB baskets. 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 the resource precisely — residential proxy providers filtered by buyer requirements — and enumerates the filter dimensions (targeting, payment, ID check, expiry, price cap, sourcing, minimum purchase, session length). It reads as a noun phrase with no explicit verb ("find") and never distinguishes itself from siblings like compare_providers or cheapest, but the scope is unmistakable.

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

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

No statement of when to use this tool versus the six siblings (cheapest, compare_providers, get_provider, monthly_picks, shared_infrastructure, sourcing_check). An agent must infer from the name alone that this is the filter/search entry point rather than a comparison or lookup tool.

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 readOnly/idempotent/non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: every fact carries the date it was checked and its source, and the review is editorial (best for / think twice if / pros / cons). It does not say what happens when the provider is unknown or ambiguous.

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?

It is one front-loaded sentence with a clear lead-in and no filler, but the long field enumeration is partly redundant with the existing output schema and makes the sentence hard to scan. Trimming the return-value list would strengthen it.

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

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

With an output schema present, the description need not spell out return shape, yet it usefully flags provenance metadata (checked dates, sources) and the sourcing-check verdict scale. The main gap is the absence of sibling routing guidance among six related tools.

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% and the single `provider` parameter already documents id, name, website and former-name forms with examples. The description adds nothing further about the parameter, 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 states precisely what the tool returns for a single residential proxy provider, and the enumerated fact list (prices, expiry, KYC, sourcing check, review) makes the resource unmistakable. It stops short of naming how it differs from siblings like sourcing_check or shared_infrastructure, which surface a subset of the same fields.

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

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

"Everything ProxyRange has on one residential proxy provider" implies a single-provider deep-dive and therefore contrasts implicitly with compare_providers/find_providers, but no when-to-use or when-not condition is ever stated. An agent must infer the routing itself.

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 annotations already establish that this is a read-only, idempotent, non-destructive operation. The description adds useful scope by saying it returns one pick per named need and includes regular 10 GB prices plus market medians, but it does not explain selection methodology or limitations. Since an output schema exists, it does not need to carry the full burden of return-value documentation.

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 one front-loaded sentence that immediately identifies the tool as ProxyRange's monthly picks. It is somewhat dense because of the long parenthetical list of needs, but every clause contributes useful scope.

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

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

For a zero-parameter, read-only tool with an output schema and safety annotations, the description gives enough context to understand what the tool returns. The main gap is that it does not explicitly route the agent away from related siblings when a different kind of provider search or comparison is needed.

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

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

The tool has zero parameters, so the baseline is 4. There are no parameter semantics to clarify, and the description appropriately does not discuss input arguments.

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 a specific resource: curated monthly residential proxy picks, one per need, including prices and medians. It is more specific than the title, but it does not explicitly distinguish itself from siblings such as cheapest or compare_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?

Usage is implied by 'picks for this month, one per need,' suggesting the tool is for curated recommendations rather than raw comparisons. However, it gives no explicit when-to-use guidance or exclusions versus cheapest, compare_providers, find_providers, or sourcing_check.

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 this is a read-only, idempotent, closed-world query, so safety is covered. The description adds genuine interpretive context: an alias gateway routes through the other brand's host, and shared addresses alone are only a technical link that does not establish who runs the network. That caveat directly shapes how an agent should read and trust the result.

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

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

Two sentences, front-loaded with the resource and its definition, followed by the caveat that qualifies the result. The second sentence is dense but earns its place by preventing over-interpretation of shared addresses. Minor cost is the jargon-heavy phrasing.

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. With one optional parameter and a clear statement of what counts as shared infrastructure plus the interpretation caveat, an agent has enough to call it correctly. Explicit sibling routing is the only missing piece.

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 optional parameter already documents that omitting it lists every brand. The description restates the same all-brands behavior without adding format or matching semantics beyond what the schema says. 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 states precisely what is returned: which residential proxy brands share infrastructure, with a parenthetical defining the evidence (same answering addresses or same DNS target). It covers both the single-provider and all-brands scope, so an agent knows the shape of the answer. It does not name a sibling to contrast with, leaving differentiation to inference.

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: 'for one provider or for every brand ProxyRange covers' suggests the optional-parameter pattern but never says when an agent should reach for this tool instead of compare_providers or get_provider. There are no exclusions or prerequisites 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 cover read-only/idempotent/non-destructive, so the description's job is to add semantics — which it does: it enumerates the verdict scale (Clear/Unclear/Concerning), confidence, reasons, evidence items with source quotes, links and timestamps, plus any provider reply. It also explains why the domain matters (residential proxies route through other people's devices).

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

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

Two sentences, front-loaded with the resource and result shape; the trailing sentence provides domain rationale rather than filler. Slightly long-winded in the evidence enumeration but 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?

With an output schema present, the return values don't need re-explaining, and the description covers scope, verdict semantics and rationale. Only the absence of routing guidance versus sibling tools keeps it from 5.

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% and the provider parameter already carries example formats, including former names. The description adds no parameter-level detail, so 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?

Specific verb+resource: a 'sourcing check for one residential proxy provider' that returns a rating with confidence, reasons and evidence. That is clearly distinct from get_provider and compare_providers, though the description never names those siblings to sharpen the boundary.

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 — an agent can infer it's for judging how a provider enrolled its IPs, but there is no explicit 'use this when…' or 'use X instead when…' guidance against the six siblings.

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