localization

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

Annotations already mark the tool as non-read-only, non-idempotent, and non-destructive. The description adds a stateful side effect (configure_country sets country context for subsequent scraping calls), clarifies that it is not a normal page fetch, and discloses the 2-credit cost. This adds useful context beyond the annotations, though it stops short of describing effects of the other operations.

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 compact sentences plus one illustrative example. Purpose is front-loaded, cost and exclusion are included without bloat. The opening clause is slightly run-on, but the overall length and structure are appropriate.

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 description fully supports the configure_country path and excludes ordinary scraping, but the tool exposes eight operations and has no output schema. The other operations such as localize_search, auto_detect, handle_geo_blocking, and get_stats are not mapped to use cases or expected outputs, which is a clear gap for a multi-operation 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 the baseline is 3. The description adds value with a concrete invocation binding operation, countryCode, and language, and explains what configure_country does with those parameters. The rest of the parameters are already well documented in 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?

States concrete use cases: scraping geo-restricted content, emulating a locale/timezone, region-specific pricing, geo-blocks, and localized search. It also distinguishes itself from the 'scrape' sibling with 'Not for an ordinary page read (scrape)' and provides a concrete example so an agent can tell what the tool is for.

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 when-to-use conditions (geo-restricted content, locale/timezone emulation) and an explicit when-not ('Not for an ordinary page read (scrape)'). The example shows exactly how to invoke the primary configuration operation. It does not map out all eight operations, but the tool-vs-alternative decision is clear.

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