Scrape AI answer engines and Google Search/News with country and state-level geo-targeting.
Scored across 10 tools
Each scrape_* tool targets a clearly distinct engine (ChatGPT, Copilot, Gemini, Google Search, Google AI Mode, Google News, Perplexity), and the three Google variants are differentiated by explicit description cues (organic results vs. AI answer vs. news). The two list_* helpers and resolve_google_redirect each serve a unique supporting role with no overlap.
All tools use consistent snake_case verb_noun or verb_object_pattern: list_countries, list_states, resolve_google_redirect, and a uniform scrape_<engine> family. The scrape_google_* variants extend the same prefix predictably.
Ten tools is well within the ideal range and each one earns its place: seven engines/pipelines plus three small supporting utilities. Nothing appears redundant or padded.
The surface covers the core workflow well: geo-targeting metadata, multiple AI-answer engines, Google search/news/AI-mode, and redirect resolution for dead links. Minor gaps exist — no tool to check credit balance or account usage, and no engine/model enumeration despite descriptions referencing per-engine country availability.
List the ISO 3166-1 alpha-2 country codes supported for geo-targeting. Pass a model to get the codes available for that specific engine (some engines block certain countries).
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Optionally filter to countries supported by a specific engine. |
| Name | Required | Description |
|---|---|---|
| countries | Yes | ISO 3166-1 alpha-2 country codes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds genuinely new behavioral context — that per-engine country support differs and some engines block certain countries — which an agent would not infer from annotations or schema. No mention of result shape, but an output schema exists, so that burden is not on the description.
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, zero filler, with the scope (geo-targeting country codes) front-loaded before the optional-parameter guidance. 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?
Single optional enum parameter, full schema coverage, output schema present, and all four annotation hints supplied. The description adds the one non-obvious semantic (per-engine variation), so nothing an agent needs to invoke this 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?
Schema coverage is 100% and the enum is self-documenting, so the baseline is 3. The description adds value beyond the schema by explaining why the parameter matters — the returned set can differ per engine — rather than just restating "optionally filter by engine".
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 ("List the ISO 3166-1 alpha-2 country codes") plus the scoping purpose ("supported for geo-targeting"), which distinguishes it from the sibling scrape_* tools and from list_states. An agent knows exactly what it gets back without opening the 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?
"Pass a model to get the codes available for that specific engine" gives explicit conditional guidance on the optional parameter, including the motivation (engines block certain countries). It does not name a sibling alternative or state when not to use it, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the state codes available for state-level geo-targeting in a country (used as the "state" parameter on the scrape tools). Only countries with state-level targeting are accepted.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | ISO 3166-1 alpha-2 country code to list states for. Only countries with state-level targeting are supported. |
| Name | Required | Description |
|---|---|---|
| states | Yes | States available for state-level targeting. |
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.
Resolve one Google redirect link to its destination URL. Use it when a link or url field from scrape_google, scrape_google_news or scrape_google_ai_mode is empty, missing, or a google.com/goto URL: pass that result's redirectLink. Returns { url }. A link that does not resolve returns a 502; retry it later. Costs 1 credit, with no sync surcharge, and only when the destination is returned.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The redirectLink value: an absolute https://www.google.com/goto?url=... or https://www.google.com/url?... link. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only and open-world annotations, the description discloses the return shape ({ url }), the 502 failure behavior with retry guidance, and the credit cost including when it is charged. This is substantial behavioral context that annotations alone do not provide.
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 front-loaded with purpose and usage, then adds return, error, and cost details in a compact sequence. Every sentence contributes operational information without waste.
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?
Although there is no output schema, the description states the return shape and covers failure behavior, retry guidance, and cost. Combined with the annotations and fully documented parameter schema, an agent has everything needed to call it 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%, and the single url parameter is already well documented in the schema. The description adds useful context by saying to pass the source result's redirectLink, but it does not add format or syntax details beyond what the schema already provides.
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: resolve one Google redirect link to its destination URL. It also names the exact source tools whose redirectLink values should be passed, making it clearly distinguishable from the scraping siblings.
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 gives an explicit trigger: use when a link or url field from scrape_google, scrape_google_news, or scrape_google_ai_mode is empty, missing, or a google.com/goto URL. It also tells the agent exactly which value to pass, leaving little ambiguity about when and how to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a prompt to ChatGPT from a chosen country (and optionally US state) and return the full answer: text, cited sources, and optionally markdown, search queries, shopping results, and ads. Use this to see how ChatGPT answers a prompt and which brands/sources it mentions. Costs 7 credits (5 base + 2 sync surcharge); any of include.rawResponse, searchQueries, ads or shopping adds 2 once; include.productDetails adds 2 more; each prompt after the first adds 1; a state adds 2.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Optional state code for state-level targeting (e.g. "CA" when country is "US"). Only some countries support this — call list_states for the supported countries and their codes. | |
| legacy | No | Serve ChatGPT's desktop UI instead of the default mobile-web UI. Defaults to false. | |
| prompt | Yes | The prompt to submit to ChatGPT, or an array of up to 5 prompts asked in order as follow-ups in the same conversation (1 extra credit per prompt after the first). An array returns an array of results, one per prompt. | |
| country | Yes | ISO 3166-1 alpha-2 country code to geo-target the request from (e.g. "US"). Use list_countries to see supported codes per model. | |
| include | No | Optional flags for heavier payload fields, each off by default: markdown (the answer rendered as markdown), html (the answer page HTML), rawResponse (the engine's unprocessed response payload), searchQueries (the web searches ChatGPT issued while answering), ads and shopping (sponsored and product results; ChatGPT tends to serve ads on follow-up prompts, so pass prompt as an array to see them), productDetails (the What to know summary and reviews of each product; needs shopping, and has no effect without it). Leave unset for the leanest response. | |
| disableWebSearch | No | Stop cloro from forcing web search, to get the answer ChatGPT gives on its own. ChatGPT then searches only when it decides to, so expect empty sources, citationPills and searchQueries. Defaults to false (web search forced). Same cost. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnly/openWorld/destructive=false, and the description adds a detailed credit-cost model (base, sync surcharge, per-feature add-ons, per-prompt and per-state increments) that an agent needs to judge cost. It also discloses that ads appear on follow-ups and that disableWebSearch changes source behavior. Lacks detail on response latency or failure modes, 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?
Front-loaded with purpose and return contents, followed by a compact cost sentence. The cost clause is dense but each part earns its place by conveying pricing that affects tool selection.
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 correctly enumerates what comes back (text, cited sources, optional markdown/search queries/shopping/ads) and explains the cost and follow-up mechanics. Complete enough to invoke correctly; the only minor gap is not describing error/empty-result handling.
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 parameters; the description nevertheless adds pricing semantics per parameter (productDetails adds 2, extra array prompts add 1, state adds 2) and reiterates subtle behavior (state needs list_states, disableWebSearch yields empty sources). Adds real value 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?
Specific verb (submit a prompt) plus resource (ChatGPT) and explicit scope (geo-targeted by country/state), returning text, sources, and optional enriched fields. Clearly distinguishable from siblings like scrape_copilot and scrape_gemini by naming the model and the geo-targeting behavior.
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?
States the intent explicitly: "Use this to see how ChatGPT answers a prompt and which brands/sources it mentions." It also points to list_countries and list_states for supported codes. It does not contrast with sibling scrapers, but the use case and auxiliaries are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a prompt to Microsoft Copilot from a chosen country (and optionally US state) and return the answer with cited sources. Use this to see how Microsoft Copilot answers a prompt and which brands/sources it mentions. Costs 7 credits (5 base + 2 sync surcharge); a state adds 2.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Optional state code for state-level targeting (e.g. "CA" when country is "US"). Only some countries support this — call list_states for the supported countries and their codes. | |
| prompt | Yes | The prompt to submit to Microsoft Copilot. | |
| country | Yes | ISO 3166-1 alpha-2 country code to geo-target the request from (e.g. "US"). Use list_countries to see supported codes per model. | |
| include | No | Optional flags for heavier payload fields, each off by default: markdown (the answer rendered as markdown), html (the answer page HTML), rawResponse (the engine's unprocessed response payload). Leave unset for the leanest response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, openWorld, non-destructive), and the description goes beyond them with a non-obvious cost model: '7 credits (5 base + 2 sync surcharge); a state adds 2.' That is real decision-relevant behavior the agent cannot get from structured fields. It doesn't mention latency or what a failed/blocked scrape looks like, which keeps it off 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?
Three sentences, front-loaded with what the tool does, then the use case, then cost. Every sentence carries distinct information; there is no restatement of the name or title.
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 does the right work by stating the return is 'the answer with cited sources,' and the cost line covers the main pre-call concern. Slightly incomplete on response shape for the heavier include flags and on what happens when a geo-target is unsupported, but otherwise sufficient for a 4-parameter read 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% and the state/country/prompt parameters already carry descriptions, so the baseline is 3. The description adds marginal value by tying the state parameter to a concrete cost and by clarifying country/state targeting, but it says nothing about the nested include flags beyond what the schema documents.
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?
Specific verb+resource: 'Submit a prompt to Microsoft Copilot from a chosen country ... and return the answer with cited sources.' The geo-targeting scope combined with the vendor name makes it unambiguously distinct from scrape_chatgpt, scrape_gemini, and scrape_perplexity in the sibling list.
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?
'Use this to see how Microsoft Copilot answers a prompt and which brands/sources it mentions' gives a concrete job to be done, and the parameter docs route the agent to list_countries/list_states before calling. What's missing is an explicit contrast with siblings (e.g., 'use scrape_chatgpt for ChatGPT answers'), so the agent must infer that sibling routing itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a prompt to Google Gemini from a chosen country (and optionally US state) and return the answer with cited sources. Use this to see how Google Gemini answers a prompt and which brands/sources it mentions. Costs 6 credits (4 base + 2 sync surcharge); a state adds 2.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Optional state code for state-level targeting (e.g. "CA" when country is "US"). Only some countries support this — call list_states for the supported countries and their codes. | |
| prompt | Yes | The prompt to submit to Google Gemini. | |
| country | Yes | ISO 3166-1 alpha-2 country code to geo-target the request from (e.g. "US"). Use list_countries to see supported codes per model. | |
| include | No | Optional flags for heavier payload fields, each off by default: markdown (the answer rendered as markdown), html (the answer page HTML), rawResponse (the engine's unprocessed response payload). Leave unset for the leanest response. |
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 genuinely new behavioral context not in the structured fields: a 6-credit cost breakdown (4 base + 2 sync surcharge, +2 for a state), which also signals the call is synchronous. It omits latency/timeout 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?
Three sentences, zero filler: capability first, use case second, cost last. The geo-targeting scope is front-loaded and the pricing is placed where an agent deciding whether to call it will see 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?
With no output schema, the description carries the return-value burden and does so at a summary level (answer plus cited sources, brand/source mentions). It also flags cost and points at list_countries/list_states via the schema. The shape of the sources array and the effect of the `include` flags on the response are not described.
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 goes slightly beyond by tying the optional state parameter to a concrete cost impact ("a state adds 2"), which the schema does not state. The nested `include` payload flags are left entirely to the schema, but that is acceptable given full coverage.
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 (submit a prompt), a specific target engine (Google Gemini), and the return shape (answer with cited sources). It is clearly distinguishable from scrape_chatgpt/scrape_copilot by engine, but it never differentiates itself from the closely-related scrape_google_ai_mode sibling, which an agent could plausibly 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?
"Use this to see how Google Gemini answers a prompt and which brands/sources it mentions" gives a concrete selection scenario, and the credit pricing helps an agent weigh it against cheaper siblings. It stops short of explicit when-not guidance or a direct pointer to scrape_google_ai_mode / scrape_google as the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a Google search from a chosen country and return organic results, with optional AI Overview extraction (include.aioverview) and People-Also-Ask AI answers (include.paaAioverview). Two modes: structured (query + gl, with optional location/uule/pages) or url (a complete google.com/search URL that owns query, location, and pagination). Supports desktop, mobile, iOS, and Android emulation and multi-page results. A result link can come back empty with a redirectLink beside it; pass the redirectLink to resolve_google_redirect to get the destination. Costs 5 credits (3 base + 2 sync surcharge); include.aioverview and/or include.paaAioverview add 2 once; each page after the first adds 2.
| Name | Required | Description | Default |
|---|---|---|---|
| gl | No | ISO 3166-1 alpha-2 code for the result geography, sent to Google as gl (e.g. "us"). Use list_countries to see supported codes per model. Required in query mode; in url mode it is read from the URL's gl parameter unless supplied here, and an explicit value wins. | |
| hl | No | Optional Google interface-language code, sent as hl (e.g. "de", "pt-br"). Defaults to the language derived from gl — set it when the geography's dominant language is not the one you want. In url mode it is read from the URL's hl parameter unless supplied here, and an explicit value wins. | |
| url | No | A complete google.com/search URL to fetch instead of building one from structured fields. When set, query/location/uule/pages must be omitted (the URL owns them); gl and hl are read from the URL's gl/hl parameters; an explicit gl or hl must agree with the URL's copy. | |
| uule | No | Optional Google UULE location parameter. Mutually exclusive with location. | |
| pages | No | Number of result pages to fetch (1-10). Defaults to 1. | |
| query | No | The search query. Required unless url is provided. | |
| device | No | Device to emulate: desktop, mobile, ios (Safari on iPhone), or android (Chrome on Android). mobile is an alias for android. Defaults to desktop. | desktop |
| country | No | ISO 3166-1 alpha-2 country code to geo-target the request from (e.g. "US"). Use list_countries to see supported codes per model. Deprecated — use gl instead; country is kept for compatibility and must not disagree with gl. | |
| include | No | Optional flags. Set aioverview: true to extract Google's AI Overview (or { markdown: true } for markdown), paaAioverview: true to hydrate AI answers in People Also Ask. Leave unset for organic results only. | |
| location | No | Optional location name to target search results (e.g. "Austin, Texas, United States"). Mutually exclusive with uule. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, openWorld, non-destructive), and the description adds substantive behavior on top: an explicit credit cost model (5 base/sync, +2 for AI Overview flags, +2 per extra page) and the quirk that a result link can come back empty with a redirectLink to resolve. Those are operationally important facts an agent could not infer 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?
Front-loaded with the core action and mode split, then costs and the redirect caveat last. Every sentence carries operational value, though a few clauses (device emulation, multi-page) restate schema content and add mild density.
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 10 parameters, a nested include object, and no output schema, the description supplies the mode rules, cost implications, and a key response anomaly (empty link + redirectLink). It does not describe the overall response envelope or pagination metadata, which is a minor gap for a scraping tool of this complexity.
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 would be 3, but the description still adds meaning: it explains that url mode owns query/location/pagination and that device emulation covers desktop/mobile/iOS/Android. The include flag semantics (markdown vs. boolean) are left to the schema, which is reasonable.
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 search ... and return organic results") plus its scope (chosen country, organic results, optional AI Overview/People-Also-Ask). It also names the sibling it hands off to (resolve_google_redirect) for empty links, so an agent can distinguish it from scrape_google_news or scrape_google_ai_mode without opening a 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?
The two-mode split (structured query+gl vs. a complete google.com/search URL that owns query/location/pagination) gives clear selection guidance between invocation styles. It also says when to use include.aioverview/paaAioverview and when to route to resolve_google_redirect. It stops short of explicitly contrasting with the news/AI-mode siblings, so no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a prompt to Google AI Mode from a chosen country and return the AI answer with cited sources. Supports location or UULE targeting and desktop/mobile emulation. Costs 6 credits (4 base + 2 sync surcharge).
| Name | Required | Description | Default |
|---|---|---|---|
| gl | No | ISO 3166-1 alpha-2 code for the result geography, sent to Google as gl (e.g. "us"). Use list_countries to see supported codes per model. | |
| hl | No | Optional Google interface-language code, sent as hl (e.g. "de", "pt-br"). Defaults to the language derived from gl — set it when the geography's dominant language is not the one you want. | |
| uule | No | Optional Google UULE location parameter. Mutually exclusive with location. | |
| device | No | Device type to emulate. Defaults to desktop. | desktop |
| prompt | Yes | The prompt to submit to Google AI Mode. | |
| country | No | ISO 3166-1 alpha-2 country code to geo-target the request from (e.g. "US"). Use list_countries to see supported codes per model. Deprecated — use gl instead; country is kept for compatibility and must not disagree with gl. | |
| include | No | Optional flags for heavier payload fields, each off by default: markdown (the answer rendered as markdown), html (the answer page HTML). Leave unset for the leanest response. | |
| location | No | Optional location name to target search results (e.g. "Austin, Texas, United States"). Mutually exclusive with uule. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, openWorldHint, destructiveHint=false), yet the description adds genuinely new context: the credit cost breakdown ('6 credits (4 base + 2 sync surcharge)') and the fact that this is a synchronous, cost-bearing call. It stops short of disclosing latency, rate limits, or failure behavior, but the cost disclosure is meaningful value beyond 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 short sentences, front-loaded with the core action before capabilities and cost. Each sentence carries distinct information with no repetition, though the cost sentence could be positioned later without loss.
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 object and no output schema, the description conveys the action, the response shape at a high level ('AI answer with cited sources'), targeting options, and cost. The heavy parameter detail is fully carried by the 100%-covered schema, leaving only minor gaps around response payload nuances.
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 including the nested 'include' flags and the deprecated 'country' is already documented in the schema. The description echoes the targeting and device capabilities but adds no syntax or format detail beyond what the schema provides, making 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?
States a specific verb and resource — 'Submit a prompt to Google AI Mode' — and names the returned payload ('the AI answer with cited sources'), which clearly separates it from scrape_google or scrape_google_news. It never explicitly contrasts itself with the sibling scraping tools, though the target engine 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?
The description implies usage through capability statements ('Supports location or UULE targeting and desktop/mobile emulation'), but gives no explicit when-to-use condition versus scrape_google or scrape_gemini, and no guidance on prerequisites such as looking up valid country codes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a Google News search from a chosen country and return news results. Supports desktop, mobile, iOS, and Android emulation and multi-page results. Costs 5 credits (3 base + 2 sync surcharge); each page after the first adds 2.
| Name | Required | Description | Default |
|---|---|---|---|
| gl | No | ISO 3166-1 alpha-2 code for the result geography, sent to Google as gl (e.g. "us"). Use list_countries to see supported codes per model. | |
| hl | No | Optional Google interface-language code, sent as hl (e.g. "de", "pt-br"). Defaults to the language derived from gl — set it when the geography's dominant language is not the one you want. | |
| pages | No | Number of result pages to fetch (1-10). Defaults to 1. | |
| query | Yes | The search query. | |
| device | No | Device to emulate: desktop, mobile, ios (Safari on iPhone), or android (Chrome on Android). mobile is an alias for android. Defaults to desktop. | desktop |
| country | No | ISO 3166-1 alpha-2 country code to geo-target the request from (e.g. "US"). Use list_countries to see supported codes per model. Deprecated — use gl instead; country is kept for compatibility and must not disagree with gl. | |
| include | No | Optional flag, off by default: html (the result page HTML). Leave unset for the leanest response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuinely useful context beyond that: a concrete credit cost model (5 credits = 3 base + 2 sync surcharge, +2 per extra page) and the fact that device emulation and multi-page fetching are supported. It does not describe the shape of the returned results, which matters given there is no output schema.
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, front-loaded with what the tool does and followed by capability and cost. Every sentence carries information; the cost sentence is dense but earns its place since pricing affects whether the agent fetches extra pages.
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 7-parameter tool with a nested object and no output schema, the description covers the essentials an agent needs: scope, geo targeting, device emulation, paging and cost. The remaining gap is the shape of the returned news results, which the description does not characterize.
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%, including enum values, defaults, deprecated-parameter warnings and a pointer to list_countries, so the schema carries the parameter burden. The description only echoes the device options and page paging at a high level, adding little beyond it. 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 and resource — 'Run a Google News search from a chosen country and return news results' — which cleanly separates it from scrape_google and the AI-mode siblings. It stops short of naming any sibling explicitly, so an agent must infer the News-vs-general-search split from the phrase 'Google News'.
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 by the resource (news results, geo-targeted by country) and the cost note gives a reason to economize on pages. But there is no explicit when-to-use/when-not guidance and no mention of the sibling tools (scrape_google, scrape_google_ai_mode) that an agent would need to choose between.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a prompt to Perplexity from a chosen country (and optionally US state) and return the answer with cited sources. Use this to see how Perplexity answers a prompt and which brands/sources it mentions. Costs 6 credits (4 base + 2 sync surcharge); a state adds 2.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Optional state code for state-level targeting (e.g. "CA" when country is "US"). Only some countries support this — call list_states for the supported countries and their codes. | |
| prompt | Yes | The prompt to submit to Perplexity. | |
| country | Yes | ISO 3166-1 alpha-2 country code to geo-target the request from (e.g. "US"). Use list_countries to see supported codes per model. | |
| include | No | Optional flags for heavier payload fields, each off by default: markdown (the answer rendered as markdown), html (the answer page HTML), rawResponse (the engine's unprocessed response payload). Leave unset for the leanest response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's added value is the concrete cost model (6 credits = 4 base + 2 sync surcharge, +2 for state), which is genuinely useful pre-call context not in the annotations. It omits latency/rate-limit nuance and doesn't elaborate on return structure beyond "answer with cited sources".
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 sentences: capability first, then the use case, then the cost. Every sentence carries information and the most decision-relevant fact (cost) is stated plainly.
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 correctly characterizes the return (answer plus cited sources) and discloses the credit price and geo-targeting scope. Additional detail on response shape for the include flags would close the remaining gap, but an agent has enough to call this 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 baseline is 3; the description adds the non-obvious fact that state targeting is optional, country-restricted, and costs an extra 2 credits, which is meaning the schema alone doesn't convey. The include flags are left entirely to the schema, keeping it short of a 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: submit a prompt to Perplexity and return the answer with cited sources, geo-targeted by country/state. The Perplexity naming implicitly distinguishes it from scrape_chatgpt/scrape_gemini siblings, but it never explicitly contrasts with them.
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?
"Use this to see how Perplexity answers a prompt and which brands/sources it mentions" gives a clear application context, and the state/country handling points implicitly to list_countries/list_states. No explicit when-not-use or exclusion guidance is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
list_countries1 field changedInput schema / properties / model / enumPrevious value: -[
- "aimode",
- "aioverview",
- "chatgpt",
- "copilot",
- "gemini",
- "google",
- "grok",
- "perplexity"
-]New value: +[
+ "aimode",
+ "aioverview",
+ "chatgpt",
+ "copilot",
+ "gemini",
+ "google",
+ "perplexity"
+]resolve_google_redirectscrape_chatgpt2 fields changedInput schema / properties / disableWebSearch / descriptionAdded value: +"Stop cloro from forcing web search, to get the answer ChatGPT gives on its own. ChatGPT then searches only when it decides to, so expect empty sources, citationPills and searchQueries. Defaults to false (web search forced). Same cost."Input schema / properties / include / descriptionPrevious value: -"Optional flags for heavier payload fields, each off by default: markdown (the answer rendered as markdown), html (the answer page HTML), rawResponse (the engine's unprocessed response payload), searchQueries (the web searches ChatGPT issued while answering), ads and shopping (sponsored and product results; ChatGPT tends to serve ads on follow-up prompts, so pass prompt as an array to see them). Leave unset for the leanest response."New value: +"Optional flags for heavier payload fields, each off by default: markdown (the answer rendered as markdown), html (the answer page HTML), rawResponse (the engine's unprocessed response payload), searchQueries (the web searches ChatGPT issued while answering), ads and shopping (sponsored and product results; ChatGPT tends to serve ads on follow-up prompts, so pass prompt as an array to see them), productDetails (the What to know summary and reviews of each product; needs shopping, and has no effect without it). Leave unset for the leanest response."scrape_google_ai_mode1 field changedInput schema / properties / include / descriptionPrevious value: -"Optional flags for heavier payload fields, each off by default: markdown (the answer rendered as markdown), html (the answer page HTML), rawResponse (the engine's unprocessed response payload). Leave unset for the leanest response."New value: +"Optional flags for heavier payload fields, each off by default: markdown (the answer rendered as markdown), html (the answer page HTML). Leave unset for the leanest response."scrape_grokscrape_chatgpt1 field changedInput schema / properties / include / properties / productDetailsAdded value: +{
+ "type": "boolean"
+}scrape_chatgpt2 fields changedInput schema / properties / include / descriptionPrevious value: -"Optional flags for heavier payload fields, each off by default: markdown (the answer rendered as markdown), html (the answer page HTML), rawResponse (the engine's unprocessed response payload), searchQueries (the web searches ChatGPT issued while answering), ads and shopping (sponsored and product results; these render only on the desktop UI, so pair them with legacy: true). Leave unset for the leanest response."New value: +"Optional flags for heavier payload fields, each off by default: markdown (the answer rendered as markdown), html (the answer page HTML), rawResponse (the engine's unprocessed response payload), searchQueries (the web searches ChatGPT issued while answering), ads and shopping (sponsored and product results; ChatGPT tends to serve ads on follow-up prompts, so pass prompt as an array to see them). Leave unset for the leanest response."Input schema / properties / legacy / descriptionPrevious value: -"Serve ChatGPT's desktop UI instead of the default mobile-web UI. Needed for include.ads and include.shopping, which only render on desktop. Defaults to false."New value: +"Serve ChatGPT's desktop UI instead of the default mobile-web UI. Defaults to false."scrape_chatgpt5 fields changedInput schema / properties / prompt / anyOfAdded value: +[
+ {
+ "maxLength": 10000,
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "items": {
+ "maxLength": 10000,
+ "minLength": 1,
+ "type": "string"
+ },
+ "maxItems": 5,
+ "minItems": 1,
+ "type": "array"
+ }
+]Input schema / properties / prompt / descriptionPrevious value: -"The prompt to submit to ChatGPT."New value: +"The prompt to submit to ChatGPT, or an array of up to 5 prompts asked in order as follow-ups in the same conversation (1 extra credit per prompt after the first). An array returns an array of results, one per prompt."Input schema / properties / prompt / maxLengthRemoved value: -10000Input schema / properties / prompt / minLengthRemoved value: -1Input schema / properties / prompt / typeRemoved value: -"string"scrape_google_news1 field changedInput schema / properties / include / descriptionPrevious value: -"Optional flags for heavier payload fields, each off by default: markdown (the answer rendered as markdown), html (the answer page HTML), rawResponse (the engine's unprocessed response payload). Leave unset for the leanest response."New value: +"Optional flag, off by default: html (the result page HTML). Leave unset for the leanest response."list_countries1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "countries": {
+ "description": "ISO 3166-1 alpha-2 country codes.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "countries"
+ ],
+ "type": "object"
+}list_states1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "states": {
+ "description": "States available for state-level targeting.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "name"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "states"
+ ],
+ "type": "object"
+}scrape_google1 field changedInput schema / properties / url / descriptionPrevious value: -"A complete google.com/search URL to fetch instead of building one from structured fields. When set, query/location/uule/pages must be omitted (the URL owns them); gl and hl are read from the URL's gl/hl parameters unless supplied explicitly."New value: +"A complete google.com/search URL to fetch instead of building one from structured fields. When set, query/location/uule/pages must be omitted (the URL owns them); gl and hl are read from the URL's gl/hl parameters; an explicit gl or hl must agree with the URL's copy."scrape_google1 field changedInput schema / properties / include / properties / googleGotoRemoved value: -{
- "type": "boolean"
-}scrape_google_ai_mode1 field changedInput schema / properties / include / properties / googleGotoRemoved value: -{
- "type": "boolean"
-}scrape_chatgpt1 field changedInput schema / properties / disableWebSearchAdded value: +{
+ "type": "boolean"
+}scrape_chatgpt2 fields changedInput schema / properties / include / descriptionPrevious value: -"Optional flags to include heavier payload fields in the response. Leave unset for the leanest response."New value: +"Optional flags for heavier payload fields, each off by default: markdown (the answer rendered as markdown), html (the answer page HTML), rawResponse (the engine's unprocessed response payload), searchQueries (the web searches ChatGPT issued while answering), ads and shopping (sponsored and product results; these render only on the desktop UI, so pair them with legacy: true). Leave unset for the leanest response."Input schema / properties / legacy / descriptionAdded value: +"Serve ChatGPT's desktop UI instead of the default mobile-web UI. Needed for include.ads and include.shopping, which only render on desktop. Defaults to false."scrape_copilot1 field changedInput schema / properties / include / descriptionPrevious value: -"Optional flags to include heavier payload fields in the response. Leave unset for the leanest response."New value: +"Optional flags for heavier payload fields, each off by default: markdown (the answer rendered as markdown), html (the answer page HTML), rawResponse (the engine's unprocessed response payload). Leave unset for the leanest response."scrape_gemini1 field changedInput schema / properties / include / descriptionPrevious value: -"Optional flags to include heavier payload fields in the response. Leave unset for the leanest response."New value: +"Optional flags for heavier payload fields, each off by default: markdown (the answer rendered as markdown), html (the answer page HTML), rawResponse (the engine's unprocessed response payload). Leave unset for the leanest response."scrape_google_ai_mode1 field changedInput schema / properties / include / descriptionPrevious value: -"Optional flags to include heavier payload fields in the response. Leave unset for the leanest response."New value: +"Optional flags for heavier payload fields, each off by default: markdown (the answer rendered as markdown), html (the answer page HTML), rawResponse (the engine's unprocessed response payload). Leave unset for the leanest response."scrape_google_news1 field changedInput schema / properties / include / descriptionPrevious value: -"Optional flags to include heavier payload fields in the response. Leave unset for the leanest response."New value: +"Optional flags for heavier payload fields, each off by default: markdown (the answer rendered as markdown), html (the answer page HTML), rawResponse (the engine's unprocessed response payload). Leave unset for the leanest response."scrape_grok1 field changedInput schema / properties / include / descriptionPrevious value: -"Optional flags to include heavier payload fields in the response. Leave unset for the leanest response."New value: +"Optional flags for heavier payload fields, each off by default: markdown (the answer rendered as markdown), html (the answer page HTML), rawResponse (the engine's unprocessed response payload). Leave unset for the leanest response."scrape_perplexity1 field changedInput schema / properties / include / descriptionPrevious value: -"Optional flags to include heavier payload fields in the response. Leave unset for the leanest response."New value: +"Optional flags for heavier payload fields, each off by default: markdown (the answer rendered as markdown), html (the answer page HTML), rawResponse (the engine's unprocessed response payload). Leave unset for the leanest response."scrape_google1 field changedInput schema / properties / include / properties / googleGotoAdded value: +{
+ "type": "boolean"
+}scrape_google_ai_mode1 field changedInput schema / properties / include / properties / googleGotoAdded value: +{
+ "type": "boolean"
+}scrape_chatgpt1 field changedInput schema / properties / legacyAdded value: +{
+ "type": "boolean"
+}scrape_google4 fields changedInput schema / properties / country / descriptionPrevious value: -"ISO 3166-1 alpha-2 country code to geo-target the request from (e.g. \"US\"). Use list_countries to see supported codes per model. Required in query mode; in url mode it can be derived from the URL's gl parameter."New value: +"ISO 3166-1 alpha-2 country code to geo-target the request from (e.g. \"US\"). Use list_countries to see supported codes per model. Deprecated — use gl instead; country is kept for compatibility and must not disagree with gl."Input schema / properties / glAdded value: +{
+ "description": "ISO 3166-1 alpha-2 code for the result geography, sent to Google as gl (e.g. \"us\"). Use list_countries to see supported codes per model. Required in query mode; in url mode it is read from the URL's gl parameter unless supplied here, and an explicit value wins.",
+ "type": "string"
+}Input schema / properties / hlAdded value: +{
+ "description": "Optional Google interface-language code, sent as hl (e.g. \"de\", \"pt-br\"). Defaults to the language derived from gl — set it when the geography's dominant language is not the one you want. In url mode it is read from the URL's hl parameter unless supplied here, and an explicit value wins.",
+ "type": "string"
+}Input schema / properties / url / descriptionPrevious value: -"A complete google.com/search URL to fetch instead of building one from structured fields. When set, query/location/uule/pages must be omitted (the URL owns them); country can be derived from the URL's gl parameter."New value: +"A complete google.com/search URL to fetch instead of building one from structured fields. When set, query/location/uule/pages must be omitted (the URL owns them); gl and hl are read from the URL's gl/hl parameters unless supplied explicitly."scrape_google_ai_mode4 fields changedInput schema / properties / country / descriptionPrevious value: -"ISO 3166-1 alpha-2 country code to geo-target the request from (e.g. \"US\"). Use list_countries to see supported codes per model."New value: +"ISO 3166-1 alpha-2 country code to geo-target the request from (e.g. \"US\"). Use list_countries to see supported codes per model. Deprecated — use gl instead; country is kept for compatibility and must not disagree with gl."Input schema / properties / glAdded value: +{
+ "description": "ISO 3166-1 alpha-2 code for the result geography, sent to Google as gl (e.g. \"us\"). Use list_countries to see supported codes per model.",
+ "type": "string"
+}Input schema / properties / hlAdded value: +{
+ "description": "Optional Google interface-language code, sent as hl (e.g. \"de\", \"pt-br\"). Defaults to the language derived from gl — set it when the geography's dominant language is not the one you want.",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "prompt",
- "country"
-]New value: +[
+ "prompt"
+]scrape_google_news4 fields changedInput schema / properties / country / descriptionPrevious value: -"ISO 3166-1 alpha-2 country code to geo-target the request from (e.g. \"US\"). Use list_countries to see supported codes per model."New value: +"ISO 3166-1 alpha-2 country code to geo-target the request from (e.g. \"US\"). Use list_countries to see supported codes per model. Deprecated — use gl instead; country is kept for compatibility and must not disagree with gl."Input schema / properties / glAdded value: +{
+ "description": "ISO 3166-1 alpha-2 code for the result geography, sent to Google as gl (e.g. \"us\"). Use list_countries to see supported codes per model.",
+ "type": "string"
+}Input schema / properties / hlAdded value: +{
+ "description": "Optional Google interface-language code, sent as hl (e.g. \"de\", \"pt-br\"). Defaults to the language derived from gl — set it when the geography's dominant language is not the one you want.",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "query",
- "country"
-]New value: +[
+ "query"
+]list_countrieslist_statesscrape_chatgptscrape_copilotscrape_geminiscrape_googlescrape_google_ai_modescrape_google_newsscrape_grokscrape_perplexityScrape Google search results with SERP data, ads, and knowledge panels
Structured Google search, news, and local results at scale - organic results, news, and local packs
Web scraping, search, crawling, structured extraction and research for AI agents.
Google SERP, Maps, Shopping, News and AI-answer data for AI agents, from the Searlo search API.
Add one secure layer between your agents and this server.