Russian Web Data Access for AI Agents

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

No annotations are provided; the description does not disclose whether the operation is read-only, what side effects exist, or any authorization requirements. The agent needs this info for safe usage.

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

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

The description is very concise (single phrase). While it is clear and front-loaded, it omits important details, so conciseness comes at the cost of completeness.

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

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

Given the tool's simplicity (one parameter, no output schema), the description is borderline adequate. It covers purpose and return unit but lacks behavioral and error handling context.

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

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

Schema description coverage is 0%, and the description only adds meaning to the return value (minor units) but does not explain the agent_id parameter, such as its format or expected values.

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

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

The description clearly states the action ('Get'), the resource ('agent balance'), and the unit ('minor units (kopecks)'). It is specific and distinguishes from sibling tools like topup_balance.

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

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

No guidance on when to use this tool vs alternatives (e.g., topup_balance). The description does not mention prerequisites or context in which the tool should be invoked.

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

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

No annotations provided, so description carries burden. It mentions 'Free, no balance needed' indicating no financial impact, but does not disclose whether it's read-only, network-dependent, or return format.

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

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

Single sentence, no wasted words, front-loaded with verb and resource.

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

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

For a simple tool with 1 parameter and no output schema, it gives essential purpose and cost, but lacks explanation of return values or additional behaviors, leaving some gaps for an agent.

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

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

Schema coverage is 0%, so description must compensate. It adds context that 'domain' is checked for availability with specific TLDs, but does not specify format or validation rules.

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

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

The description clearly states the verb 'Check' and resource 'domain availability', and specifies supported TLDs (.com/.ru/.рф). It distinguishes from siblings like register_ru_domain which registers a domain.

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

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

Explicitly states it's free and requires no balance, indicating when to use without cost. However, it lacks explicit exclusions or comparisons to siblings like check_balance.

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

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

No annotations provided, so description carries full burden. It discloses that the tool uses a Russian IP and supports residential IP for antibot, but does not mention error handling, rate limits, or side effects.

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

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

The description is a single sentence with a list followed by a clarifying statement. It is relatively concise and front-loads the key specialization, though it could be slightly more structured.

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

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

Given 3 parameters, no output schema, and no annotations, the description covers the main purpose and one parameter but omits the role of agent_id, return format, and error behavior. It is adequate but not fully complete.

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

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

Schema description coverage is 0%, requiring description to explain parameters. Only the residential parameter is explained ('for hard antibot'). The url and agent_id parameters receive no additional context.

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

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

The description clearly states it's a Russia specialization of fetch_web using a Russian IP, listing specific target sites. It effectively distinguishes from siblings like fetch_web and get_ru_proxy by specifying the geographic scope.

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

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

The description indicates when to use this tool (for Russian sites needing Russian IP) and mentions the residential option for hard antibot. However, it does not explicitly exclude use cases or compare to siblings like get_ru_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?

Discloses key behaviors: fetches via chosen country IP, charges from agent balance, returns payment_required on insufficient funds. No annotations provided, so description carries burden. Missing details on timeouts, error types beyond payment, and HTTP method used.

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?

Five sentences, front-loaded with main action. Each sentence adds value. Slightly dense but no wasted words. Could benefit from bullet points for readability.

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, so description should cover return details. Mentions returning content (HTML/JSON) and payment_required, but does not specify structure, headers, or other possible responses. Adequate for typical use but leaves some uncertainty.

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

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

With 0% schema description coverage, the description adds meaning for country (e.g., 'ru' unlocks Russia-only sites) and residential (blocks datacenter IPs). Does not explain agent_id or url beyond implicit understanding, but defaults are in schema.

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

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

Clearly states the tool fetches content from any URL via a country-specific IP. Identifies itself as flagship tool and distinguishes from siblings like fetch_ru by implying broader scope.

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

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

Provides specific scenarios: unlocking Russia-only sites with country='ru', using residential=true for sites blocking datacenter IPs. Mentions balance charging and payment_required error flow. Lacks explicit when-not-to-use vs alternative tools.

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

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

With no annotations, the description carries full burden. It discloses that the tool is charged from agent balance, returns payment_required on insufficient funds, and is idempotent per agent. This covers key behavioral aspects for a paid proxy tool.

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

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

Two sentences, front-loaded with clear purpose. Every sentence adds value: purpose, use case, charge mechanism, error handling, idempotency. No wasted words.

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

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

Covers purpose, cost, error handling, and idempotency. Missing explanation of return format and detailed parameter meanings, but overall sufficient given tool simplicity and lack of output schema.

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

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

Schema coverage is 0%, meaning parameter descriptions are absent. The tool description does not explain the meaning of 'count' or 'period_days' beyond defaults, leaving the agent to infer. This is insufficient compensation for lack of schema descriptions.

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

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

Description clearly states the tool's purpose: 'Get a Russian IP proxy to access RU-only sites', with specific examples like Wildberries, Ozon, gov registries, and banks. It distinguishes from siblings such as fetch_ru and fetch_web by focusing on proxy acquisition rather than content fetching.

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

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

Provides clear usage context: accessing sites that block foreign IPs. Also includes an error handling instruction: if payment_required, call topup_balance and retry. However, it lacks explicit alternatives or when-not-to-use guidance.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the service is charged from balance, but fails to mention other behavioral details such as idempotency guarantees (implied by idempotency_key), domain validation, or side effects like deduction from balance.

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

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

The description is extremely concise at 8 words, front-loading the main action. However, it lacks structured formatting (e.g., bullet points) and could be reorganized for easier scanning while remaining concise.

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

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

For a registration tool with 3 required parameters and no output schema, the description is insufficient. It omits error scenarios (e.g., insufficient balance, invalid domain, domain already registered), success response format, and any post-processing steps. It is incomplete for a financial transaction involving multiple inputs.

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%, meaning the description adds no information beyond the schema. The parameters domain, agent_id, and idempotency_key are not explained. The description could define domain format, agent_id purpose, or the role of idempotency_key in preventing duplicate charges.

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

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

The description clearly states the action 'Register' and the resource '.ru/.рф domain', distinguishing it from sibling tools like check_domain (checking availability) and topup_balance (topping up). The mention of '(secondary service)' adds 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?

The description implicitly suggests usage via 'Charged from balance' but does not explicitly state when to use vs when not, nor does it mention prerequisites like checking domain availability or having sufficient balance. No alternatives are given.

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

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

No annotations are present, so the description carries full burden. It discloses that the tool returns a pay_url and mentions two payment rails, but lacks details on side effects, authorization needs, 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?

The description is very concise with two sentences, no fluff. However, it could be slightly expanded to cover key parameters while remaining efficient.

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

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

Given the complexity of a payment operation with 4 parameters and no output schema, the description is incomplete. It omits parameter details, error conditions, and idempotency considerations.

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

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

Schema coverage is 0%, and the description only explains the 'rail' parameter minimally. It does not describe agent_id, amount_minor, or email, leaving significant gaps in parameter understanding.

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 'Top up agent balance' with specific verb and resource, and distinguishes from siblings like check_balance by mentioning payment rails and returning a pay_url.

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

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

The description implies usage for topping up agent balance with choices of rail, but does not explicitly state when to use versus alternatives or provide guidance on prerequisites or context.

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