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

With no annotations, the description carries the full burden and delivers real behavioral context: it discloses the result shape (answer + sources) and the important operational trait that AI Mode pages almost always require JS, so engine=auto will select the browser. Rate limits, auth needs, and latency are not covered, but the JS/engine caveat is genuinely useful.

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 purpose and output shape are front-loaded, and the engine note is separated into its own block. It is compact and largely waste-free, with only minor redundancy around the engine explanation.

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 detailed, and the engine/JS behavior is covered. However, the locale parameters gl and hl are undocumented in both description and schema, leaving a real gap for a 4-parameter 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 0% for 4 parameters, so the description must compensate. It explains the engine parameter's valid values (auto|http|proxy|browser) and their behavioral implication, but leaves gl, hl, and query entirely undocumented, so its coverage is partial.

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 resource and mode (Google AI Mode, udm=50) and states the output type (synthesis answer + sources) and intended use (direct questions). It distinguishes itself from generic search siblings by emphasizing synthesized answers rather than link lists, though it never explicitly names a contrasting sibling.

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 implies usage with 'cocok untuk pertanyaan langsung' (suitable for direct questions), which signals when this tool fits, but offers no explicit when-not-to-use guidance or named alternative. The engine reference to google_web_search is a helpful pointer but does not route between the two tools.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Scrape' hints at a web-scraping operation, and engine values are listed, but nothing is said about rate limits, auth requirements, pagination via start/num, or reliability. For a scraper with zero annotation coverage this is a significant gap.

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 compact lines with the core purpose front-loaded followed by the engine enumeration. No padding, though the trailing parenthetical reference to google_web_search is slightly cryptic for a standalone description.

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 needn't be explained. However, for a 6-parameter tool with no annotations and 0% schema coverage, the description is too thin: it omits pagination, locale, and result-count semantics. It leaves an agent under-informed about how to call this tool 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 description coverage is 0% across 6 parameters, yet the description only explains one (engine: auto|http|proxy|browser). The query, gl (locale), hl (language), num, and start parameters remain undefined in both schema and description, leaving most of the contract unclear and requiring the agent to guess at formats and 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?

States a specific verb (Scrape) and resource (Google Books Search, with the tbm=bks identifier) plus the returned fields (title, URL, snippet). This distinguishes it from generic search siblings, though it doesn't name a specific alternative tool. Clear and actionable, but no explicit sibling routing.

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

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

No when-to-use or when-not-to-use guidance relative to siblings like google_search, google_scholar_search, or google_web_search. The only cross-reference is a parenthetical pointing to google_web_search for the engine parameter, which is about configuration, not selection. An agent gets no routing help.

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

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

No annotations are provided, so the description carries the full disclosure burden. It hints at the extraction scope via the returned field list, but says nothing about permissions, rate limits, redirect/robots handling, or side effects of crawling an arbitrary URL.

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?

A single short sentence with the core action front-loaded and zero filler. It is efficient, though its brevity is partly under-specification rather than deliberate tightness.

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 re-explained, but with zero annotation coverage and 0% parameter documentation the definition leaves the two optional controls and the crawling behavior entirely undefined for a tool that fetches arbitrary external URLs.

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

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

Schema description coverage is 0% for all 3 parameters. The description only obliquely maps 'outbound links' to include_links and never mentions max_chars (which defaults to 8000) or the meaning/units of these controls, so it fails to compensate for the undocumented 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 pairs a specific verb ('Crawl') with a resource ('any URL') and enumerates the extracted artifacts (title, meta, text, outbound links). This clearly separates it from the sibling search/quote/translate tools, though it does not name a sibling explicitly.

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?

'Crawl any URL (e.g. a search result)' implies the context of fetching page content behind a link, but gives no explicit when-to-use/when-not guidance or alternatives. An agent must infer that this is the follow-up to a search result rather than a search itself.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing beyond the resource being scraped. It says nothing about rate limits, blocking/anti-bot behavior, auth needs, or whether the ticker must correspond to a known exchange listing - all material 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?

A single front-loaded sentence that states the action, the target, and the payload with zero filler. Nothing to trim and nothing important buried.

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, but the definition leaves the two optional parameters entirely undocumented and omits all behavioral context for a scraper with no annotations. An agent knows roughly what it does but not how to call it safely or completely.

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

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

Schema description coverage is 0% across all three parameters. The description hints only at the subject of the scrape (a quote page) and does not explain 'ticker' format, what 'exchange' does when the ticker is ambiguous, or that 'hl' controls language.

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 ('Scrape'), a specific resource ('Google Finance quote page'), and enumerates the returned fields (price, prev close, day high/low, change). No sibling tool covers finance quotes, so an agent can route here unambiguously from the name alone.

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?

There is no statement of when to use this tool versus any alternative, nor any exclusions or prerequisites. The use case (fetching a stock quote) is only inferable from the tool name and the listed fields, not from explicit guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the topics covered (including a 'status contract' and 'safe usage patterns'), which signals it is a read-only reference, but it never explicitly states that it has no side effects or how the returned guidance should be consumed. For a zero-parameter read tool the risk is low, so this gap is modest.

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?

A single front-loaded sentence with a trailing imperative; every clause (tool map, engine semantics, status contract, safe patterns) adds distinct information and none is wasted.

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 parameters and an output schema present, the description needn't explain return values, and it adequately frames what the call yields and when to make it. Nothing critical for correct invocation 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?

The tool takes zero parameters, so per the calibration this defaults to a baseline of 4. The description adds no parameter detail, but there is nothing to document.

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 the resource (an agent-facing usage guide) and enumerates its contents: tool map, engine semantics, status contract, and safe usage patterns. This clearly separates it from all the search/quote/translate siblings, which perform actual lookups rather than explaining the toolkit. It stops short of a crisp 'returns documentation about X' verb, keeping it just below a 5.

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?

'Read this before experimenting' gives explicit when-to-use guidance pointing at the pre-use/onboarding moment, which is exactly when an agent would want a tool map. It doesn't name an alternative or an exclusion, but for a meta help tool no real alternative exists, so the omission is minor.

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

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

With no annotations, the description carries the full burden. It does add real behavioral signal by naming the engine modes (auto/http/proxy/browser), which implies anti-bot/rate-limit tradeoffs, and it says what is extracted. However, it omits auth needs, throttling behavior, and failure modes for a scraping operation.

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 short, front-loaded sentences with no filler; the output payload is stated first and engine modes second. The trailing cross-reference is terse and partly in Indonesian ('lihat'), which is a minor readability blemish rather than bloat.

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 are covered, but for a 6-parameter scraping tool with zero annotation coverage the description leaves defaults, locale/result-count semantics, and pagination behavior undocumented, and offers no usage routing.

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

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

Schema description coverage is 0% across 6 parameters, so the schema documents nothing. The description only enumerates the engine values; gl, hl, num, page, and query are left entirely unexplained, so it fails to compensate for the coverage gap beyond one parameter.

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 (Scrape), resource (Google Images, with the tbm=isch implementation detail), and the payload returned (direct image URLs, page URLs, sizes). The image-specific resource is inherently distinct from the other google_* search siblings, though it never explicitly contrasts itself 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?

There is no guidance on when to pick this over google_web_search, google_video_search, or the other media search tools, nor any prerequisites or exclusions. The reference to google_web_search is only for engine-mode semantics, not for tool selection.

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

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

With no annotations, the description must carry the full behavioral burden, and it does not. It implies a read-only RSS scrape and hints at real-time freshness ('right now'), but says nothing about rate limits, auth requirements, result volume, or pagination for a scraping tool.

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

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

A single front-loaded sentence with no filler, which is efficient. Given the undocumented locale parameters, though, the brevity shades into under-specification rather than ideal 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?

The output schema exists, so return values need no explanation, but three undocumented parameters and zero annotations leave the definition materially incomplete for a tool whose behavior depends on locale inputs.

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

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

All three parameters (gl, hl, ceid) have 0% schema description coverage and no enums, and the description adds nothing about them. Locale/region codes like 'US:en' are non-obvious, and the description leaves the agent unable to tell that these control geo/language of the feed.

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 (scrape) and resource (Google News homepage RSS) plus what it returns ('top headlines right now'). It implicitly separates itself from google_news_search by naming the homepage, but never explicitly routes between 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?

No when-to-use guidance, no conditions, and no mention of the obvious alternative google_news_search for query-based retrieval. The agent must infer that this is the un-parameterized 'front page' variant.

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

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

With no annotations, the description carries the full behavioral burden and does add real value: it discloses the unblocked RSS path, the fallback to a rendered News tab, and that Camoufox is used for browser mode. It says nothing about rate limits, result caps, pagination, or failure modes beyond the one fallback, leaving gaps for a scraping tool with no annotation coverage.

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?

It is short and front-loads the core action, but the second block is a raw parameter-value enumeration that arguably belongs in the schema, and the awkward line breaks plus code-switching reduce clarity per word.

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. However, for a 6-parameter scraper with 0% schema coverage and no annotations, the description covers only the engine parameter and gives no guidance on the geographic/language controls or on choosing this tool over sibling search tools.

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

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

Schema description coverage is 0% across 6 parameters. The description partially compensates by defining the engine values (auto | http | proxy | browser) in a way the bare string schema does not, but it omits any meaning for query, gl, hl, ceid, and num, leaving most parameters undocumented in both places.

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 opening verb+resource ('Scrape Google News') is specific and lets an agent tell it apart from siblings like google_news_homepage or google_web_search. The mixed Indonesian/English phrasing ('RSS dulu', 'renderan bila RSS gagal') slightly muddies an otherwise clear statement of what the tool does.

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 describes an internal retrieval strategy (RSS first, News-tab fallback) and lists engine modes, which implicitly guides how to invoke it. It never states when to prefer this tool over google_news_homepage, google_web_search, or any other sibling, so usage selection is left 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?

No annotations are provided, so the description carries the full behavioral burden. It reveals that results come from scraping 'XHR JSON' and lists returned fields, but says nothing about rate limits, blocking, result caps, or authentication needs. The field list is also largely redundant given an output schema exists.

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 purpose and kept short; every line contributes. The NOTE formatting is slightly awkward but does not waste space.

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 restated. However, with no annotations and an undocumented `num` parameter, the definition remains thin for a scraper whose reliability and limits an agent might need to know.

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

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

With 0% schema description coverage the description must compensate, but it only explains `page` (1-based, embedded in the url query string as page=N). The `num` parameter (default 10) is left entirely undefined, and `query` is only inferable from the tool name, leaving a significant documentation gap.

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 ('Scrape') plus named resource ('Google Patents') and a concrete list of returned fields (title, number, inventors, dates, PDF). An agent immediately knows what this tool does and what distinguishes it from the sibling search tools (finance, books, news, 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?

There is no guidance on when to use this tool versus siblings like google_scholar_search or google_web_search, nor any exclusions or prerequisites. The page-placement note is a mechanics tip, not usage guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden. It says 'scrape' but discloses nothing about rate limits, anti-bot behavior, pagination semantics, or auth requirements; the engine note merely delegates to another tool rather than describing 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?

Two short sentences with no padding and the core purpose front-loaded. However, the second sentence is a mixed-language fragment ('engine: auto | http | proxy | browser (lihat google_web_search)') that adds a reference without explaining it, weakening structure.

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-value explanation is not required, but with 5 parameters at 0% schema coverage and zero annotations the description leaves too much unspecified for an agent to call the tool correctly across hl/num/start/engine.

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

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

Schema description coverage is 0% for 5 parameters, so the description must compensate. It only hints at cluster_id's origin and lists engine values via a cross-reference; hl, num, and start remain completely undocumented in both schema and description.

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 ('scrape') and resource ('papers citing a Scholar cluster') and clarifies the source of the required cluster_id, which separates it from sibling google_scholar_search. It is clear but does not explicitly contrast itself with the other Scholar tool beyond the parenthetical.

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 note that cluster_id comes 'from cluster_id in scholar results' implies the workflow (first run a Scholar search, then use this), but there is no explicit when-to-use/when-not guidance or named alternative for obtaining citation data.

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

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

No annotations are provided, so the description carries the full burden. 'Scrape' implies a fragile/rate-limited operation but nothing is said about blocking, quotas, auth, or failure modes. The engine enum (auto|http|proxy|browser) does add some real behavioral context but not enough for a scraping tool.

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

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

Front-loads the purpose in one line and follows with terse parameter notes; no wasted sentences. The mixed-language fragment ('lihat google_web_search') is slightly awkward but does not bloat the 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?

An output schema exists so return values need not be re-explained, but with 7 parameters at 0% coverage, no annotations, and 5 undocumented params, the definition is not complete enough for an agent to invoke it confidently.

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

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

Schema coverage is 0% and 7 parameters exist. The description documents only start (0-based offset) and engine (enum values); hl, num, query, year_low, and year_high remain unexplained in both schema and description, so it only partially compensates for the coverage gap.

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 (scrape) and resource (Google Scholar) and lists what it returns (papers, authors/venue, citations, PDF links), so an agent knows the surface. It does not differentiate itself from siblings like google_scholar_cited_by or google_search, so it stops short of a 5.

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 references google_web_search (for engine) and mentions that unified google_search computes start, which hints at a relationship between tools. However, it never states when to use this tool versus google_search, google_web_search, or google_scholar_cited_by, 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?

With no annotations, the description carries the full burden. It usefully discloses engine behavior beyond the schema: 'auto (HTTP cepat, fallback browser bila diblokir)', forced proxy pool, and direct browser modes, plus the note that news pagination slices an RSS feed. It omits any statement on rate limits, blocking risk, or auth needs, and is partly written in Indonesian, which weakens the disclosure.

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 core claim is front-loaded in sentence one, and the following lines are terse, non-redundant param notes that each add information. Language mixing (Indonesian parentheticals) slightly undermines readability, but nothing is padded.

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. Given 7 parameters at 0% schema coverage and no annotations, the description fills the most important gaps (tab, page, num, engine) but leaves gl/hl undocumented and gives no sibling-routing guidance, so it is only adequately complete for the tool's 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 0%, so the description must compensate. It documents tab (9 enumerated values), page (1-10 with news caveat), num (per page), and engine (4 modes with explanations) – solid value. But query, gl, and hl receive no explanation at all, leaving locale/language behavior undocumented.

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 lead sentence gives a specific verb+resource (search) and states the defining scope: 'One search tool for all Google tabs + pagination (pages 1-10).' This meaningfully distinguishes it from the tab-specific siblings (google_web_search, google_image_search, etc.) by framing itself as the consolidated option. However, it never explicitly says the relationship, so the differentiation is inferred rather than stated.

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 tab list and page range imply coverage, letting an agent infer this tool can substitute for the dedicated per-tab siblings, and the engine note hints at blocking/fallback scenarios. But there is no explicit 'use X instead when...' guidance, so the choice between this and google_web_search / google_news_search must be guessed.

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

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

No annotations are provided, so the description carries the full burden. It discloses the returned fields but says nothing about the scraping implications, rate limits, blocking/anti-bot behavior, or auth requirements. The engine options hint at fetching trade-offs but without explanation.

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?

Very short and front-loaded, with the resource and output fields stated first. The parenthetical reference to another tool is somewhat cryptic but does not bloat the 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?

With 6 parameters at 0% schema coverage and no annotations, the description should compensate but largely does not. An output schema exists so return-value detail is excused, but the near-total absence of parameter and behavioral context leaves the definition under-specified.

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

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

Schema description coverage is 0% across 6 parameters. The description adds value only for engine (listing auto|http|proxy|browser, which the schema lacks) and tbm=shop; gl, hl, num, start, and query remain completely undocumented in both schema and description.

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 (Scrape) and resource (Google Shopping, tbm=shop) plus the returned fields (title, URL, snippet), which distinguishes it from sibling search tools like google_image_search or google_news_search. It is clear but does not explicitly differentiate itself from the closest siblings beyond the resource name.

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 no when-to-use guidance, no conditions that select this tool over alternatives, and no exclusions. The only cross-reference is a vague pointer to google_web_search for engine behavior, which is not usage guidance.

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

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

With no annotations, the description carries the full burden, and it does disclose the content of the report: endpoint reachability, proxy pool, cache, cooldowns and forensic counters. It implies a read-only diagnostic but does not explicitly state that it mutates nothing or that no auth/quota consumption is involved, leaving a small gap.

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?

A single sentence, front-loaded with the 'Health check' framing and then the specific report contents. Every clause adds information and nothing is padded.

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 the description need not enumerate return values, yet it helpfully previews the report sections. For a zero-param diagnostic tool this is nearly complete; the only omission is an explicit statement that it is a safe, non-mutating probe.

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 tool takes zero parameters, so there is no parameter semantics to document and the baseline is 4. Nothing in the description is needed to explain inputs, and it introduces none.

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: a health check reporting which Google endpoints are reachable from the caller's IP, extended by the diagnostic surfaces it includes (proxy pool, cache, cooldowns, forensic counters). This is clearly distinguishable from every sibling, all of which fetch search or data results rather than report connectivity state.

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 phrase 'Health check' implies a diagnostic use case, and no sibling overlaps, so usage is reasonably inferable. However, the description never explicitly says when to call this (e.g. before other Google calls, or when a sibling fails), leaving the trigger condition 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?

No annotations are provided, so the description must carry the full behavioral burden. '(no block)' is vague and may hint at a behavioral trait, but it does not clarify read-only status, auth needs, rate limits, or response behavior. This is a significant gap for a tool with no annotation coverage.

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

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

The description is very short and front-loaded with no filler. However, the parenthetical '(no block)' is unclear and the overall phrase is too terse to be truly helpful given the lack of structured context.

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 explained. Still, with no annotations and 0% schema description coverage, the description should explain parameter meanings and basic behavior, which it does not. It is incomplete for correct invocation.

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

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

Schema description coverage is 0%, and the description adds no meaning for either parameter. It does not explain the required 'query' parameter or the optional 'hl' language parameter, leaving the agent with only the schema's bare type information.

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 the resource clearly: 'Google autocomplete suggestions.' It distinguishes the tool from siblings like google_search and google_web_search by focusing on autocomplete rather than search results. However, it lacks a specific verb and the '(no block)' qualifier is cryptic, so it is not fully 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?

No when-to-use guidance or alternatives are provided. The agent can infer that this tool returns autocomplete suggestions, but there is no explicit context for selecting it over other search-related siblings.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the endpoint is unofficial and requires no API key, which tells the agent about auth expectations and reliability risk. However, it says nothing about rate limits, error/failure behavior, or supported language handling.

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?

A single tight sentence with the core action front-loaded and no wasted words. Nothing to trim and nothing buried.

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 explained, and the tool is simple. Still, the undocumented language-code parameters and absence of any usage or behavioral guidance leave real gaps for an agent invoking it unaided.

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

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

Schema description coverage is 0%, and the description never mentions 'text', 'source', or 'target'. Critically, it does not clarify that source/target are language codes or what format they take, nor the meaning of the 'auto' default — the schema field names alone leave ambiguity that the description should have resolved.

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 ('Translate text') and identifies the mechanism used (Google's unofficial gtx endpoint). It is self-evidently distinct from the sibling tools, which are all search/finance/trend lookups, though it doesn't explicitly contrast itself with any of 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?

There is no statement of when to use this tool versus alternatives, no prerequisites, and no exclusions. The purpose is inferable from the name, but the description provides no routing guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses one trait beyond the schema — the '(no block)' reliability claim about the RSS endpoint — and that this is a read-style fetch, but says nothing about auth, rate limits, or failure 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?

A single tight sentence with the core purpose front-loaded and no filler. It is arguably too terse in places — '(no block)' is cryptic — but nothing is wasted.

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 do not need explaining, but the description still omits parameter meaning for a 0%-coverage schema and offers no usage routing against google_trends_interest. For a two-input fetch tool it leaves the agent guessing on both inputs and on tool selection.

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

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

Schema description coverage is 0%, so the schema provides no help for the two parameters, and the description never mentions 'hl' or 'geo' at all. The names are conventional Google abbreviations, which keeps this above a 1, but the description adds zero semantic value for the inputs.

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 (fetch Google daily trending searches) plus the delivery format (RSS) and returned fields (topic, traffic, links). It does not explicitly contrast itself with the sibling google_trends_interest, so sibling differentiation is left to inference.

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?

There is no when-to-use or when-not-to-use guidance, and no mention of the nearby google_trends_interest alternative for trending-vs-interest-over-time use cases. The agent must infer the routing decision from the tool name alone.

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

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

With no annotations, the description carries the full behavioral burden and does well: it discloses that the widgetdata endpoint often rejects non-browser requests (HTTP 400/401), that engine=auto falls back to Camoufox with cookies/fingerprint, and that persistent failure yields status 'limited'. It omits auth/rate-limit specifics, but the failure-mode and fallback disclosure is genuinely valuable context.

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?

Purpose is front-loaded, but the text is bilingual (English + Indonesian) and repeats engine explanation across the param list and the NOTE block, padding the length. Structure is serviceable but not tight.

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-value explanation is unnecessary. However, three parameters (hl, tz, geo) are undocumented and there is no usage routing versus sibling trends tools, leaving meaningful gaps for a tool with non-trivial fallback behavior.

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

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

Schema description coverage is 0% for 6 parameters, so the description must compensate. It explains keywords (comma-separated, max 5), timeframe (with concrete examples), and engine (auto/http/browser semantics), but leaves hl, tz, and geo completely undocumented in both schema and description. Coverage of half the parameters is partial compensation.

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+resource: 'Google Trends interest-over-time via internal explore API (no key).' The 'interest-over-time' scope implicitly distinguishes it from the sibling google_trends_daily, and the '(no key)' note clarifies access requirements. It stops short of explicitly naming the sibling it differs from, so it is clear but not fully differentiated.

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 through parameter examples (keywords max 5, timeframe values like 'now 7-d', engine options), but there is no explicit when-to-use guidance versus google_trends_daily or other search siblings. No exclusions or preconditions are stated for choosing this tool over 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the output shape but says nothing about scraping reliability, rate limits, blocking, auth needs, or pagination behavior; delegating the engine explanation to another tool's description does not compensate.

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?

It is short and front-loads the core action, which is good, but the second line is telegraphic and half-Indonesian ('lihat google_web_search'), making it weaker as a standalone instruction despite the brevity.

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 no explanation, but with 0% parameter coverage and no annotations the definition leaves five of six parameters and the entire behavioral profile unaddressed — incomplete for a scraping tool with locale and pagination knobs.

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

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

Schema coverage is 0% and there are 6 parameters. The description only clarifies one — engine (auto | http | proxy | browser) — which the schema leaves as a bare string with a default and no enum, so that addition is genuinely useful. But gl, hl, num, start, and query are entirely undocumented in both places.

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 concrete verb and resource ('Scrape Google Video Search (tbm=vid)') and enumerates the returned fields (title, URL, snippet), which is specific enough to distinguish it from the sibling search tools at a glance. It stops short of explicitly contrasting itself with google_web_search or google_image_search, so it lands at 4 rather than 5.

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?

Purpose implies when to reach for it (video results only), and the reference to google_web_search for the engine semantics is a mild cross-reference. However, there is no explicit when-to-use / when-not guidance or stated alternatives among the ~20 sibling search tools.

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

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

With no annotations, the description carries the full burden. It does disclose meaningful scraping behavior: HTTP may be blocked and falls back to a browser, a forced proxy pool exists, and browser mode bypasses proxy/API keys. It does not state auth needs, rate limits, or reliability caveats, leaving notable gaps 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 compact sentences, purpose front-loaded before the engine detail, with no filler. The engine clause is dense and mixes Indonesian with English, which slightly hurts readability but not length.

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, but with 6 undocumented parameters and no annotations, an agent lacks the semantic context (locale, result count, pagination via start) needed to invoke it well. The description covers only one of several open questions.

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

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

Schema description coverage is 0% across 6 parameters, so the description must compensate. It explains only 'engine' (with four modes); gl, hl, num, start, and even query are left entirely unexplained, so most parameters gain no meaning beyond their names and defaults.

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 ('Scrape') and resource ('Google Web Search') and enumerates the output surface (organic results, featured snippet, related searches), so the agent knows what it retrieves. However, it offers no differentiation from the near-identical sibling 'google_search' (or the other vertical search tools), so it is clear but not sibling-distinguishing.

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 'engine' clause gives per-mode guidance about which retrieval strategy to pick (auto/http/proxy/browser), which is useful context. But there is no statement of when to select this tool over its many search siblings, nor any exclusions or prerequisites, so usage is only implied.

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