cloro

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds the useful behavioral detail that engines can block certain countries, which explains why results vary by model — value beyond annotations but modest in scope.

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 what the tool returns and followed by the conditional-parameter guidance. No redundancy or 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 simple read-only lookup with full schema coverage and an output schema handling return values, the description is essentially complete. The engine-blocking caveat is the one piece of non-obvious context an agent needs, and it is present.

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 sole parameter has an enum, so the schema fully documents the model input. The description adds the semantic rationale (engine-specific country blocking) but no format or syntax detail 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 verb (List) and resource (ISO 3166-1 alpha-2 country codes for geo-targeting), which is concrete and distinguishable from siblings like list_states and the scrape_* tools. An agent immediately knows this is a reference/lookup tool returning country codes, not a scraping tool.

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 describes the conditional use of the optional model parameter ('Pass a model to get the codes available for that specific engine'), which is the key usage decision here. It doesn't name explicit alternatives or when-not-to-use, but the single-parameter design leaves little ambiguity.

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 a read-only, idempotent, non-destructive, closed-world lookup, so the safety profile is fully covered. The description adds only the acceptance constraint, which is also echoed in the schema, so marginal extra value.

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, front-loaded with the core action and followed by the usage tie-in and constraint. 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?

An output schema exists so return values need not be described, and the single parameter and its constraint are covered. Complete for a simple lookup, though the sibling alternative could be named explicitly.

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 'country' param is fully documented with its enum and constraint, so the schema carries the load. The description adds the purpose link (the collected value feeds the scrape tools' 'state' param) but no syntax 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?

States a specific verb (list) and resource (state codes) with the precise purpose: state-level geo-targeting. It is clearly distinguishable from the sibling list_countries and the scrape_* tools.

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?

Explains the downstream use (the returned codes feed the 'state' parameter on the scrape tools) and notes the input constraint that only state-level-targeting countries are accepted. It stops short of explicitly naming list_countries as the alternative for unsupported countries.

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 safe read-only nature, so the description adds useful behavioral context beyond them: the tool geo-targets from a country/US state and returns cited sources, including brand mentions. This clarifies what the agent should expect from the response without contradicting the annotations.

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 two concise sentences, front-loaded with the core action and purpose. Every clause adds useful information: what it does, how it geo-targets, what the output contains, and why you would use it. There is zero 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?

Given no output schema, the description does a good job of mentioning the main return value ('answer with cited sources'). It also implies the response will reflect brand/source mentions. It doesn't describe the exact response structure, but the parameter schema covers the request side and the annotations clarify safety, so the overall picture is fairly 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 100% and each parameter is already well-documented, including the nested 'include' object. The description does not add significant meaning beyond the schema — the only additional hint is 'optionally US state', which the schema already states. 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?

The description opens with a specific action ('Submit a prompt to Microsoft Copilot'), targets a clear resource, and explains the output ('answer with cited sources'). It also distinguishes this tool from sibling scraping tools by naming the model and the unique value of seeing which brands/sources Copilot mentions.

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 explicitly states the intended use case: 'Use this to see how Microsoft Copilot answers a prompt...' This tells the agent when to choose this tool. It does not explicitly discuss alternatives or exclusion criteria, but the sibling tool names (scrape_chatgpt, scrape_gemini, etc.) make the choice obvious.

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 read-only, open-world, and non-destructive behavior. The description adds useful context about geo-targeting and cited-sources output, but it does not disclose operational details such as response format variety or potential limitations. This modest addition beyond annotations supports a 3.

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 two concise sentences that front-load the core action and result before adding the use case. It contains no filler, no repetition of schema details, and every sentence 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?

The schema fully documents all input parameters and the nested include flags, while annotations cover the safety profile. The description supplies the missing output clue (answer with cited sources, brands) and a concrete use case, making selection and invocation reasonably clear despite the absence of an 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?

The input schema has 100% parameter description coverage, including prompt, country, state, and the nested include object. The description only loosely echoes the schema ('chosen country', 'optionally US state') without adding new syntactic or semantic detail, 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?

The description states a specific verb and resource: 'Submit a prompt to Google Gemini' from a chosen country and return the answer with cited sources. It names the model explicitly and focuses on brands/sources, which differentiates it clearly from sibling scrapers like scrape_chatgpt and scrape_perplexity.

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 second sentence gives a clear intended use case: 'see how Google Gemini answers a prompt and which brands/sources it mentions.' This provides enough contextual guidance for an agent to know when to choose this tool, though it does not explicitly mention when not to use it or name alternatives.

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 provide readOnlyHint=true and destructiveHint=false, and the description adds useful behavioral context beyond those: two request modes, optional AI Overview/PAA extraction, device emulation, and multi-page fetching. It does not contradict the annotations.

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 tight, front-loaded sentences cover the core action, optional features, modes, device support, and pagination with no redundancy. Every sentence 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?

The tool has 10 parameters, a nested include object, and no output schema, so the description could usefully describe the expected response shape or caveats around AI Overview availability. It covers modes and capabilities well, but leaves return-format details and failure/availability notes unstated, which is a meaningful gap at this complexity level.

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 a baseline of 3 applies. The description adds mode-level semantics by explaining that URL mode 'owns' query, location, and pagination, and by surfacing include.aioverview and include.paaAioverview as optional extracts. This is genuine value beyond the per-field 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 states a specific action ('Run a Google search ... return organic results') and clearly identifies the resource and scope. It mentions optional AI Overview and People-Also-Ask extraction, which helps set it apart from other search tools, though it does not explicitly name sibling tools.

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 explains the two internal modes (structured vs. URL) and gives some context for choosing between themhol, but it never guides the agent on when to use this tool versus sibling tools like scrape_google_news or scrape_google_ai_mode. No alternatives or exclusion conditions are mentioned.

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, and destructiveHint=false, covering safety expectations. The description adds useful behavioral context beyond annotations by stating that requests can be geo-targeted, support location/UULE targeting, and emulate desktop/mobile, and that the response contains an AI answer with cited sources. No contradiction with annotations.

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 main description is a single dense sentence that front-loads the core action, target, and key capabilities without any fluff. Every clause adds value: the prompt submission, country selection, cited sources, and targeting/emulation options.

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 an 8-parameter tool with a nested include object and no output schema, the description plus the detailed schema provides enough context to invoke the tool correctly. It states the return shape ('AI answer with cited sources') and points to list_countries for valid codes. It remains slightly thin on response structure and edge-case behavior, but the annotations and schema compensate.

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% with generally strong parameter descriptions, so a baseline of 3 would normally apply. However, the include property description lists 'rawResponse' which is not present in the schema's include properties, while failing to mention 'expandProducts'. This inaccuracy can mislead an agent into setting a nonexistent flag, significantly undermining parameter semantic quality.

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 uses a specific verb phrase, 'Submit a prompt to Google AI Mode', and names the exact resource, distinguishing it from generic Google search and sibling AI scrapers like scrape_gemini or scrape_chatgpt. The mention of 'AI answer with cited sources' further clarifies that this is the AI Mode endpoint, not a standard search tool.

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 provides clear context for when to use the tool: when an agent needs Google AI Mode results rather than regular Google results or another AI assistant. It also adds targeting and emulation context. However, it does not explicitly name alternatives or say when not to use this tool, so it does not fully earn 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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful operational context (device emulation options and multi-page fetching), but does not mention rate limits, anti-bot behavior, or response shape for a scraper.

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 tightly written sentences with no wasted words. The primary action and its notable capabilities are front-loaded, making the definition easy to scan.

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 rich input schema and annotations carry most of the load, so the description does not need to repeat parameter details. However, with no output schema, the description only vaguely promises "news results" and omits return structure, pagination aggregation, or scraping cost/rate-limit 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 100%, so every parameter is already documented in detail, including deprecation notes for country and enum values for device. The description loosely maps to a few parameters (country, device, pages) but adds no syntax or format meaning 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?

States a specific verb and resource ("Run a Google News search") and names the field of results ("news results"). The name and description distinguish it from generic scrapers like scrape_google, but it never explicitly contrasts itself with sibling tools such as scrape_google or scrape_google_ai_mode.

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 says what the tool does but gives no guidance on when to choose it over scrape_google, scrape_google_ai_mode, or the other scraper siblings. It also omits any exclusions or prerequisites, leaving selection entirely 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 destructiveHint=false, so the tool is a safe read operation. The description adds that the request is geo-targeted from a chosen country/state and returns cited sources, which is useful context beyond annotations. It does not disclose rate limits, cost considerations, or that responses are external AI answers, but given annotation coverage, this is adequate.

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 two sentences long with no waste, front-loading the core action and result. It packs the scope (chosen country/state, cited sources) and the usage motive (see brands/sources) efficiently. Slight deduction for not mentioning the includes or state/country dependency in the main description, but the schema covers 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?

The tool has 4 parameters but only 2 required, and the schema provides rich descriptions for all parameters including 'include' flags and state/country codes. The output schema does not exist, but the description states the return value (answer with cited sources). However, the description does not explain that the response might be large with include flags or that list_countries/list_states are needed for valid values, though these are in the schema. Overall, information is sufficient for an agent to call correctly, with minor gaps.

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 documents all parameters. The description adds the purpose of the country/state targeting (geo-targeting) and the cited-sources context, but it does not add much beyond schema descriptions. The description in the schema for 'include' already explains the flags, so the main description adds minimal extra parameter semantics.

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 specific verb (Submit), resource (prompt to Grok), and the key scoping feature (from a chosen country/state), and explicitly mentions returning answers with cited sources. It also differentiates from siblings by naming Grok explicitly and describing what it adds (cited sources/brands), distinguishing it from scrape_chatgpt, scrape_gemini, etc.

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 tells when to use the tool: to see how Grok answers a prompt and which brands/sources it mentions. It also implicitly routes to list_states and list_countries for valid codes, which provides context for prerequisites. However, it does not explicitly state when to prefer this over sibling tools (e.g., versus scrape_chatgpt), leaving some inference to the agent based on 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 already cover readOnlyHint, openWorldHint, and destructiveHint, so the description only needed to add behavioral detail. It does: it discloses that the tool submits a live prompt, geo-targets by country/state, and returns the answer plus cited sources. This is meaningful beyond annotation hints, though it doesn't mention cost, latency, or rate limits.

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 action and result, and the second sentence adds practical use-case value. No filler or redundant detail.

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 tool with no output schema, the description gives a reasonable contract: input prompt plus geo-target, output answer with cited sources. The schema fills in state/inclusion prerequisites (list_states/list_countries, include flags). It is slightly short on return-structure detail, but not enough to make it incomplete 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 description coverage is 100%, and the description restates country/state only at a high level. It adds no parameter semantics beyond the schema; the detailed include flags are fully documented in the schema. Therefore the baseline score of 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?

The description uses a specific verb ('Submit a prompt to Perplexity'), names the exact resource, and states the geo-targeting behavior and return value ('answer with cited sources'). The second sentence ('Use this to see how Perplexity answers...') reinforces what makes it distinct from sibling scraper tools, so an agent can tell it apart from scrape_chatgpt or scrape_gemini.

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 provides clear usage context: use this when you need Perplexity's answer and which brands/sources it mentions. It does not explicitly name alternatives or when-not conditions, but the Perplexity-specific framing plus sibling tool names is enough direction.

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