ProxyCove

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

Annotations already declare this is a mutation (readOnlyHint=false) that is non-destructive and not open-world, so the safety profile is covered. The description adds useful context about the recovery-login purpose, but omits key behavior for a write tool: whether an existing recovery email is overwritten, whether the change is reversible, and what confirmation is 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?

One sentence, front-loaded with the action and followed by the reason — no filler. It is slightly compressed in the parenthetical aside but every clause carries meaning.

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 mutation with annotations present and no output schema, the description gives adequate purpose but leaves the overwrite/idempotency question and the post-call state unexplained. It is minimally complete, not fully so.

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 is a single required parameter with 100% schema description coverage ('Human's email' with email format), so the schema already does the work. The description adds no format, validation, or uniqueness nuance beyond what the schema states, making the baseline 3 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 states a specific verb and resource ('Attaches an email to the account') and immediately explains the effect ('so the human can log in on proxycove.com via Forgot password'). It is clearly distinguishable from siblings like link_telegram or get_credentials, though it never names an alternative 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 rationale ('never lose the balance') implies when an agent should call it, but there is no explicit when-to-use trigger, no exclusion, and no pointer to a related sibling such as link_telegram for alternate recovery channels. Usage is inferable rather than 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 only declare readOnlyHint=false, destructiveHint=false and openWorldHint=false; the description adds substantially more: that balance is debited (financial side effect), the credential/port topology returned, and a non-obvious ~5 second propagation delay that would otherwise cause wrong-country exits. This is exactly the kind of behavior that cannot be inferred 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?

Three sentences, front-loaded with the action and its cost, then returns, then the two actionable warnings. No filler; every clause carries operational 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 exists, and the description compensates by naming the returned credentials and port semantics. Combined with the timing warning and pricing prerequisite, an agent has everything needed to call and use the result 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 coverage is 100%, so the baseline is 3, but the description adds real meaning beyond it: it ties rotation_interval_minutes to the returned port (824 = rotating, 10000 = sticky) and explains that the country filter propagates asynchronously. It stops short of restating enum values or syntax for type/traffic_gb, which the schema already covers.

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 ('Buys a proxy') plus the key side effect ('deducting the account balance') and what is returned. An agent can distinguish this from sibling extend_proxy or create_topup without opening any 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?

Gives a concrete prerequisite ('Check get_pricing × traffic_gb against the balance first') naming a sibling tool, plus a post-purchase sequencing rule. It does not, however, say when to use extend_proxy instead for topping up an existing proxy, so the alternative-selection guidance is incomplete.

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 only declare the basic write/non-destructive profile; the description adds the crucial behavioral facts that annotations cannot: the key is shown once, there is no password, the key IS the account, it must be set as a Bearer Authorization header, and losing it forfeits the balance without a recovery channel.

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 primary outcome (creates account, returns key), then the conditional warning, then the lifecycle caveats. Every sentence carries an operational instruction with no filler.

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

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

For a no-required-param mutation with no output schema, the description still supplies everything needed: what is returned, how to use it, the irreversibility risk, and the recommended next tools. No material gap remains.

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 both parameters (label, contact_email) are already documented in the schema. The description only indirectly reinforces the email's recovery role via the attach_recovery reference, adding no new parameter-level detail. 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 ('Creates a new account') plus the distinctive outcome ('returns an API key (pc_live_...)') and the differentiator 'WITHOUT registration forms'. An agent can immediately separate this from siblings like get_account or attach_recovery.

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 an explicit when-not rule: do not create a new account if the human already has one, and names the concrete alternatives (website cabinet key, Telegram bot). It also prescribes the likely follow-up actions (attach_recovery, link_telegram) right after creation.

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 a non-read-only, non-destructive, closed-world write. The description adds real beyond-schema behavior: the return value (payment_url), the human-in-the-loop payment flow, and an explicit prohibitive constraint ('Agents must NEVER collect card details'). It stops short of stating auth requirements or whether the invoice expires.

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 action and return value, and every clause (workflow, method list, card-detail prohibition) carries actionable information. The method enumeration is long but earns its length by disambiguating five enum values.

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 exists, and the description supplies the key return value (payment_url) and the surrounding workflow an agent needs to act correctly, while annotations cover the safety profile. Nothing essential is missing for this two-parameter tool.

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

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

Schema coverage is 100%, so baseline is 3, but the description genuinely enriches the method enum beyond the schema's bare 'Payment method' by explaining each value's audience and defaults. amount_usd adds no new info beyond the schema's min/max, so it is not a full 5.

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 ('Creates an invoice') plus the concrete artifact ('returns payment_url'), which clearly separates it from siblings like buy_proxy, create_account, and get_payment_status. An agent knows exactly what side effect to expect.

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

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

Explicitly explains the workflow (hand URL to the human, who pays in the browser) and gives method-selection guidance: sbp default for RU, card_international best for non-RU, crypto_cryptomus as an alternative gateway. It does not name competing sibling tools, but the when-to-use guidance for payment methods is unusually strong.

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

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

Annotations cover the safety profile (non-read-only, non-destructive, non-open-world), so the bar is lower; the description adds genuinely useful context by stating it deducts balance (a financial side effect) and that credentials persist. It stops short of describing failure behavior, e.g. what happens with insufficient balance, so not a 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 compact sentences, front-loaded with the core action and parenthetical qualification. Every clause earns its place with no filler.

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 with annotations and no output schema, the description covers action, scope, and the balance deduction. It could mention limits or failure conditions, but nothing critical to invoking it correctly is 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?

Both parameters (proxy_id, traffic_gb) are fully documented in the schema at 100% coverage, so the baseline is 3. The description adds nothing about the parameter semantics beyond the schema, but it does not need to.

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 (adds) and resource (prepaid GB to an existing proxy), plus the useful reassurance that existing credentials continue to work. It does not explicitly contrast itself with the sibling buy_proxy, which also involves purchasing traffic, 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?

The word 'existing' implies this is for proxies already owned, which nudges an agent away from buy_proxy, but the description never states when to use this versus buy_proxy or attach_recovery. Usage is implied rather than guided.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description usefully discloses the returned fields (USD balance, attached email, active proxy count) in the absence of an output schema, but adds nothing about auth requirements, freshness, or accuracy of the data.

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

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

A single, front-loaded fragment with no filler. It is efficient, though its noun-phrase form costs a little clarity versus an explicit verb.

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 no-param read, annotations cover safety and the description covers the return fields in lieu of an output schema. However, it omits the routing guidance against the many get_* siblings that would make the definition complete.

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

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

The tool takes zero parameters, which is the baseline 4 case. Schema description coverage is 100% but empty, so there is no parameter semantics burden to carry.

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 lists the resource's contents (balance, email, active proxy count) rather than stating a verb+resource, so the tool's action is only implied by the name/title. It does not differentiate this from siblings like get_credentials, get_usage, or get_payment_status, which also retrieve account-scoped data.

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 when-to-use guidance, no prerequisites, and no mention of the alternative sibling tools that return overlapping account data. The agent must guess whether this or get_credentials/get_usage is the right call.

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

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

Annotations declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the exact return format, which is useful, but says nothing about sensitivity of credentials, rate limits, or how proxy_id must be obtained.

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 sentence with no waste, front-loaded with the resource and including the exact output shape.

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 read-only tool with no output schema, the description is nearly complete: it names the resource and the return format. It could be stronger by stating that the connection string is sensitive and should not be exposed.

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%; the proxy_id parameter is documented in the schema as coming from list_proxies. The description adds no parameter detail beyond the one-parameter shape, 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?

The description states the resource (connection string for one proxy) and gives the concrete format. It is reasonably distinct from siblings, but does not explicitly name the proxy_id linkage or differentiate from list_proxies beyond context.

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

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

Usage is implied: call this to obtain a connection string for a single proxy. There is no explicit when/when-not guidance, no prerequisites, and no alternative named.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral value the annotations don't: the finite set of possible results and the polling pattern after human action.

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

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

Two short sentences, enum values front-loaded and the polling cue second. No waste; slightly telegraphic but every clause carries 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?

With no output schema, the description usefully names the possible statuses, which is the key return information. Combined with the single fully-documented parameter and readOnly annotations, an agent has what it needs to call the tool correctly.

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

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

Single parameter with 100% schema coverage, and the schema already says the invoice_id comes from create_topup. The description adds no format or sourcing detail beyond that, so the 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?

States a specific resource (invoice) and enumerates the exact return values (pending | paid | cancelled), which is far more than a tautology. It doesn't differentiate from siblings like create_topup or get_pricing, but the invoice-status 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?

"Poll after the human opens the payment link" gives a concrete trigger condition and implies the correct ordering relative to create_topup. It stops short of stating when NOT to call (e.g., before link creation) or a polling interval, so it misses the top tier.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description usefully adds what the payload contains (USD, per-GB, three proxy tiers), but says nothing about whether rates are static or current.

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?

One short fragment, front-loaded with the key fact (unit, currency, resource) and no filler. Slightly telegraphic but nothing wasted.

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-param lookup with no output schema, the description adequately communicates return content. It could note currency refreshing or that results cover all offered tiers, but it is sufficient to call 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?

Zero parameters, so the baseline is 4; there is nothing for the description to disambiguate, and schema coverage is 100%.

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 resource and scope: per-GB USD prices for three proxy categories. An agent can distinguish it from get_usage and buy_proxy, 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?

No when-to-use guidance, no mention of alternatives like buy_proxy or get_usage, and no statement that it takes no arguments. Usage is only inferable from the name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds 'live' freshness and 'used/remaining' content, but omits units, rate limits, and authentication requirements.

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?

One compact phrase with zero waste, front-loading the metric. It is a sentence fragment rather than a full sentence, but there is no padding.

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

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

For a simple read operation with one documented parameter and annotations covering the safety profile, the description conveys the return concept adequately. No output schema is needed, though a hint about return format would be a minor improvement.

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 proxy_id parameter is documented. The description's 'for one proxy' aligns with the schema but adds no syntax, format, or validation detail beyond it.

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

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

States the resource and scope (traffic for one proxy) and the metric (used/remaining), so an agent knows what it returns. However, it does not name a retrieval verb or differentiate from siblings like get_account or list_proxies.

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

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

No indication of when to prefer this over list_proxies or get_account, nor prerequisites such as proxy ownership. Usage is only implied by the tool name and the phrase 'for one proxy'.

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 only declare the safe non-destructive profile; the description adds genuinely non-obvious behavior: the tool returns a code consumed by a human outside the API, the code expires in 30 minutes, and the linking happens through a specific bot menu path. That expiry and human-in-the-loop requirement are exactly the kind of context annotations cannot carry.

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 return value and then the follow-on workflow. The embedded UI path '(@ProxyCove_bot → "Link website account")' is slightly noisy but is doing real work in telling the human where to paste the code.

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 no output schema, the description carries the full burden of describing the return value and it does so (a short code), plus its validity window. Combined with the zero-parameter schema, an agent has everything needed to call this correctly and explain the result to the user.

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 and the baseline of 4 applies. The description correctly spends no words on parameter syntax.

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+resource (linking the website account to the Telegram bot) and precisely what the tool returns: a short code the human relays to @ProxyCove_bot. It is unmistakably distinct in form from the getter/purchase siblings, though it never contrasts itself with the similarly recovery-flavored attach_recovery, which is the one sibling an agent might confuse it with.

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 context is clear: this is offered as a 'second way to keep access if the API key is lost,' and the follow-on flow (manage account, issue new API keys from the bot) is spelled out. There is no explicit when-not-to-use guidance or named alternative, so it stops short of a 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 and openWorldHint=false, so safety is covered. The description adds that results are filtered by proxy type, which is mildly useful, but says nothing about coverage limits or why the list might differ by type.

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 short sentence with no filler, front-loading the resource. It is a fragment rather than a full statement, which slightly weakens clarity.

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

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

For a one-parameter read-only list tool with full schema coverage and annotations, the essentials are present. It omits any hint of return shape or how the list is ordered or paginated, which leaves gaps for an agent planning a call.

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 'type' parameter has an enum with three values plus a description, so the schema does the work. The description restates the dependency on type without adding format or behavior detail beyond it.

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

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

States a specific resource (countries) scoped to a proxy type, so the verb-less fragment still conveys what is returned. It does not name or distinguish itself from any sibling, which keeps it below 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 statement of when to use this tool versus alternatives, nor any prerequisite such as needing an existing proxy. The phrase 'for the given proxy type' implies the input is a type, but not when an agent should reach for this list.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description does contribute return-side context by disclosing that results include remaining traffic and connection credentials — useful since there is no output schema. It stops short of noting credential sensitivity, pagination, or result size.

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 short sentence with no filler, and the scope ('of the account') leads. It reads as a fragment rather than a full sentence, which is a minor structural weakness but does not impede comprehension.

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, the annotations cover safety and the description covers the payload (proxies, remaining traffic, credentials). With no output schema present, it would help to know whether credentials are returned in plaintext or whether the list is paginated, but nothing essential for correct invocation is 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?

The tool takes zero parameters, and the schema confirms an empty properties object at 100% coverage, so the baseline of 4 applies. The description adds no parameter detail because there is none to add.

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 and scope ('All proxies of the account') and even characterizes what comes back ('remaining traffic and connection credentials'), so an agent knows this is a retrieval of the account's proxy inventory rather than a purchase (buy_proxy) or extension (extend_proxy). It is a noun phrase with no explicit verb, but 'All proxies of the account' is unambiguous as a listing operation.

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

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

There is no guidance on when to call this versus alternatives such as get_credentials (which overlaps with the 'connection credentials' mentioned here) or buy_proxy/extend_proxy. No preconditions, no exclusions, no routing cues; the agent must infer usage entirely from the tool name.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false, but the description adds no behavioral context beyond the mode switch itself. It doesn't say whether the change is persistent, whether it disrupts active connections, or whether it requires re-authentication. For a mutation tool, this is thin.

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?

One focused sentence that front-loads the core action and both mode/port pairs without redundancy.

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

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

For a two-parameter mutation tool with no output schema, the description lacks operational context such as persistence, connection impact, and required proxy state. It is minimally adequate but leaves an agent guessing about side effects.

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 both parameters fully. The description's mention of the two modes and ports loosely maps to interval_minutes, but adds no syntax beyond what the schema provides. 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?

States a specific action (switch between rotation modes) and the resource (IP rotation), with the two modes and their ports named. It doesn't differentiate from the 12 siblings, but the operation is unique enough that confusion is unlikely.

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 rotate-every-request vs sticky, and no prerequisites (e.g., that the proxy must not be in use or that the change takes effect immediately). The agent must infer usage purely from the mode names.

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