oxylabs-mcp

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

Annotation Contradiction: The description states the agent can click links and fill forms, which may modify website/server state, while readOnlyHint=true claims no state modification. No additional behavioral caveats are provided to resolve this conflict.

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

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

The description is front-loaded with the core purpose and uses short, readable sentences. However, 'return the data in the specified format' appears twice verbatim, adding unnecessary 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 description covers the tool's main behavior and the schema dependency, but it misses explicit guidance relative to sibling tools and does not mention the potential side effects of filling forms or clicking buttons. The annotation contradiction further undermines completeness.

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%, but the description adds a valuable cross-constraint: schema is required only when output_format is json, csv, or toon. It also clarifies that task_prompt describes what the browser agent should achieve, going beyond the schema field descriptions.

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 'runs the browser agent' and 'returns data in the specified format.' It enumerates specific interactive capabilities—navigating to URLs, clicking links, filling forms, scrolling—that distinguish it from sibling scraping or crawling 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,' providing a clear use case. However, it does not explicitly mention alternatives or when not to use it, so it stops short of full 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 indicate readOnlyHint=true, so the description need not repeat safety. It adds useful behavioral context such as render_javascript being slower and recommending a try-without-JS-first strategy, plus the conditional schema requirement. This goes beyond the structured fields.

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

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

The description is concise and well-structured: a one-sentence purpose statement followed by three brief, informative notes. Every sentence contributes meaningful guidance without repetition or fluff.

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 tool is moderately complex with 7 parameters and an output schema. The description covers the core purpose, explains key conditional behaviors, and provides usage strategy. It omits details like geo_location, but the schema handles that. Overall sufficiently 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 100%, so baseline is 3. The description adds extra value by explaining the usage strategy for render_javascript and providing an example for return_sources_limit, going beyond the schema definitions.

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 it crawls a website from a starting URL and returns data in a specified format, which is a specific verb+resource. However, it does not differentiate from sibling tools like ai_scraper or universal_scraper, so it misses the full 5.

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

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

It provides some usage guidance for parameters (e.g., schema required for certain formats, try without JS first), but does not explicitly state when to use this tool over alternatives or provide exclusions. The guidance is contextually relevant but incomplete for tool selection.

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

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

The annotation readOnlyHint=true already informs the agent that the tool is read-only, and the description adds no additional behavioral context like crawl depth behavior, output format, or handling of JS rendering.

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 and front-loaded, but it is so terse that it sacrifices clarity and informativeness, under-specifying the tool's purpose.

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?

Despite having a detailed schema and output schema, the overall description is too vague for a tool with 9 parameters and complex crawling behavior. It does not explain the core mapping functionality or edge cases, leaving the agent to infer intent.

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 9 parameters, so the description does not need to explain parameters. The description itself contributes nothing beyond the schema's already detailed parameter definitions.

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 identifies a verb ('mapping') and resource ('website's URLs'), indicating the tool finds URLs on a website. However, 'mapping' is ambiguous and does not differentiate this from similar sibling tools like ai_crawler.

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

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

The description gives no guidance on when to use this tool versus alternatives such as ai_crawler or ai_search. It does not mention any context or exclusions.

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?

The annotations already declare readOnlyHint=true, so the description's job is lighter. The description adds a note about render_javascript for JS-heavy sites, which is a behavioral trait. It does not disclose any failure modes or limitations, but given annotation coverage, a score of 3 is reasonable.

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 at two sentences and front-loaded with the core purpose. It is efficient, but the inaccurate schema-requirement sentence makes it less valuable than it could be. Still, it earns points for brevity and structure.

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

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

For a tool with 5 parameters and multiple sibling scrapers, the description is thin. It omits mention of geo_location, does not explain the 'toon' format, and gives no context for when to choose this over ai_crawler or universal_scraper. The output schema helps, but the description alone leaves significant gaps for an agent.

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%, which would normally warrant a baseline of 3. However, the description contains a factual inaccuracy: it says schema is required only for json/csv, but the schema also lists 'toon' as requiring schema. This misleads the agent about parameter requirements, actively detracting from the schema's clarity.

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's core function: scrape a web page and return data in a specified format. This is a specific verb+resource combination. However, it does not differentiate from sibling scrapers like ai_crawler or universal_scraper, so it lacks explicit distinguishing details.

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

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

The description gives no guidance on when to use this tool versus alternatives such as ai_crawler or ai_browser_agent. It only mentions parameter-level conditions (schema requirement and render_javascript usage), not tool-selection context. This is below the 'implied usage' threshold.

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 readOnlyHint=true, which is consistent with the description. The description adds meaningful behavioral context about return_content returning markdown content and the relationship with ai_scraper, going beyond the annotation. It does not contradict annotations and provides useful operational details.

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, front-loaded with the core purpose, and every sentence contributes useful guidance. There is no fluff or redundant content, making it an efficient and well-structured description.

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

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

Given the tool's complexity, schema coverage, and existing output schema, the description covers the key operational nuances (return_content, ai_scraper, payload). It would benefit from a brief mention of render_javascript or geo_location, but those are already fully described in the schema, so the overall completeness is adequate for an agent to select and invoke the 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 baseline is 3. The description enriches the parameter semantics by explaining that return_content eliminates the need for ai_scraper and that a lower limit is preferable when return_content is True. This adds value beyond the simple schema descriptions.

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 opens with 'Search the web based on a provided query,' which clearly states the tool's verb and resource. However, it does not explicitly differentiate from sibling search tools like google_search_scraper or amazon_search_scraper, only mentioning ai_scraper in the context of return_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?

The description provides explicit guidance on when to use the tool versus an alternative: 'you don't need to use ai_scraper' when return_content is True. It also advises lowering the limit when return_content is True to reduce payload. This is clear context, though it does not cover all sibling alternatives or broader selection criteria.

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?

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.

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.

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

The readOnlyHint annotation provides basic safety information, but the description adds no behavioral context beyond the literal action. It does not disclose output behavior, error conditions, or any side effects, leaving the agent without useful transparency 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 extremely concise, a single sentence with no redundant words. However, it is overly sparse, sacrificing essential explanatory content for brevity.

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

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

Given the tool's complexity and the presence of an output schema, the description is incomplete. It does not explain how user_prompt influences the generated schema, what app_name selects, or what the output will look like, making it difficult for an agent to invoke 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?

The input schema has 0% description coverage, and the description does not explain the meaning or expected format of user_prompt or app_name. While app_name has an enum, user_prompt is ambiguous, and the description fails to relate the parameters to the generated 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 'Generate a json schema in openapi format' clearly states the primary action and resource, distinguishing it from the scraping/agent sibling tools. It lacks specificity about what the schema represents or how the inputs influence it, preventing a perfect score.

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 guidance is provided on when to use this tool versus alternatives, nor are any exclusions or prerequisites mentioned. The description simply states the action without contextualizing its 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 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.

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.