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

With annotations covering the safety profile (readOnly, idempotent, openWorld, non-destructive), the description adds genuinely novel context: Google rate-limiting, the fact that blocked results require waiting or switching tools, and that the AI Mode page nearly always needs JS so engine=auto falls back to browser. That is real behavioral value beyond the annotations.

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

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

Front-loaded with the purpose and result shape, then engine notes, then rate-limit guidance — three tight blocks with no filler. Slightly fragmented by mixing languages and a parenthetical cross-reference, but every line earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the description needn't explain return values, and it is complete on rate-limiting, engine selection, and JS fallback. The main gap is that the localization parameters (gl/hl) are undocumented anywhere, leaving an agent guessing about their meaning.

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% with 4 parameters, so the description carries the burden. It usefully documents the engine parameter's values (auto|http|proxy|browser) and the JS/browser fallback behavior, which the schema does not express. But gl, hl, and query are left entirely unexplained, so compensation is only 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 states a specific verb+resource with scope: a Google AI Mode (udm=50) synthesis search returning 'answer + sources', positioned for 'pertanyaan langsung' (direct questions). It distinguishes itself contextually from generic listings and references the sibling google_web_search for engine semantics. It stops short of an explicit contrast with the many other search 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 implied usage ('cocok untuk pertanyaan langsung') and explicit failure-path guidance ('when the result is blocked, wait or switch to an RSS-based tool'), which names an alternative class of tool. However there is no clear when-not-to-use statement or routing rule against the concrete siblings (google_web_search, google_search).

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the description earns credit for adding rate-limit behavior on Google's side and the engine fallback options. This is real behavioral context beyond the annotations, though it doesn't describe pagination or blocking symptoms in detail.

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 what the tool returns, then the engine note and rate-limit caveat in two short lines. Efficient and low-waste, though the parenthetical cross-reference and mixed-language phrasing add slight friction.

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, and annotations handle safety. But with 6 parameters at 0% coverage and only one parameter addressed in prose, the description is incompletely specified for an agent trying to invoke it precisely.

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 description carries the full burden for six parameters. It only clarifies 'engine' (auto | http | proxy | browser), leaving query, gl, hl, num, and start completely undocumented in both schema and text.

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) plus resource (Google Books Search) and even names the output fields (title, URL, snippet). The resource is distinguishable from siblings like google_scholar_search or google_patents_search by name, though the description does not explicitly contrast 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?

Gives operational guidance on rate limits (avoid rapid repeats; when blocked, wait or switch to an RSS-based tool) and points at google_web_search for engine semantics. However it never states when to choose books search versus the many sibling search tools, which is the core selection question.

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

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

Annotations already declare read-only, idempotent, open-world, non-destructive behavior, so the safety profile is covered. The description adds genuinely new operational context the annotations cannot convey: rate limiting by Google, avoiding rapid repeats, and what to do when a result is blocked.

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 with no filler. The primary capability is front-loaded and the operational caveat follows immediately after.

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, and the rate-limit/blocked behavior is well covered. However, with 0% parameter description coverage across three parameters, the definition is incomplete for correct invocation, particularly for max_chars and include_links.

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 nothing in the structured data explains url, max_chars, or include_links. The description names output fields but never defines max_chars (a default of 8000) or how include_links affects the returned outbound links, leaving two of three parameters unexplained.

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 (Crawl) and resource (any URL), and enumerates exactly what comes back: title, meta, text, outbound links. That output list also implicitly separates it from the sibling search tools, which return query results rather than page content.

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

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

Gives a concrete use case ("e.g. a search result") and an explicit fallback path for the blocked case (wait, or switch to an RSS-based tool). It never names a specific sibling tool or states when not to use this one, so it stops short of full 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?

Annotations already declare readOnly/idempotent/openWorld, so the safety profile is covered. The description adds genuinely new behavioral context: Google imposes rate limits, rapid repeats risk blocking, and blocked results require waiting or an alternative tool. That's real operational guidance beyond the annotations.

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

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

Three short, front-loaded blocks: purpose, ticker syntax, rate-limit caveat. No wasted sentences, though the mixed Indonesian/English phrasing adds mild reading friction.

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 described. With that covered, the description supplies the missing input-format guidance and the rate-limit behavior. Main residual gap is not clarifying its relationship to the overlapping google_fx_rate sibling.

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 carry the load, and it does: it explains ticker format with concrete examples per exchange ('BBCA'+'IDX', 'AAPL'+'NASDAQ') and forex pair normalization ('USD-IDR', 'USDIDR/USD/IDR' accepted). It leaves 'hl' and 'exchange' defaults unmentioned, hence not 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 ('Scrape Google Finance quote') and enumerates covered asset classes (stocks, forex, crypto). It's clear what it does, though it doesn't explicitly distinguish itself from the sibling google_fx_rate, which presumably overlaps on forex quotes.

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?

Provides a useful rate-limit workaround ('wait or switch to an RSS-based tool'), which is a strong when-blocked alternative. But it never states when to use this over google_fx_rate for currency pairs, leaving sibling routing ambiguous.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), but the description adds real operational context: Google rate-limiting, the blocked-result failure mode, and why it is more layout-resilient than finance pages. It stops short of describing pagination or latency, but the added context is substantive.

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?

Short and front-loaded: purpose, return shape, differentiation, and the rate-limit caveat each occupy about one sentence. Only the final rate-limit sentence is slightly tangential to selection, but it earns its place as an operational warning.

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 routing guidance is complete. However, with six undocumented parameters and no schema descriptions, an agent lacks guidance on locale/engine options, which keeps this from being fully complete.

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

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

Schema description coverage is 0% across six parameters, so the description carries the full burden. The example '1 USD to IDR' loosely implies base/quote/amount, but gl, hl, and engine are never explained and no value formats or defaults are clarified beyond the schema itself.

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 ('live rate from the SERP converter widget') with a concrete example ('1 USD to IDR') and names the output field fx_rate. It also distinguishes itself from the sibling google_kurs_bi, so an agent can route without opening either 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?

Explicitly says when to use it ('quick rates') and when not to ('for official BI rates use google_kurs_bi'), plus a fallback path when results are blocked (wait or switch to an RSS-based tool). Both the alternative and the exclusions are stated outright.

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

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

Annotations already establish readOnly, idempotent, openWorld and non-destructive. The description adds genuinely new behavioral context: Google-side rate limiting, avoiding rapid repeats, and the wait-or-switch R2B fallback when blocked. That is meaningful operational guidance beyond the structured hints.

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 tool's identity and content, then the critical rate-limit guidance. No filler; every clause carries information the agent needs before experimenting.

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. Given the tool is a documentation/help endpoint, the description adequately signals its scope (tool map, engine semantics, status contract, safe usage) and the key operational caveat.

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 nothing for the description to clarify beyond the schema. Baseline 4 applies since no parameter semantics are required.

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 purpose: an 'Agent-facing usage guide' covering tool map, engine semantics, status contract and safe usage patterns. This clearly separates it from the sibling search/fetch tools, though it does not name which sibling it complements. Verb+resource are concrete and 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?

'Read this before experimenting' gives explicit timing for invocation, and the rate-limit sentence routes the agent to an alternative ('switch to an RSS-based tool') when results are blocked. It provides clear context and a fallback path, but does not enumerate when-not-to-use cases.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuinely non-obvious behavioral context: Google rate-limits this endpoint and results can come back blocked, with a documented recovery strategy. Pagination and output shape behavior are left unstated, keeping it below 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 short, front-loaded fragments with no filler — the resource and outputs come first, caveats second. The parenthetical '(lihat google_web_search)' is a slightly awkward cross-reference but costs little 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?

With an output schema present, return values need no prose, and annotations cover the safety profile. The description fills the remaining gaps an agent needs (engine modes, rate limiting, blocked-result fallback), though it leaves pagination/num semantics unclear.

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 carry the burden. It only documents the `engine` parameter's accepted values (auto/http/proxy/browser); gl, hl, num and page receive no explanation at all, and the schema offers none either.

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 ('Scrape Google Images (tbm=isch)') plus the concrete outputs returned: direct image URLs, page URLs, sizes. This is enough to tell it apart from google_video_search and google_web_search without opening any 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?

Gives real operational guidance: engine selection (auto/http/proxy/browser) and a fallback path ('when the result is blocked, wait or switch to an RSS-based tool'). It does not, however, state when to prefer image search over a sibling like google_web_search, so it stops short of explicit when/when-not routing.

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld), and the description adds genuinely useful behavior: the page is JS-heavy so 'auto' routes to a browser, 'http' is tried first as a cheap path, and Google rate-limits/blocking can occur. That fallback ordering is not derivable from annotations or 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 the resource identity and followed by parameter and rate-limit notes. Slightly informal/mixed-language phrasing but no wasted 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?

With an output schema present, return values need no explanation, and the annotations cover the safety profile. The description supplies the missing rate-limit caveat and engine fallback, so an agent has enough to invoke it correctly; only sibling differentiation and engine enum values are absent.

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 carries the burden and mostly does: currency examples and the empty-string default, plus engine behavior ('http' cheap first, browser for JS-heavy pages). It never enumerates the valid engine values, leaving some ambiguity for a 0%-coverage 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 resource: Bank Indonesia transaction rates (buy/sell) from the official BI table. Clear verb+resource, though it never explicitly distinguishes itself from sibling google_fx_rate, which an agent might reasonably 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?

Provides operational guidance (wait or switch to an RSS-based tool when blocked) but gives no explicit when-to-use-this vs google_fx_rate or other rate tools. Currency semantics ('kosong = semua') are implied usage rather than selection 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?

Annotations already establish the read-only, idempotent, non-destructive, open-world profile. The description adds a trait annotations cannot express: Google rate-limits this endpoint, so rapid repeats may be blocked and recovery requires waiting or switching tools. That is materially useful operational 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?

Two sentences, purpose front-loaded, no filler. The second sentence is dedicated to the one non-obvious operational risk, so every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema covers return values and annotations cover safety, so those are not needed here. The remaining gap is the unexplained locale parameters, which matter for correct invocation of a region-varying feed but are absent from both the description and the schema.

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

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

All three locale parameters (gl, hl, ceid) have 0% schema description coverage, and the description says nothing about them. For a region/language-sensitive endpoint, the agent gets no explanation of what gl, hl, or ceid control or how they interact, so the description fails to compensate 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 and resource ('Scrape Google News homepage RSS') plus the payload ('top headlines right now'), which cleanly distinguishes it from the sibling google_news_search by scope (homepage feed vs. query). It does not name that sibling explicitly, so differentiation is implicit rather than explicit.

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?

Provides a conditional fallback ('when the result is blocked, wait or switch to an RSS-based tool'), which is genuine usage guidance. However it never states when to prefer this over google_news_search, and the 'RSS-based tool' alternative is left unnamed, so routing remains inferential.

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

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

Annotations already cover readOnly/openWorld/idempotent, so the bar is lower, and the description still adds genuinely useful behavior: RSS-first vs rendered fallback, the Camoufox browser path, rate-limit exposure, and the blocked-result recovery path. It does not contradict any annotation.

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?

Compact and front-loaded on the core operation, with the engine list and rate-limit note each earning their place. The mixed Indonesian/English phrasing and sentence fragments ('fallback tab News renderan bila RSS gagal') reduce immediate parseability for a general agent.

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 annotations carry the safety profile. What remains missing is documentation of the five non-engine parameters, which is a notable gap given 0% schema coverage.

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 params. The description meaningfully documents the 'engine' values (auto | http (RSS only) | proxy | browser), which the schema does not enumerate, but leaves query, gl, hl, num, and ceid completely unexplained. Partial compensation only.

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 (scrape Google News) and even describes the internal two-strategy mechanism (RSS first, rendered News tab fallback). It does not distinguish itself from the sibling google_news_homepage, so it falls 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?

Adds real operational guidance: engine modes, and a warning that Google rate-limits and that one should wait or switch to an RSS-based tool when blocked. However, it never names the specific alternative sibling (e.g. google_news_homepage) nor states when this tool is preferable to google_web_search or google_search.

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

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

Annotations already declare readOnly, idempotent, non-destructive behavior, so the bar is lower; the description adds real value with the rate-limit/blocking disclosure and the wait-or-switch remediation. It does not note pagination termination or result caps, but the blocking behavior is the operationally important trait.

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 return fields, then the page gotcha, then the rate-limit caveat. Short and generally well ordered, though the 'url= query string' wording is slightly confusing given no url parameter exists in the schema.

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 prose. The gaps are the undocumented num parameter and the absence of any query-format guidance for a patent search endpoint, which is a meaningful omission for a scraper-style 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%, so the description must compensate. It does explain that page is 1-based and, crucially, that the page number lives inside the url= query string rather than as an outer param — a non-obvious trap. But num (result count) and the query syntax itself go entirely 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?

States a specific verb ('Scrape Google Patents XHR JSON') and enumerates the returned fields (title, number, inventors, dates, PDF), which cleanly separates it from the scholar/news/shopping siblings. An agent can tell what this does and what it yields 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?

Usage context is only implied — it is for patent lookups, and the description redirects to an 'RSS-based tool' when results are blocked, which is a genuine alternative signal. However, no guidance is given on when to prefer this over other search siblings or on what query forms are valid.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds real behavioral context beyond them: the engine modes and the fact that Google rate-limits these calls and may return blocked results. It does not describe pagination behavior or result volume, but the added characteristics are substantive.

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, then engine options and the rate-limit caveat, with no filler. The mixed-language cross-reference '(lihat google_web_search)' is slightly opaque to an English reader but costs little 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 described, and the rate-limit warning is a genuine completion of the picture. What is missing is any explanation of the pagination parameters an agent must set to page through citing papers, which is a meaningful gap for a scraper 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 description coverage is 0%, so the description must carry the burden, and it only partially does: it explains cluster_id's source and lists engine options. The pagination parameters (num, start) and hl are never explained in either place, leaving three of five parameters 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?

States a specific verb ('scrape') and resource ('papers citing a Scholar cluster') and clarifies the input's origin ('cluster_id from scholar results'), which cleanly separates it from google_scholar_search. It stops short of explicitly naming that sibling as the tool to call first, so it is clear but not fully differentiated in prose.

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

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

Gives implied context via the parenthetical pointing to cluster_id from scholar results, and the rate-limit note ('avoid rapid repeats; when the result is blocked, wait or switch to an RSS-based tool') is useful operating guidance. However, it never states explicitly that you must run google_scholar_search first, nor names a concrete sibling alternative for fallback.

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

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

Annotations already mark readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds a useful rate-limit warning and fallback to an RSS-based tool, but does not say whether results are cached, how blocking manifests, or what the response includes despite having an output schema. It adds context but not rich operational detail.

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 a compact list: purpose first, then parameter notes, then rate-limit caution. It is well front-loaded with no filler sentences, though the 'lihat google_web_search' reference is slightly opaque and parameter lines are terse.

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 7 parameters at 0% schema coverage and an output schema present, the description should at least name the missing parameters or their intent. It adds the rate-limit fallback and covers two parameters, but leaves the remaining five untouched, which is thin for a tool with an open-world, network-heavy 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%, so the description must compensate fully. It explains only 'start' (0-based offset) and 'engine' (auto|http|proxy|browser) and gives a default for neither. It omits 'query', 'hl', 'num', 'year_low', 'year_high' entirely, so five of seven parameters are left 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 description names the resource (Google Scholar) and enumerates what is returned (papers, authors/venue, citations, PDF links), so an agent understands what it does. However, it does not differentiate from siblings like google_web_search or google_scholar_cited_by; a scholar-specific sibling is not addressed.

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 usage context is only implied by the mention of 'start' for pagination and 'when the result is blocked, wait or switch to an RSS-based tool.' There is no explicit statement of when to pick this over google_web_search or google_scholar_cited_by.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: Google rate limiting on repeated calls, and engine-mode semantics (auto does HTTP with browser fallback when blocked, proxy forces a proxy pool, browser uses Camoufox directly).

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, and the parameter-by-parameter lines earn their place for a 7-param tool. The Indonesian parentheticals ('HTTP cepat, fallback browser bila diblokir', 'paksa pool proxy', 'langsung Camoufox') and irregular line wrapping hurt readability and are not universally parseable.

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. For a broad multi-surface search tool the description covers pagination, rate limits, and engine fallback adequately; the only real omission is the meaning of gl/hl and any explicit sibling-routing rule.

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 description must carry the load, and it does for four of seven parameters: tab (nine named values), page (1-10, news slices RSS), num, and engine (auto/http/proxy/browser with fallback behavior). It leaves gl and hl entirely unexplained, which keeps it out of the top band.

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 first sentence states a specific verb and resource ('One search tool for all Google tabs + pagination') and enumerates the covered surfaces via the tab list. It is clear what the tool does, though it never says how it relates to the many specialized siblings (google_web_search, google_news_search, google_image_search, etc.) that appear to overlap with its tab values.

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 a when-not rule — 'Rate-limited by Google: avoid rapid repeats; when the result is blocked, wait or switch to an RSS-based tool' — plus guidance that page/news slices the RSS feed. However, it offers no routing advice for the obvious ambiguity: whether to use tab=web here or call google_web_search, or tab=news vs google_news_search.

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

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

Annotations already declare the safe read-only, idempotent, open-world profile, but the description adds real behavioral context beyond them: Google rate-limiting, what happens when a request is blocked, and the fallback strategy. It does not describe pagination behavior or result size, 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?

The purpose is front-loaded in one line and the follow-on notes are short and non-redundant. Minor friction: the parenthetical is partly in another language ('lihat google_web_search') and the engine line is fragmentary, slightly hurting readability.

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, and annotations cover the safety profile. The description is complete on operational constraints and fallback, but the thin parameter coverage across 6 params is the one real completeness gap.

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 carry the burden and largely does not. It only hints at engine modes (auto | http | proxy | browser, deferred to google_web_search), leaving gl, hl, num, and start entirely unexplained; the agent must guess country, language, count, and pagination offset 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), a specific resource (Google Shopping, tbm=shop), and the exact return payload (product title, URL, snippet). This clearly distinguishes it from siblings like google_web_search and google_image_search without needing to open 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?

It gives useful operational guidance (avoid rapid repeats, wait when blocked, switch to an RSS-based tool) but never states when to prefer this tool over google_web_search or other google_* siblings. Usage is implied rather than directed, so it lands at minimum-viable with real gaps.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real value beyond that: Google-side rate limiting, the meaning of a blocked result, remediation steps, and the diagnostic payload returned (proxy pool, cache, cooldowns, counters).

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: the first front-loads what the tool reports, the second front-loads the operational constraint and remedy. No filler or repetition of the 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 zero parameters and an output schema already present, the description only needs to convey purpose, rate-limit behavior, and failure handling - all of which it does. An agent has everything required to call it and interpret a blocked result.

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 no parameters and the schema is fully covered, so there is nothing for the description to clarify. Baseline applies; the sentence about blocked results usefully explains result-state semantics rather than argument 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+resource: a health check of which Google endpoints are reachable from the current IP, and enumerates the returned diagnostics (proxy pool, cache, cooldowns, forensic counters). This cleanly distinguishes it from every search/crawl sibling in the 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?

Gives concrete when-not-to-do guidance - 'avoid rapid repeats' and, when blocked, 'wait or switch to an RSS-based tool' - which names a fallback class. It lacks an explicit positive trigger (e.g. 'call this first to diagnose reachability before running a search'), so it stops just short of a full when/when-not pairing.

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

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

Annotations already declare readOnly/idempotent/openWorld, so the bar is lower, and the description still adds genuinely useful context: Google rate-limits this endpoint and results can come back blocked, with a recommended recovery path. It does not describe the shape or reliability of results beyond the blocking caveat.

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 the capability front-loaded and the operational caveat second; no filler or repetition.

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, but with 0% schema coverage the description leaves both parameters undefined and never clarifies what 'no block' means. Adequate for the operation itself, 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% for two parameters, and the description says nothing about either. In particular 'hl' (default 'en') is never identified as a language code nor is the expected format given for 'query', so the description does not compensate for the schema 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 resource (Google autocomplete suggestions) with a qualifier, so an agent can tell it apart from the many sibling search tools. The parenthetical '(no block)' is cryptic and not explained anywhere, which slightly muddies the purpose.

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

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

Gives behavioral usage guidance ('avoid rapid repeats', 'when blocked, wait or switch to an RSS-based tool'), which implies when the tool fails and what to do. However, it never says when to prefer this autocomplete tool over sibling search tools like google_search or google_web_search, so selection guidance is only implied.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower; the description adds genuinely useful context by disclosing that the endpoint is unofficial, keyless, rate-limited, and can return blocked results. It stops short of describing retry timing or response shape, but that is a modest gap given the 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?

Two tight sentences with zero filler; the core purpose and the endpoint caveat are front-loaded before the rate-limit warning.

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 failure behavior is covered. However, with three parameters at 0% schema coverage, the description is not complete enough for an agent to know how to fill source/target 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% and the description says nothing about text, source, or target. It never explains that source defaults to 'auto' or that target defaults to 'en', nor the expected language-code format, so the undocumented parameters are left entirely unexplained.

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 (Translate) and resource (text) plus the underlying mechanism (Google's unofficial gtx endpoint, no key). No sibling does translation, so it is trivially distinguishable from the search/finance/trends tools listed.

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

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

Gives operational guidance: avoid rapid repeats, and when results are blocked, wait or switch to an RSS-based tool. This is clear failure-mode routing, but it never says when to prefer this over any listed sibling or what to do for other translation needs.

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

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

Annotations already declare read-only, idempotent, open-world, non-destructive behavior, so the bar is lower; the description still adds genuinely new context about Google rate-limiting/blocking and the retry-or-switch strategy. It stops short of describing pagination or result size, but the rate-limit disclosure is meaningful added 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 short sentences, zero filler, with the core purpose and the return fields front-loaded ahead of the rate-limit caveat. Appropriately sized for a simple two-parameter feed tool.

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 and annotations cover the safety profile, so return values and safety need not be explained. However, with two undocumented parameters and no guidance on locale/region semantics, the definition is adequate but leaves a real gap an agent would hit on first call.

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 both parameters (hl, geo), so the description carries the full burden of explaining them — and it mentions neither. An agent gets no hint that hl controls language/locale or geo controls the region for the trend 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+resource (daily trending searches) and enumerates the returned fields (topic, traffic, links), which distinguishes it from the sibling google_trends_interest (interest-over-time) without naming it. Clear, but the sibling differentiation is only implicit.

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?

Offers operational guidance on rate limits ('avoid rapid repeats', 'wait or switch to an RSS-based tool') but never says when to choose this tool over the closely related google_trends_interest. Usage context is implied rather than explicit.

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

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

Annotations already cover read-only/open-world/idempotent/non-destructive, but the description adds real behavioral context beyond them: HTTP 400/401 rejections from the widgetdata endpoint, the auto engine's Camoufox in-page fetch that carries cookies/fingerprint, the 'limited' status outcome, and Google-side rate limiting. The mixed Indonesian/Malay in the NOTE reduces clarity slightly.

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 and the key parameter hints are front-loaded, but the NOTE is long and partially redundant, and the language switches mid-document (English/Indonesian), which costs readability. The engine parameter is described twice in slightly different terms.

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 description does cover the failure/fallback and rate-limit behavior an agent needs. However, three parameters (hl, tz, geo) are undocumented anywhere, which leaves the definition incomplete for a 6-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 description coverage is 0%, so the description must carry parameter meaning, and it only covers 3 of 6 params: keywords (comma-separated, max 5, with example), timeframe (concrete value examples), and engine (auto/http/browser semantics). hl, tz, and geo receive no explanation in either the schema or the description, leaving real gaps.

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 – Google Trends interest-over-time – and scopes it with the mechanism (internal explore API, no key). The phrase 'interest-over-time' cleanly separates it from the sibling google_trends_daily (daily trending searches), so an agent can route 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?

Usage context is only implied: the tool is for interest-over-time queries, and a fallback is suggested 'when the result is blocked, wait or switch to an RSS-based tool.' The alternative is never named, and there is no explicit when-to-use/when-not guidance versus google_trends_daily or other sibling 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?

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context beyond annotations: rate-limiting by Google, block-then-wait behavior, and an RSS fallback. Return format is not described, but the output schema covers that.

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 lines with the purpose front-loaded and no filler. The mixed-language phrasing ('lihat google_web_search') is slightly rough but costs no meaningful 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?

For a read-only scraper with an output schema, return values needn't be explained. The description covers rate limits and the engine option but leaves four of six parameters (gl, hl, num, start) unaddressed, leaving a gap for pagination and localization semantics.

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 description must carry the burden. It clarifies the 'engine' parameter's allowed values (auto | http | proxy | browser) and points to google_web_search for detail, but leaves gl, hl, num, and start entirely unexplained, so compensation 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?

States a specific verb ('Scrape') and resource ('Google Video Search (tbm=vid)') plus the returned fields (title, URL, snippet). The resource name clearly separates it from google_image_search, google_news_search, and google_web_search, though it never explicitly names a sibling it is not.

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?

Provides operational guidance ('avoid rapid repeats; when blocked, wait or switch to an RSS-based tool'), which implies when the tool fails. But it gives no explicit when-to-use vs the many other search siblings; usage is only implicit from the resource name.

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

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

Annotations already establish readOnly/idempotent/openWorld/non-destructive, so the description adds the higher-value behavioral facts: Google rate-limits this endpoint, rapid repeats should be avoided, and blocked results can be routed to an RSS-based tool. That is meaningful context beyond the annotations.

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

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

The first sentence is well front-loaded and earns its place. The engine block is a dense pipe-delimited list mixing English and Indonesian, which is harder to parse than a clean enumeration would be.

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. The description covers blocking behavior and engine modes, but leaves the locale/pagination parameters (gl, hl, num, start) undefined, which is a gap for a six-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%, so the schema documents none of the six parameters. The description does explain the `engine` values (auto/http/proxy/browser) in useful detail, which is the most complex parameter, but gl, hl, num, start, and query remain completely unexplained anywhere.

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) plus the exact payload returned: organic results, featured snippet, related searches. This clearly distinguishes it from siblings like google_news_search, google_image_search, and google_scholar_search.

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

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

Gives real operational guidance: engine mode selection (auto/http/proxy/browser) and a rate-limit warning with an alternative ('switch to an RSS-based tool') when blocked. However, it never tells the agent when to prefer this over the sibling google_search, and the guidance is partly in Indonesian, reducing accessibility.

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