Fetch and process content from specified URLs & sources using the Oxylabs Web Scraper API.
Scored across 10 tools
Tools like ai_scraper and universal_scraper both appear to extract webpage content, while ai_search and google_search_scraper both perform web searches, creating potential selection ambiguity. However, the specialized scrapers for Amazon and Google are clearly distinct.
Most tools follow a noun-based pattern with descriptive prefixes like 'ai_' or platform names, but 'generate_schema' uses a verb_noun structure, breaking the pattern. The 'scraper' suffix is consistent across multiple tools.
With 10 tools, the set is well-scoped for a web scraping server, covering general scraping, crawling, searching, mapping, and specialized platforms without excessive redundancy.
The tool set covers the full lifecycle of web scraping tasks: searching, scraping, crawling, mapping, and schema generation. Specialized scrapers for Amazon and Google add depth, and the universal scraper fills any gaps.
Run the browser agent and return the data in the specified format.
This tool is useful if you need navigate around the website and do some actions. It allows navigating to any url, clicking on links, filling forms, scrolling, etc. Finally it returns the data in the specified format. Schema is required only if output_format is json, csv or toon. 'task_prompt' describes what browser agent should achieve
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to start the browser agent navigation from. | |
| schema | No | The schema to use for the scrape. Only required if output_format is json, csv or toon. | |
| task_prompt | Yes | What browser agent should do. | |
| geo_location | No | Two letter ISO country code to use for the browser proxy. | |
| output_format | No | The output format. Markdown returns full text of the page including links. Toon(Token-Oriented Object Notation) returns data in Toon format, which is optimized for AI agents. If json, csv or toon, the schema is required. | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the agent can click links, fill forms, and perform actions, which implies potentially mutating state or submitting data. This contradicts the annotations readOnlyHint set to true. Because the description directly conflicts with the annotation and also provides no safety/auth/side-effect context, this dimension scores minimal.
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 not excessively long, but it repeats the core idea: the first sentence and the 'Finally it returns...' sentence both say the tool returns data in a specified format. Some sentences are redundant rather than adding new operational guidance.
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 and detailed input-schema provide substantial structure, so this is not a sparse definition. However, the description misses important behavioral context around a browser automation tool, such as side effects from form submission, authentication state, and session behavior; this is made worse by the annotation contradiction.
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 schema already covers all parameters with descriptions at 100% coverage, so the baseline is 3. The description repeats the conditional schema requirement for json/csv/toon and explains task_prompt, but it adds no new information beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly says 'Run the browser agent and return the data' and then lists concrete actions like clicking, filling forms, scrolling, and navigating to URLs. This gives a specific verb/resource and conveys an interactive browser tool, though it does not explicitly name or contrast sibling scraper/crawler tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says the tool is 'useful if you need navigate around the website and do some actions,' which implies an interactive task. However, it provides no explicit guidance on when not to use it or which sibling tool (e.g., ai_scraper, ai_crawler) should be used for static extraction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool useful for crawling a website from starting url and returning data in a specified format.
Schema is required only if output_format is json, csv or toon. 'render_javascript' is used to render javascript heavy websites. 'return_sources_limit' is used to limit the number of sources to return, for example if you expect results from single source, you can set it to 1.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL from which crawling will be started. | |
| schema | No | The JSON schema to use for structured data extraction from the crawled pages. Only required if output_format is json, csv or toon. | |
| user_prompt | Yes | What information user wants to extract from the domain. | |
| geo_location | No | Two letter ISO country code to use for the crawl proxy. | |
| output_format | No | The format of the output. If json, csv or toon, the schema is required. Markdown returns full text of the page. CSV returns data in CSV format. Toon(Token-Oriented Object Notation) returns data in Toon format, which is optimized for AI agents. | markdown |
| render_javascript | No | Whether to render the HTML of the page using javascript. Much slower, therefore use it only for websites that require javascript to render the page. Unless user asks to use it, first try to crawl the page without it. If results are unsatisfactory, try to use it. | |
| return_sources_limit | No | The maximum number of sources to return. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint=true, which the description respects. The description does not add further behavioral details (e.g., no side effects, rate limits, or data retention), but it does not contradict the annotation either. Given the read-only nature is already indicated, the description adds little beyond 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?
The description is verbose and redundant, repeating parameter details that are already in the schema. For example, the URL and render_javascript explanations are duplicated verbatim. This wastes tokens and reduces clarity.
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 is present but the description does not explain the structure or any exceptional behaviors. It briefly mentions returning data in a specified format, but does not elaborate on how the crawl is scoped or what happens with large sites. Given the completeness of the input schema and presence of output schema, the description is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the tool description adds no new parameter information. The prose repeats the schema definitions without clarifying edge cases or relationships, so it meets the baseline but provides no added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool crawls a website starting from a URL and returns data in a specified format. However, it does not differentiate from sibling tools like ai_scraper or universal_scraper, which might also crawl pages.
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 does not explicitly state when to use this tool over alternatives. It implies output format flexibility but lacks guidance on scenarios favoring ai_crawler over other scrapers or search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool useful for mapping website's URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL from which URLs mapping will be started. | |
| limit | No | The maximum number of URLs to return. | |
| user_prompt | No | What kind of URLs user wants to find. Can be used together with 'search_keywords'. | |
| geo_location | No | Two letter ISO country code to use for the mapping proxy. | |
| max_crawl_depth | No | The maximum depth of the crawl. | |
| search_keywords | No | The keywords to use for URLs paths filtering. Keywords are matched as OR condition. Meaning, one keyword is enough to match the url path. | |
| allow_subdomains | No | Whether to map subdomains URLs as well. | |
| render_javascript | No | Whether to render the HTML of the page using javascript. Much slower, therefore use it only for websites that require javascript to render the page. Unless user asks to use it, first try to crawl the page without it. If results are unsatisfactory, try to use it. | |
| allow_external_domains | No | Whether to include external domains URLs. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint: true, indicating a safe read operation, but the description fails to add behavioral context. It doesn't disclose that the tool performs crawling, respects depth limits, or requires JavaScript rendering for some sites. No mention of performance characteristics, rate limits, or edge cases beyond what the schema's parameter descriptions already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is concise but under-specifies the tool's behavior. It's not powerful or informative enough to earn credit for conciseness; rather, it reads as an under-developed placeholder. A good description would front-load the tool's purpose in a way that adds value, but this wastes the opportunity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, a required URL, and complex behaviors like crawl depth, subdomain handling, and JavaScript rendering, a one-sentence description is grossly inadequate. Even though an output schema exists, the description fails to convey the tool's inputs' intent or the meaning of its output. The behavioral nuances (e.g., proxy usage, OR-matching for keywords) are left entirely to the schema, making this incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 9 parameters are documented in the input schema itself. The description adds no parameter semantics; it merely repeats the tool name. Per rubric, with high schema coverage, the baseline is 3, which is appropriate here since the description doesn't need to compensate but also doesn't add value.
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 'Tool useful for mapping website's URLs' uses the vague verb 'mapping' and a possessive phrasing that doesn't define the action clearly. While it names the resource (website URLs), it fails to articulate the core function of discovering or crawling links, leaving the tool's true purpose ambiguous. Sibling tools like 'ai_crawler' and 'ai_scraper' further blur the line, making this description insufficiently specific.
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 provides no guidance on when to use this tool versus any of the nine sibling tools. There is no mention of when ai_map is preferred over ai_crawler or ai_browser_agent, nor any exclusions or prerequisites. Users are left to guess which tool fits their use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scrape the contents of the web page and return the data in the specified format.
Schema is required only if output_format is json or csv. 'render_javascript' is used to render javascript heavy websites.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to scrape | |
| schema | No | The JSON schema to use for structured data extraction from the scraped page. Only required if output_format is json, csv or toon. | |
| geo_location | No | Two letter ISO country code to use for the scrape proxy. | |
| output_format | No | The format of the output. If json, csv or toon, the schema is required. Markdown returns full text of the page. CSV returns data in CSV format, tabular like data. Toon(Token-Oriented Object Notation) returns data in Toon format, which is optimized for AI agents. | markdown |
| render_javascript | No | Whether to render the HTML of the page using javascript. Much slower, therefore use it only for websites that require javascript to render the page.Unless user asks to use it, first try to scrape the page without it. If results are unsatisfactory, try to use it. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description aligns with that (scraping is read-only). The description adds useful behavioral context about render_javascript being slower and the recommendation to try without it first. However, it doesn't disclose potential rate limits, auth requirements, or what happens on failure, which would be valuable for a scraping tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the core purpose. It avoids redundancy with the schema. However, it could be slightly more structured by separating the conditional requirements more clearly, but overall it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and 100% parameter coverage, the description is fairly complete. It covers the key conditional logic (schema requirement, render_javascript usage) and the tool's scope. It doesn't explain return values, but the output schema handles that. Minor gaps: no mention of error handling or edge cases, but acceptable for a scraping 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 100%, so the schema already documents all parameters well. The description adds minimal extra meaning beyond what the schema provides, but it does clarify the conditional requirement for schema and the performance trade-off of render_javascript. This is a baseline 3 since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scrapes web page contents and returns data in a specified format. It distinguishes itself from siblings like ai_crawler (which likely crawls multiple pages) and google_search_scraper (which targets search results) by focusing on a single page scrape with format options.
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 provides clear guidance on when schema is required (for json/csv/toon formats) and when to use render_javascript (for JS-heavy sites, with a recommendation to try without it first). It doesn't explicitly mention alternatives among siblings, but the usage context is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the web based on a provided query.
'return_content' is used to return markdown content for each search result. If 'return_content' is set to True, you don't need to use ai_scraper to get the content of the search results urls, because it is already included in the search results. if 'return_content' is set to True, prefer lower 'limit' to reduce payload size.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return. | |
| query | Yes | The query to search for. | |
| geo_location | No | Two letter ISO country code to use for the search proxy. | |
| return_content | No | Whether to return markdown content of the search results. | |
| render_javascript | No | Whether to render the HTML of the page using javascript. Much slower, therefore use it only if user asks to use it.First try to search with setting it to False. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, which the description doesn't contradict (no annotation_contradiction). The description adds meaningful behavioral context beyond the structurual annotation: markdown content inclusion, payload size implications, and render_javascript's performance trade-off. This goes beyond the minimal safety profile annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences covering tool purpose, a direct workflow tip (ai_scraper avoidance), and a size/performance caution. It's appropriately sized for a tool with this many parameters. Minor redundancy ('if return_content is set to True' appears twice) and a slightly repetitive structure prevent a 5, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter tool with an output schema, the description covers the meaningful decision points: when to use return_content, how to set limit, and when render_javascript is warranted. The geo_location parameter is self-explanatory from the schema, and the output schema exists, so return-format explanation isn't needed. Complete without being bloated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds significant value on top: it explains the functional consequence of return_content (avoiding an ai_scraper round-trip), warns about limit's effect on payload, and gives operational guidance on render_javascript's default-off usage. This exceeds the baseline.
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 a specific verb+resource: 'Search the web based on a provided query.' This is unambiguous and immediately identifiable as the search-tool counterpart among siblings. However, it doesn't proactively distinguish itself from the closely-related google_search_scraper sibling, leaving the differentiation 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?
While not a formal 'when to use' statement, the description provides clear conditional guidance: it explains that when return_content=True, ai_scraper becomes unnecessary, and it recommends lowering 'limit' to reduce payload. The render_javascript guidance ('use it only if user asks to use it') is effectively a when-not-to-use instruction. Exclusions aren't exhaustive, but context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scrape Amazon products.
Supports content parsing, different user agent types, domain, geolocation, locale parameters and different output formats. Supports Amazon specific parameters such as currency and getting more accurate pricing data with auto select variant.
| Name | Required | Description | Default |
|---|---|---|---|
| parse | No | Should result be parsed. If the result is not parsed, the output_format parameter is applied. | |
| query | Yes | Keyword to search for. | |
| domain | No | Domain localization for Google. Use country top level domains. For example: - 'co.uk' for United Kingdom - 'us' for United States - 'fr' for France | |
| locale | No | Set 'Accept-Language' header value which changes your Google search page web interface language. Examples: - 'en-US' for English, United States - 'de-AT' for German, Austria - 'fr-FR' for French, France | |
| render | No | Whether a headless browser should be used to render the page. For example: - 'html' when browser is required to render the page. | |
| currency | No | Currency that will be used to display the prices. | |
| geo_location | No | The geographical location that the result should be adapted for. Use ISO-3166 country codes. Examples: - 'California, United States' - 'Mexico' - 'US' for United States - 'DE' for Germany - 'FR' for France | |
| output_format | No | The format of the output. Works only when parse parameter is false. - links - Most efficient when the goal is navigation or finding specific URLs. Use this first when you need to locate a specific page within a website. - md - Best for extracting and reading visible content once you've found the right page. Use this to get structured content that's easy to read and process. - html - Should be used sparingly only when you need the raw HTML structure, JavaScript code, or styling information. | |
| user_agent_type | No | Device type and browser that will be used to determine User-Agent header value. | |
| autoselect_variant | No | To get accurate pricing/buybox data, set this parameter to true. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation. The description adds some functional context (content parsing, output formats, user agents) but does not disclose potential side effects, rate limits, or return behavior beyond what the schema implies. The annotation is not contradicted, and the added detail provides marginal 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?
The description is two sentences with the purpose front-loaded. The second sentence compactly enumerates capabilities without redundancy. Every word contributes to the overall understanding, and there is no filler or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, 1 required) and rich schema/output schema, the description gives a reasonable high-level overview. However, it does not mention limitations, pagination, or differentiate from similar tools like amazon_search_scraper. The output schema and annotations fill in some gaps, making it minimally complete but not richly contextual.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 10 parameters, so the schema carries the full semantic burden. The description groups parameters into categories and highlights Amazon-specific ones (currency, autoselect_variant), adding conceptual organization but no new factual information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scrapes Amazon products, providing a specific verb and resource. It does not explicitly differentiate from sibling tools like amazon_search_scraper or universal_scraper, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for scraping Amazon products but gives no explicit guidance on when to use it vs. alternatives. It lacks when-to-use/when-not-to-use criteria or exclusion notes, leaving the agent to infer based on the name and general purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scrape Amazon search results.
Supports content parsing, different user agent types, pagination, domain, geolocation, locale parameters and different output formats. Supports Amazon specific parameters such as category id, merchant id, currency.
| Name | Required | Description | Default |
|---|---|---|---|
| pages | No | Number of pages to retrieve. | |
| parse | No | Should result be parsed. If the result is not parsed, the output_format parameter is applied. | |
| query | Yes | Keyword to search for. | |
| domain | No | Domain localization for Google. Use country top level domains. For example: - 'co.uk' for United Kingdom - 'us' for United States - 'fr' for France | |
| locale | No | Set 'Accept-Language' header value which changes your Google search page web interface language. Examples: - 'en-US' for English, United States - 'de-AT' for German, Austria - 'fr-FR' for French, France | |
| render | No | Whether a headless browser should be used to render the page. For example: - 'html' when browser is required to render the page. | |
| currency | No | Currency that will be used to display the prices. | |
| start_page | No | Starting page number. | |
| category_id | No | Search for items in a particular browse node (product category). | |
| merchant_id | No | Search for items sold by a particular seller. | |
| geo_location | No | The geographical location that the result should be adapted for. Use ISO-3166 country codes. Examples: - 'California, United States' - 'Mexico' - 'US' for United States - 'DE' for Germany - 'FR' for France | |
| output_format | No | The format of the output. Works only when parse parameter is false. - links - Most efficient when the goal is navigation or finding specific URLs. Use this first when you need to locate a specific page within a website. - md - Best for extracting and reading visible content once you've found the right page. Use this to get structured content that's easy to read and process. - html - Should be used sparingly only when you need the raw HTML structure, JavaScript code, or styling information. | |
| user_agent_type | No | Device type and browser that will be used to determine User-Agent header value. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only lists supported features (parsing, pagination, user agents, etc.) and does not disclose behavioral traits such as response format, rate limits, or edge cases. The readOnlyHint annotation already indicates a safe read operation, but the description adds little beyond what the schema and annotation provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear opening statement followed by a feature list in two sentences. While every sentence provides relevant information, the list format is somewhat generic and could be better structured by separating capabilities into categories.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 parameters) and the presence of a full output schema, the description offers an adequate high-level overview. However, it omits practical context like when to use parse=false or how pagination behaves, relying on the detailed schema descriptions to cover specifics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description redundantly mentions parameter groups already documented in the schema (e.g., pagination, user agent types, currency) without adding nuanced meaning or context beyond what the schema descriptions offer.
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 begins with a specific verb and resource: 'Scrape Amazon search results.' This clearly distinguishes it from siblings like google_search_scraper and amazon_product_scraper, which target different resources. It further lists Amazon-specific parameters, reinforcing its focused 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?
The description implies usage for Amazon search result scraping but provides no explicit guidance on when to choose this tool over alternatives. It does not mention exclusions or recommend siblings for related tasks, leaving the decision to inference from the tool name and capability list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a json schema in openapi format.
| Name | Required | Description | Default |
|---|---|---|---|
| app_name | Yes | ||
| user_prompt | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not contradict the readOnly annotation, but it adds no context about side effects, limitations, or special behaviors. With the annotation present, the bar is lower, but the description still offers minimal insight beyond the tool's name.
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 single, concise sentence with no fluff, but it is too brief to be informative. It is appropriately sized in terms of length, but the lack of content reduces its effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters and an output schema, the description is severely incomplete. It does not explain expected inputs, outputs, or any relevant context, making it insufficient for a user to understand the tool's full capabilities.
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 description gives no explanation of the parameters user_prompt and app_name. Schema coverage is 0%, and the description fails to compensate with any param-level detail, leaving the user to guess their meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a JSON schema in OpenAPI format, which is a specific action and outcome. It differentiates from sibling tools focused on search and scraping, but could be more specific about the schema's intended use.
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 provides no guidance on when to use this tool versus alternatives, nor any conditions or prerequisites. It lacks explicit when-to-use or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scrape Google Search results.
Supports content parsing, different user agent types, pagination, domain, geolocation, locale parameters and different output formats.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results to retrieve in each page. | |
| pages | No | Number of pages to retrieve. | |
| parse | No | Should result be parsed. If the result is not parsed, the output_format parameter is applied. | |
| query | Yes | URL-encoded keyword to search for. | |
| domain | No | Domain localization for Google. Use country top level domains. For example: - 'co.uk' for United Kingdom - 'us' for United States - 'fr' for France | |
| locale | No | Set 'Accept-Language' header value which changes your Google search page web interface language. Examples: - 'en-US' for English, United States - 'de-AT' for German, Austria - 'fr-FR' for French, France | |
| render | No | Whether a headless browser should be used to render the page. For example: - 'html' when browser is required to render the page. | |
| ad_mode | No | If true will use the Google Ads source optimized for the paid ads. | |
| start_page | No | Starting page number. | |
| geo_location | No | The geographical location that the result should be adapted for. Use ISO-3166 country codes. Examples: - 'California, United States' - 'Mexico' - 'US' for United States - 'DE' for Germany - 'FR' for France | |
| output_format | No | The format of the output. Works only when parse parameter is false. - links - Most efficient when the goal is navigation or finding specific URLs. Use this first when you need to locate a specific page within a website. - md - Best for extracting and reading visible content once you've found the right page. Use this to get structured content that's easy to read and process. - html - Should be used sparingly only when you need the raw HTML structure, JavaScript code, or styling information. | |
| user_agent_type | No | Device type and browser that will be used to determine User-Agent header value. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description 'Scrape' is consistent with a read operation. However, the description adds little beyond the annotations and the parameter schema; it does not mention rate limits, pagination behavior, rendering implications, or antiscraping nuances.
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 only two sentences. The first sentence is a clear, front-loaded purpose statement; the second is a compact capability list. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema and output schema are rich, but the tool description omits several notable parameters like render and ad_mode, and does not explain the parse/output_format relationship. Given the tool's complexity, the description alone provides only high-level context, leaving these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 12 parameters. The tool description only lists categories like 'pagination' and 'geolocation' without adding new meaning; therefore, a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and resource: 'Scrape Google Search results.' This clearly distinguishes the tool from siblings like amazon_search_scraper or ai_search by naming Google Search as the target. The second sentence enumerates key capabilities (parsing, user agents, pagination, etc.), further clarifying scope.
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 for scraping Google Search results but provides no explicit guidance on when to prefer this over ai_search, universal_scraper, or other siblings. It lists supported features but does not state conditions, exclusions, or alternative choices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a content of any webpage.
Supports browser rendering, parsing of certain webpages and different output formats.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Website url to scrape. | |
| render | No | Whether a headless browser should be used to render the page. For example: - 'html' when browser is required to render the page. | |
| geo_location | No | The geographical location that the result should be adapted for. Use ISO-3166 country codes. Examples: - 'California, United States' - 'Mexico' - 'US' for United States - 'DE' for Germany - 'FR' for France | |
| output_format | No | The format of the output. Works only when parse parameter is false. - links - Most efficient when the goal is navigation or finding specific URLs. Use this first when you need to locate a specific page within a website. - md - Best for extracting and reading visible content once you've found the right page. Use this to get structured content that's easy to read and process. - html - Should be used sparingly only when you need the raw HTML structure, JavaScript code, or styling information. | |
| user_agent_type | No | Device type and browser that will be used to determine User-Agent header value. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already indicates a safe read operation. The description adds that browser rendering and parsing are supported, which is useful. However, it does not disclose potential limitations, error behaviors, or the meaning of 'certain webpages', so it adds only modest context beyond the 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?
The description is concise, with two short sentences that front-load the core purpose. It is efficient but contains a grammatical awkwardness ('a content') and vague phrasing like 'certain webpages', preventing a 5.
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 presence of multiple sibling scrapers and a 5-parameter schema, this description is too sparse. It does not explain when to use this generic scraper over specialized ones like amazon_product_scraper, nor does it clarify the render or geo_location options' implications. An output schema exists, which covers return format, but selection guidance is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with detailed parameter descriptions for url, render, geo_location, output_format, and user_agent_type. The tool description adds no additional parameter meaning beyond mentioning 'different output formats', which the schema already details. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets content from any webpage and supports browser rendering, parsing, and output formats. However, it does not differentiate itself from sibling tools like ai_scraper or ai_crawler, 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?
No explicit guidance on when to use this tool versus alternatives. The mention of browser rendering and parsing hints at use cases, but there are no exclusions or comparisons to sibling scrapers, leaving the agent without clear selection criteria.
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_browser_agentai_crawlerai_mapai_scraperai_searchamazon_product_scraperamazon_search_scrapergenerate_schemagoogle_search_scraperuniversal_scraperFetch and process content from specified URLs using the Oxylabs Web Scraper API.
Fetch and extract data from any public web page, even JS-rendered or anti-bot protected
Fetch any public web page through managed proxies, with optional JS rendering and extraction rules.
Crawl, scrape, search the web, and automate browsers at scale with anti-bot bypass.
Add one secure layer between your agents and this server.
