cloro

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

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds useful behavioral context not captured in annotations: some engines block certain countries, which explains why results may vary by model. This context supplements the structured annotations well.

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, front-loads the core purpose, and devotes the second sentence to the only optional nuance. There is 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 zero-required-parameter read-only listing tool with an enum-only optional filter, the description covers purpose, the optional filter's effect, and behavioral nuance. No output schema is provided, but the description already states that the output is ISO 3166-1 alpha-2 country codes, so the context is sufficiently 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 input schema already provides full coverage with a clear description for the model parameter and an enum of valid values. The description adds value by explaining why the parameter matters — filtering by engine-specific country support and warning that some engines block certain countries.

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 'List' and the specific resource: 'ISO 3166-1 alpha-2 country codes supported for geo-targeting.' This makes the tool's purpose distinct from the sibling list_states and the various 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?

The description explains the main use case — retrieving countries for geo-targeting — and provides clear guidance for the optional model parameter: pass a model to get engine-specific availability. It does not explicitly name alternatives or state when not to use this tool, so it falls just 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 cover the safety profile: readOnlyHint, idempotent, and non-destructive. The description adds that only state-targeting countries are accepted and that output plugs into scrape tools, but it does not describe result format, pagination, or other behavioral details. Given the annotations, this is acceptable but not outstanding.

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 core action and resource, and a second sentence for the limitation. No redundant or filler text.

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 single-parameter listing tool, the description covers purpose, the main constraint, and the connection to sibling scrape tools. It does not spell out the exact return shape, but the phrase 'List the state codes' sufficiently implies an array of code values. The absence of an output schema makes this a minor gap only.

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?

Input schema coverage is 100% and the only parameter, country, already has a clear description and enum. The tool description adds context about how the result is used, but it does not add new parameter-level semantics beyond the schema. Baseline 3 applies because the schema carries the load.

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 a specific action and resource: listing state codes for country-level geo-targeting, and explicitly connects to the 'state' parameter used by scrape tools. It distinguishes itself from siblings like list_countries and scrape_* tools by specifying exactly what it returns and why.

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 when to use this tool: when you need valid state codes for a country before calling a scrape tool. It also states a constraint (only countries with state-level targeting are accepted). It does not explicitly name alternatives or exclude cases, but the context is clear enough.

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 the tool read-only and non-destructive. The description adds behavioral detail beyond that: it geo-targets from a country/state, returns the full answer with cited sources, and can include markdown, search queries, shopping, and ads depending on flags. It does not mention quotas/rate limits, but the safety profile is covered.

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 with no filler: the first states the action and output payload, the second states the practical use case. It is compact, front-loaded, 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?

For a tool with six parameters and no output schema, the description is largely sufficient: it names the core inputs (prompt, country, optional state) and the key return fields (text, cited sources, optional extras). It could explicitly mention the disableWebSearch option or route to list_countries/list_states, but those are documented in the schema and sibling names.

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 83%, so the schema already documents most parameters well. The description restates the general prompt/country/state concept and optional output flags, but adds little beyond the schema's own field descriptions. 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 specifies the exact verb and resource: submit a prompt to ChatGPT and return the answer text plus cited sources, with optional extras. The use case ('see how ChatGPT answers... which brands/sources it mentions') clearly distinguishes it from sibling scrapers for other engines.

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 gives a clear context for use: checking ChatGPT's answer, source mentions, and brand/source inclusion. It does not explicitly name alternative tools or state when not to use it, but the ChatGPT-specific purpose is enough to route an agent toward it.

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 mark it read-only and non-destructive; the description adds meaningful behavioral detail: it emulates different devices, supports multi-page results, geo-targets via country/gl, and discloses that URL mode overrides structured fields. There is no contradiction with 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 compact and front-loaded with the core action, followed by mode selection, device support, and optional features. Every sentence contributes useful information 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?

Given the tool's complexity — 10 parameters, nested include objects, multiple modes, and no output schema — the description covers invocation well. It lacks explicit output-structure details beyond "organic results," but the essential selection and calling context 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 description coverage is 100%, so the baseline is 3. The description adds value by explicitly tying include.aioverview and include.paaAioverview to their extraction behavior and by summarizing the structured vs. URL ownership semantics, which helps the agent understand parameter interactions 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?

The description names a specific verb and resource: "Run a Google search" that "return[s] organic results." It clearly separates itself from siblings like scrape_google_news and scrape_google_ai_mode by focusing on standard Google organic results with optional AI Overview extraction.

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 gives explicit guidance on choosing between the two invocation modes — structured query/country vs. a full URL — and explains when the URL owns query, location, and pagination. It does not explicitly compare against sibling tools, but the mode-selection guidance is clear enough for correct invocation.

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?

Beyond the readOnly/openWorld annotations, the description adds meaningful behavioral context: it returns the AI answer with cited sources and supports country/location targeting and desktop/mobile emulation. It does not detail response structure or rate limits, but the core behavior is disclosed.

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 with the main action front-loaded and no wasted words. It conveys purpose, return value, and key options without restating schema details.

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 8 parameters and no output schema, the description gives the essential behavioral promise — AI answer with cited sources — and the main targeting/emulation options. It could be more explicit about the optional include flags, but the schema covers those details.

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 the schema fully documents each parameter. The description adds no new per-parameter meaning beyond summarizing location/UULE and device emulation, which are already 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?

The description uses a specific verb and resource: 'Submit a prompt to Google AI Mode... and return the AI answer with cited sources.' This clearly identifies what the tool does and distinguishes it from sibling tools like scrape_google 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?

The description conveys the tool's intended use by naming Google AI Mode and its key capabilities, such as location/UULE targeting and device emulation. However, it does not explicitly state when to choose this tool over alternatives or when not to use it.

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 mark the operation as read-only and non-destructive, so the safety burden is covered. The description adds meaningful behavioral context by disclosing device emulation (desktop/mobile/iOS/Android) and multi-page result fetching, which an agent cannot infer from 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?

Two tight sentences with no filler: the core action leads, followed by the two most relevant capability expansions (device emulation, pagination). Every sentence adds 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 seven parameters, a nested include object, and no output schema, the description should tell an agent what a response looks like; 'return news results' is vague. The schema covers parameters and annotations cover safety, so the main remaining gap is the unspecified result shape and any pagination/rate-limit caveats.

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 the schema already documents all seven parameters thoroughly, making the baseline 3. The tool description itself adds little parameter meaning beyond 'chosen country', but it doesn't need to because the schema carries the burden.

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 verb ('Run a Google News search'), a concrete resource, and the result type ('return news results'), which clearly distinguishes it from siblings like scrape_google and scrape_google_ai_mode. It also adds useful scope ('from a chosen country') and capabilities.

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 this is the tool to use for Google News searches, but it never explicitly contrasts it with the sibling scrape_google or states when not to use it. There is no mention of alternatives or exclusion criteria, so the usage guidance is only inferred from the tool's purpose.

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.