Pay-per-call web search for AI agents: 10 SERP tools (web, news, images, places, shopping, scholar, videos, extract and more) paid per request in USDC via x402 on Base or Solana. Free trial with the X-Trial header.
Scored across 12 tools
Most tools map to clearly distinct verticals (news, images, places, scholar, shopping, video), but three tools—web_search, batch_search, and search_extract—all perform Google web search and their boundaries rest mostly on pricing/volume rather than purpose. An agent must read pricing details closely to pick correctly, and search_extract overlaps with web_search + extract.
All names are snake_case and the majority follow a noun_search pattern (news_search, image_search, places_search), which is highly predictable. Minor deviations (extract, deep_research, ai_visibility_check, search_extract) still read naturally and the verb-first ones describe their action clearly.
Twelve tools is well within a sane range for a multi-vertical search API. A couple of entries (batch_search vs web_search) feel like scaling variants rather than distinct capabilities, but nothing is bloated or missing purely on count.
The surface covers web, news, image, video, shopping, scholar, places, batch, extraction, and multi-page research, which is broad lifecycle coverage for a search/data-retrieval service. Gaps are minor: no pagination/offset beyond the 20-result cap, no status/balance or usage-check tool for the x402 payment model, and no job polling for batch work.
For 1-10 keywords, report where a brand/domain ranks on Google plus AI Overview, answer box, People Also Ask and knowledge graph presence, top competitors and a 0-100 score. Paid via x402 ($0.10 USDC flat on Base or Solana); send X-PAYMENT. Not in the free trial.
| Name | Required | Description | Default |
|---|---|---|---|
| gl | No | ||
| brand | Yes | ||
| keywords | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description layers on the details an agent cannot infer: a hard paywall, exact price and currency, two accepted networks, and the required X-PAYMENT header, plus exclusion from the free trial. It also discloses what the report contains, so a caller knows the value returned for the payment. This is precisely the beyond-annotations context that prevents a failed or wrongly-billed call.
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 dense sentences: the first front-loads what is measured and produced, the second front-loads the payment constraint. No filler, no restatement of the title, and the cost gate appears before the agent commits.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately summarizes the returned report fields, and the payment mechanics are fully specified, which is the main complexity here. The gap is the undocumented 'gl' input and the absence of any note on what happens when X-PAYMENT is missing or invalid.
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 full burden. It clarifies that 'brand' also accepts a domain and that keywords are capped at 1-10 (partially redundant with minItems/maxItems), but the 'gl' parameter is never mentioned at all, leaving an agent to guess it is geo/language scoping. With three undocumented schema properties, the description only half-compensates.
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 ('report where a brand/domain ranks on Google') and enumerates the specific outputs: AI Overview, answer box, People Also Ask, knowledge graph, top competitors, and a 0-100 score. This is clearly a brand-visibility audit, which distinguishes it from every sibling (web_search, batch_search, deep_research, extract) that retrieves generic web 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 strong contextual gating: 'Paid via x402 ($0.10 USDC flat on Base or Solana); send X-PAYMENT. Not in the free trial.' That tells an agent when this tool is viable (paid flows only) and when it must route elsewhere (trial users). It stops short of naming a specific alternative for the unpaid case, so it is clear context rather than a full when/when-not routing rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Up to 25 Google web searches in one call via x402 ($0.15 USDC on base). Pass an x402 payment in the X-PAYMENT header.
| Name | Required | Description | Default |
|---|---|---|---|
| num | No | ||
| queries | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, openWorld, and non-destructive, so the description adds genuinely new behavioral context: the exact price ($0.15 USDC on base) and the required X-PAYMENT header. It does not describe what happens when payment is missing or malformed (error shape, whether the request is rejected before any search runs), which is the main remaining gap for a paid 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?
Two short sentences, front-loaded with the capability and then the payment requirement, with no filler. Every clause carries operational information the agent needs.
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 two-parameter tool with no output schema, the description covers the batch capability and the payment gate but leaves the second parameter undefined and says nothing about return shape (presumably per-query result sets) or failures. Adequate to attempt a call, not enough to call it optimally.
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 largely does not. It tells the agent that `queries` holds up to 25 searches, but the `num` parameter (results per query, max 20) is never mentioned and is completely undocumented anywhere. It also does not clarify that pricing is per call rather than per query, which matters for batching decisions.
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 ('Up to 25 Google web searches in one call') plus the batching mechanism, which is the feature that separates it from the single-query web_search sibling. It never names web_search as the alternative, so the 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?
The 'up to 25' limit and the X-PAYMENT requirement imply when this tool applies, and it correctly flags a precondition (payment) that must be satisfied before calling. However, there is no explicit statement of when to choose this over web_search, nor what to do when only one query is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Google, read the top 3-8 pages in parallel and return a concise cited brief with source excerpts. Paid via x402 ($0.08 USDC on Base or Solana); send X-PAYMENT. Not in the free trial.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | ||
| q | No | ||
| query | No | ||
| maxChars | No |
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 behavior: x402 payment of $0.08 USDC on Base or Solana, the required X-PAYMENT header, and exclusion from the free trial — all critical for an agent that could otherwise fail on an unpaid call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly packed sentences with zero filler; the capability comes first and the payment prerequisite follows immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema the description does explain the return shape (cited brief with source excerpts), and it covers payment. But for a 4-parameter tool with 0% schema coverage and duplicated query fields, the missing parameter guidance leaves the definition short of 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%, so the description carries the full burden, and it only partially delivers: 'top 3-8 pages' maps to the n parameter's 3-8 bounds. The ambiguous pair q vs query and the undocumented maxChars are left entirely unexplained, which will cause malformed calls.
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?
Names a specific pipeline: search Google, fetch the top 3-8 pages in parallel, and return a cited brief with excerpts. This clearly distinguishes it from single-step siblings like web_search, extract, and search_extract.
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 'Not in the free trial' note hints at availability constraints, and the multi-page synthesis framing implies when to prefer it over a plain search. However, it never explicitly states when to choose this over search_extract or batch_search, nor what inputs make it worthwhile.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a public URL and return clean markdown via x402 ($0.003 USDC on base). Pass an x402 payment in the X-PAYMENT header.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| maxChars | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety traits like readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds important context beyond annotations: the tool is paid via x402 at $0.003 USDC on Base and requires an X-PAYMENT header.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tightly written sentences with no wasted wording. Purpose and the critical payment constraint are front-loaded and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read-only tool with no output schema, the description covers the core purpose, output format, and payment requirement. The main gap is the undocumented maxChars parameter, which is missing from both the schema and the description.
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, but it only clarifies that the url parameter should be a public URL. The maxChars parameter is not mentioned at all, leaving its meaning and constraints 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 states a specific verb and resource: fetch a public URL and return clean markdown. This clearly distinguishes extraction from the sibling search tools, though it does not explicitly contrast with the similarly named search_extract 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?
The description implies usage by saying it fetches a public URL and returns markdown, which helps an agent infer when to use it. However, it provides no explicit when-to-use guidance versus alternatives such as search_extract or web_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Google Images results (title, page url, imageUrl, thumbnail, size) for one query, up to 20. Paid via x402 ($0.01 USDC on Base or Solana); send X-PAYMENT, or X-Trial: 1 for free trial calls.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| gl | No | ||
| num | No | ||
| query | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish read-only, open-world, idempotent, and non-destructive behavior. The description adds valuable behavioral context beyond annotations: it states that the tool is paid, gives the exact price and chains, and specifies the X-PAYMENT and X-Trial headers for paid and free-trial calls.
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 tight, front-loaded sentence that packs result fields, result limit, pricing, chains, and payment headers without unnecessary wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description helpfully lists return fields and explains payment mechanics. However, with 0% schema description coverage, it is not complete enough for the ambiguous four parameters or for choosing this tool over search siblings.
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 for the four undocumented parameters. It partially clarifies that one query is used and that results are capped at 20, but it does not explain the difference between q and query or what gl controls, leaving significant ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns Google Images results for one query, with specific result fields and a cap of 20. It distinguishes itself from other search siblings by naming Google Images, though it does not explicitly call out alternative search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus siblings like web_search, shopping_search, or video_search. The image-search purpose is implied, but no when-to-use or when-not-to-use conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paid Google News search via x402 ($0.01 USDC on base). Pass an x402 payment in the X-PAYMENT header.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| num | No | ||
| query | No |
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 operational context the annotations cannot express: the call is monetized at $0.01 USDC on Base and requires an x402 payment in the X-PAYMENT header. It does not describe failure behavior when payment is missing or insufficient, which keeps it from 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?
Two short sentences, zero padding, with the resource and cost front-loaded before the invocation requirement. It is efficient, though the space saved comes at the cost of the parameter information that should have been included.
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?
A search tool with no output schema and no documented parameters needs the description to say what query field to populate and roughly what comes back. The description covers billing fully but leaves the q-vs-query duplication and the result shape entirely unaddressed, so an agent cannot call 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 description coverage is 0% with three parameters, so the description carries the full burden, yet it says nothing about q, query, or num. Worse, the schema exposes both 'q' and 'query' as untyped strings with no indication of which is authoritative or whether one is an alias, and the description does not resolve that ambiguity or explain the 1-20 bound on num.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Paid Google News search') and adds the payment rail ('x402, $0.01 USDC on base'), so an agent knows exactly what the tool retrieves. It does not explicitly contrast with web_search or other siblings, but the 'News' domain is specific enough for selection.
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 explains the mechanics of the payment but never says when to choose this over web_search or batch_search, nor what happens if the user does not want to pay. There is no guidance on prerequisites such as holding USDC on Base before calling, which is the key gating condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Google Maps/Places results (name, address, rating, phone, website, lat/lng) for one query, up to 20. Paid via x402 ($0.01 USDC on Base or Solana); send X-PAYMENT, or X-Trial: 1 for free trial calls.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| gl | No | ||
| num | No | ||
| query | No | ||
| location | No |
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 genuinely new behavior: cost ($0.01 USDC on Base or Solana), the X-PAYMENT mechanism, and the X-Trial free-trial header. It stops short of describing failure behavior (e.g., what error a missing payment returns) or rate limits, so it is strong but not exhaustive.
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 dense sentences with the resource and return fields front-loaded, then payment mechanics. Every clause carries information; only the long parenthetical field list is borderline, but it does earn its place by describing output without an output 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?
Return shape is well covered without an output schema, but for a 5-parameter tool with no parameter documentation, the ambiguous q/query and gl/location pairs are a real gap the description should have closed. Payment is explained well; input usage is not.
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 5 parameters have 0% schema description coverage, and the description only implicitly maps 'up to 20' to num. The duplicated-looking pairs q/query and gl/location are left completely unexplained, leaving the agent to guess which of each pair to send and what format they expect.
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 concrete verb/resource (Google Maps/Places results for one query) and even enumerates returned fields (name, address, rating, phone, website, lat/lng), which is specific enough to distinguish it from web_search or news_search. It does not explicitly contrast itself with the closest sibling, batch_search, but the 'one query, up to 20' scope implies the split.
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 implied rather than stated: 'for one query' hints that batch_search covers multi-query cases, and the payment instructions tell the agent what headers to send. There is no explicit when-to-use/when-not-to-use statement or named alternative, so an agent must infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Google Scholar results (title, url, snippet, publication, year, citations, pdf) for one query, up to 20. Paid via x402 ($0.01 USDC on Base or Solana); send X-PAYMENT, or X-Trial: 1 for free trial calls.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| gl | No | ||
| num | No | ||
| query | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the bar is lower; the description adds real value by disclosing the paid model ($0.01 USDC on Base or Solana), the X-PAYMENT header requirement, and the X-Trial: 1 free-trial mechanism. It does not cover failure behavior when payment is missing/rejected or any rate limits, which keeps it short of 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?
Two sentences, front-loaded with the returned data shape, then the payment mechanics. Every clause carries information; nothing is redundant or padding.
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 search tool with no output schema, listing the return fields and payment headers is the right coverage, and 0 required parameters lowers the risk. However, the unresolved q vs query duplication and the undocumented gl parameter leave the agent with genuine ambiguity about how to call it.
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, yet it only implicitly maps 'up to 20' to the num parameter. The two competing query parameters (q and query) are never disambiguated, and gl is completely unexplained, leaving an agent guessing which field to populate.
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 Scholar results'), the exact fields returned (title, url, snippet, publication, year, citations, pdf) and a scope cap ('up to 20'). 'Google Scholar' implicitly separates it from web_search/news_search siblings, though no sibling is named directly.
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 'for one query' hints that batch_search exists for multi-query use, but this is inference rather than an explicit alternative. There is no guidance on when to prefer this over web_search or search_extract, and no stated prerequisites beyond payment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Google web search plus clean markdown of the top N results (1-5) via x402 ($0.02 USDC on base). Pass an x402 payment in the X-PAYMENT header.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | ||
| q | No | ||
| query | No | ||
| maxChars | No |
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 operational context the annotations lack: pricing ($0.02 USDC on base) and the required X-PAYMENT header, which is exactly the kind of auth prerequisite that belongs in prose. It does not say what happens if payment is missing or rejected, which caps 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?
Two dense sentences with no filler, and the core operation is front-loaded before the payment detail. The '(1-5)' parenthetical duplicates the schema's minimum/maximum and is the one wasted token.
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 four-parameter, zero-coverage, no-output-schema tool, the description does not do enough: it never explains the q/query duplication, ignores maxChars, and gives no sense of what the markdown payload looks like or how failures/payment errors surface. The payment detail is a strength but is not sufficient to make the definition callable with confidence.
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 four parameters, so the description must compensate and largely fails. It clarifies only n (and merely restates the 1-5 bound already encoded in the schema's min/max), while leaving the duplicate q vs query parameters completely unresolved and maxChars entirely undefined.
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 compound operation: Google web search plus clean markdown extraction of the top N results. That distinguishes it from the pure-listing siblings (web_search, extract) by making the combined search+extract behavior explicit, though it never states the distinction outright.
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 choose this over web_search, extract, or batch_search, and no guidance on when the paid path is preferable to the free siblings. The only conditional information is the payment mechanic, not tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Google Shopping product results (title, price, store, rating, url, image) for one query, up to 20. Paid via x402 ($0.01 USDC on Base or Solana); send X-PAYMENT, or X-Trial: 1 for free trial calls.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| gl | No | ||
| num | No | ||
| query | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description carries the payment protocol information that annotations cannot: $0.01 USDC on Base or Solana, an X-PAYMENT header, and X-Trial for free calls. That is genuinely valuable context beyond readOnlyHint/idempotentHint, but it does not describe rate limits, failure modes when payment is missing, or pagination 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 tightly packed sentences: result shape and cap first, then payment mechanics. No filler, though the payment sentence is dense enough to require careful parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the field list is a useful stand-in for return values, and payment/auth is covered. However, the unexplained gl parameter and the q/query ambiguity leave real gaps for a paid, four-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% across four parameters, so the description must compensate and largely does not. 'One query' and 'up to 20' loosely map to q/query and num, but the duplicate q vs query parameters are never explained and gl (geolocation) is completely 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+resource ('Google Shopping product results') and enumerates the returned fields (title, price, store, rating, url, image) with a result cap of 20. It does not differentiate itself from siblings like web_search or image_search, 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?
Nothing indicates when this tool should be chosen over the nine sibling search tools. The phrase 'for one query' hints at single-query scope, but there are no exclusions, prerequisites, or alternative-routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Google Videos results (title, url, channel, duration, date, thumbnail) for one query, up to 20. Paid via x402 ($0.01 USDC on Base or Solana); send X-PAYMENT, or X-Trial: 1 for free trial calls.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| gl | No | ||
| num | No | ||
| query | No |
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 material behavior beyond that: a $0.01 USDC charge on Base or Solana, the required X-PAYMENT header, the trial escape hatch, and the 20-result cap. It omits error/failure behavior on unpaid calls and any rate-limit or quota 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 tightly packed sentences with the resource and return shape front-loaded and payment mechanics second. Nothing is redundant and no sentence 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 output schema, the inline field list for results is valuable, and the payment model is fully spelled out. But for a 4-parameter tool at 0% schema coverage, the unresolved q-vs-query duplication and the undocumented gl parameter leave real gaps an agent must guess at.
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 parameter burden, and it largely does not. It implies 'one query' and 'up to 20' (matching the num maximum) but never explains gl (geolocation), and critically it does not disambiguate the two duplicated, both-optional query parameters q and query — an ambiguity an agent will hit immediately.
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 verb ('Google Videos results ... for one query') and enumerates the returned fields (title, url, channel, duration, date, thumbnail), so it is clearly distinguishable from image_search, news_search, and web_search. It stops short of a full 5 because it never explicitly routes the agent away from the 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?
There is concrete guidance on how to invoke it commercially (send X-PAYMENT, or X-Trial: 1 for a free trial call), which is the main adoption question for a paid x402 tool. However, nothing says when to choose this over web_search or search_extract, and there is no guidance on what happens when payment is missing or the trial is exhausted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paid web search via x402 ($0.01 USDC on base). Pass an x402 payment in the X-PAYMENT header of the MCP request, or send header X-Trial: 1 for free trial calls (25 per network).
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| num | No | Results, default 10 | |
| query | No | Search query (alias: q) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, open-world, non-destructive semantics, and the description adds the piece annotations cannot express: this call costs $0.01 USDC on Base and requires a payment header. It stops short of explaining what happens on an unpaid or over-quota request (error shape, fallback), which is the main remaining behavioral unknown for a paid endpoint.
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, payment mechanics front-loaded before the trial escape hatch, and no filler. Every clause carries information the agent needs to make a callable request.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and a simple flat input, the description covers the highest-risk unknowns: cost and authorization. It is only incomplete in not differentiating from the ten sibling search tools and not stating failure behavior when payment or quota is exhausted.
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 67% and the description contributes nothing about q, query, or num. More importantly, the schema exposes both q and query as an undocumented alias pair with no required field, leaving the agent to guess which to send and whether both should be set; the description does not resolve that ambiguity.
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 clause names the resource (web search) and the distinctive mechanism (x402 paid), so the agent immediately knows what it does. It never distinguishes this from siblings like news_search, scholar_search, or batch_search, so scope against alternatives must be inferred 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?
It gives concrete invocation guidance: pay via X-PAYMENT header or use X-Trial: 1 for free calls, capped at 25 per network. That is useful procedural context, but there is no guidance on when to choose this over batch_search or a vertical search sibling, and 25 free calls is a hard quota the agent should factor into planning.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
ai_visibility_checkdeep_researchbatch_searchextractimage_searchnews_searchplaces_searchscholar_searchsearch_extractshopping_searchvideo_searchweb_search
Add one secure layer between your agents and this server.