Web Data API Plan Finder

Server Details

Compare web scraping, crawling and SERP API pricing and limits against your workload and budget

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Last Tested: 2026-10-03 07:42
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.4/5.0

Scored 2026-10-02 09:30 across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose, reinforced by explicit 'Use this when' and 'Do not use this when' clauses. search is for discovery, check_conditions for validating named plans, cost_scenarios for varying workloads, get_details for retrieving full details, and relax_conditions for suggesting condition changes. No two tools overlap in trigger or output.

Naming Consistency4/5

All names use snake_case, which is consistent. However, 'cost_scenarios' is a noun phrase rather than a verb_noun pattern, and 'search' is a bare verb, creating minor deviations from the otherwise consistent verb_noun convention (check_conditions, get_details, relax_conditions).

Tool Count5/5

With 5 tools, the set is well-scoped for a plan-finder domain. Each tool covers a distinct facet: discovery, verification, cost analysis, detail retrieval, and condition relaxation. No tool feels redundant or missing at this count.

Completeness5/5

The tools cover the full lifecycle of finding, evaluating, and adjusting web data API plans: search for discovery, check_conditions for validation, cost_scenarios for scaling analysis, get_details for deep dives, and relax_conditions for fallback guidance. No obvious gaps exist for the stated purpose.

Available Tools

5 tools

check_conditionsCheck plans against conditionsA

Read-onlyIdempotent

Inspect

Use this when: the user names specific plans (by name, id or pricing-page URL) and wants to know whether they meet the workload and conditions, or which plan of the same product is the cheapest that does. Do not use this when: the user has no plans in mind yet (use search). Check specific plans, given by plan id, plan name or pricing-page URL, against the workload and conditions; up to 20 plans in one call are judged against the same conditions. Returns met / not met / unknown per condition with the official source sentence, which plans and billing options each value applies to, and a purchase link. For each plan it also names the cheapest plan of the same product that meets every required condition, with its monthly cost, or null if none does. An ambiguous name or URL returns the candidate plans instead of a guess.

ParametersJSON Schema

Name	Required	Description	Default
`plans`	No	Plans given by provider and plan name (e.g. "ScrapingBee Freelance") or by pricing-page URL, for plans found elsewhere. A name or URL that fits several plans returns the candidates under resolution and no verdict.
`detail`	No	summary returns one source sentence per fact; full returns every recorded fact and sentence.	summary
`offer_ids`	No	Plan ids to check (from search or get_details).
`preferred`	No	Nice-to-have conditions; they do not filter, they break ties.
`data_regions`	No	Regions where data must be stored or processed, e.g. ["EU"]. Different from exit-IP countries.
`billing_types`	No	Acceptable billing: monthly_subscription (A plan with a fixed fee (or minimum commitment) billed every month.) annual_subscription (A plan paid for a year at a time.) pay_as_you_go (No plan fee; a price per unit of use, billed after use or drawn from a balance topped up with any amount.) prepaid_credits (A fixed-size credit pack bought before use, usually with an expiry.) Free plans always qualify.
`monthly_pages`	No	Pages per month by type: plain_html (static pages), javascript (needs rendering), premium_proxy (blocked sites that need residential/premium proxies), javascript_premium_proxy (both).
`search_engines`	No	Search engines whose results the plan must return, each at the plan's search price: google, bing, yahoo, yandex, baidu, duckduckgo, naver, brave (brave is Brave's own index). monthly_searches is the total over all of them.
`min_concurrency`	No	Minimum number of concurrent requests (or browsers) the plan must allow.
`monthly_searches`	No	Search requests per month (one results page each).
`search_countries`	No	ISO 3166-1 alpha-2 codes of the countries whose search results the searches must return (the search engine's country setting, e.g. Google gl), e.g. ["GB","CA"]. Different from exit_ip_countries.
`exit_ip_countries`	No	ISO 3166-1 alpha-2 codes of countries the page requests must exit from, e.g. ["US","DE"]. For search results of a country use search_countries.
`ai_extraction_pages`	No	How many of the pages need their fields extracted by an AI model (from a prompt or a schema, or automatically) without writing selectors. Each page counts in one of the two extraction fields.
`min_pages_per_crawl`	No	Pages one crawl job (from one start URL, following links) must be able to reach. A plan whose crawl has no page cap meets any number; give the size of the largest site to crawl. Different from the monthly page total.
`monthly_pages_total`	No	Total pages per month when the split by type is not known yet. Costs and verdicts then cover every share of JavaScript-rendered pages from 0% to 100% of the total (no premium proxies), and the result lists monthly_pages under needs_input.
`search_result_types`	No	Result types the parsed search response must contain: organic, ads, local_pack, knowledge_graph, people_also_ask, related_searches, shopping, news, images, videos, ai_overview.
`max_monthly_cost_usd`	No	Monthly budget in USD before tax. Compared with listed prices; annual plans use their per-month equivalent.
`min_requests_per_minute`	No	Minimum request rate the plan must allow, per minute.
`browser_seconds_per_page`	No	Browser time per page in seconds, for headless-browser products billed by time. Every plan must then serve pages that take this long: a hosted browser does, a request-based API only when one request may run that long.
`realtime_search_required`	No	Search results must be returned in real time (not through a queue).
`target_errors_not_billed`	No	Error responses from the target site (e.g. 404) must not be billed.
`needs_recurring_free_tier`	No	The plan must be usable every month without paying (a free plan with a monthly allowance or a monthly free credit).
`failed_requests_not_billed`	No	Requests that fail on the provider side (timeouts, blocks, 5xx) must not be billed. A flat monthly price for unlimited requests meets it, since no request is billed on its own; when only success-based billing will do, use only_successful_requests_billed.
`structured_extraction_pages`	No	How many of the pages must come back as JSON fields rather than HTML or text, by any method the plan offers (CSS or XPath selectors, a schema, or AI). When the fields must be found without writing selectors, use ai_extraction_pages instead; each page counts in one of the two.
`only_successful_requests_billed`	No	Billing must count successful requests only: each successful request is charged (or draws credits) and failed ones cost nothing. A flat monthly price for unlimited requests does not meet it, since the price is the same whatever succeeds.

Output Schema

ParametersJSON Schema

Name	Required	Description
`as_of`	Yes
`notes`	Yes
`request`	No
`results`	Yes
`resolution`	No	How each entry of plans was read.
`assumptions`	Yes
`needs_input`	Yes

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds real behavioral context beyond that: a 20-plan batch cap judged against the same conditions, met/not-met/unknown verdicts with the official source sentence, and the notable behavior that an ambiguous name or URL returns candidates rather than guessing. It does not discuss rate limits or cost of the call, 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.

Conciseness4/5

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

Front-loaded with the routing clause, which is exactly what an agent needs first, and the rest is dense with information rather than filler. It is somewhat long and the phrase 'given by plan id, plan name or pricing-page URL' partially restates the opening when-clause, costing a little efficiency.

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

Completeness5/5

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

For a 25-parameter read tool with an output schema, the description covers the routing decision, the batch scope, the verdict semantics, the cheapest-alternative output, and the ambiguity fallback. Nothing an agent needs in order to decide whether and how to call it is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: that plans may be given as provider+name or pricing-page URL and that filtering happens against the same conditions for all plans in a call. The distinction between required and 'preferred' (tie-breaking, non-filtering) is conveyed implicitly through phrasing rather than stated outright.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource ('Check specific plans ... against the workload and conditions') and explicitly distinguishes itself from the sibling 'search' by scoping the case where the user already has plans in mind. An agent can route between check_conditions and search without opening either schema.

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

Usage Guidelines5/5

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

It gives an explicit 'Use this when' clause with the trigger (user names plans by name, id, or pricing-page URL) and an explicit 'Do not use this when' clause pointing at the alternative (use search). This is the textbook when/when-not/alternative pattern.

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

cost_scenariosPlan costs as the workload changesA

Read-onlyIdempotent

Inspect

Use this when: the user asks how the cost changes as the workload grows or shifts, or at what volume another plan becomes the cheapest. Do not use this when: the workload is fixed (use search). Show how web data API plan costs change when the monthly workload changes, for example twice the pages or a larger share of JavaScript pages. Along the path from the current to a target workload it returns the cheapest fully matching plan at both ends, each workload where the cheapest plan changes, and for tracked plans where the cost first steps up, where the plan can no longer cover the volume and where the budget is exceeded. Costs follow published pricing rules (whole packs of extra credits, per-period pack limits, per-connection browser billing, monthly minimums) with official source sentences.

ParametersJSON Schema

Name	Required	Description	Default
`scale`	No	Multiply every monthly count by this factor for the end of the path, e.g. 2 for twice the current workload. Give target or scale.
`detail`	No	summary returns one source sentence per fact; full returns every recorded fact and sentence.	summary
`target`	No	Workload at the end of the path; fields not given keep their current value. Give target or scale.
`offer_ids`	No	Compare only these plans and follow each of them along the path. Default: every plan that can serve the workload, following the cheapest full match at the start.
`preferred`	No	Nice-to-have conditions; they do not filter, they break ties.
`data_regions`	No	Regions where data must be stored or processed, e.g. ["EU"]. Different from exit-IP countries.
`billing_types`	No	Acceptable billing: monthly_subscription (A plan with a fixed fee (or minimum commitment) billed every month.) annual_subscription (A plan paid for a year at a time.) pay_as_you_go (No plan fee; a price per unit of use, billed after use or drawn from a balance topped up with any amount.) prepaid_credits (A fixed-size credit pack bought before use, usually with an expiry.) Free plans always qualify.
`monthly_pages`	No	Pages per month by type: plain_html (static pages), javascript (needs rendering), premium_proxy (blocked sites that need residential/premium proxies), javascript_premium_proxy (both).
`product_types`	No	Limit to these product types. Default: every type that can serve the workload.
`search_engines`	No	Search engines whose results the plan must return, each at the plan's search price: google, bing, yahoo, yandex, baidu, duckduckgo, naver, brave (brave is Brave's own index). monthly_searches is the total over all of them.
`min_concurrency`	No	Minimum number of concurrent requests (or browsers) the plan must allow.
`monthly_searches`	No	Search requests per month (one results page each).
`search_countries`	No	ISO 3166-1 alpha-2 codes of the countries whose search results the searches must return (the search engine's country setting, e.g. Google gl), e.g. ["GB","CA"]. Different from exit_ip_countries.
`exit_ip_countries`	No	ISO 3166-1 alpha-2 codes of countries the page requests must exit from, e.g. ["US","DE"]. For search results of a country use search_countries.
`ai_extraction_pages`	No	How many of the pages need their fields extracted by an AI model (from a prompt or a schema, or automatically) without writing selectors. Each page counts in one of the two extraction fields.
`min_pages_per_crawl`	No	Pages one crawl job (from one start URL, following links) must be able to reach. A plan whose crawl has no page cap meets any number; give the size of the largest site to crawl. Different from the monthly page total.
`monthly_pages_total`	No	Total pages per month when the split by type is not known yet. Costs and verdicts then cover every share of JavaScript-rendered pages from 0% to 100% of the total (no premium proxies), and the result lists monthly_pages under needs_input.
`search_result_types`	No	Result types the parsed search response must contain: organic, ads, local_pack, knowledge_graph, people_also_ask, related_searches, shopping, news, images, videos, ai_overview.
`max_monthly_cost_usd`	No	Monthly budget in USD before tax. Compared with listed prices; annual plans use their per-month equivalent.
`min_requests_per_minute`	No	Minimum request rate the plan must allow, per minute.
`browser_seconds_per_page`	No	Browser time per page in seconds, for headless-browser products billed by time. Every plan must then serve pages that take this long: a hosted browser does, a request-based API only when one request may run that long.
`realtime_search_required`	No	Search results must be returned in real time (not through a queue).
`target_errors_not_billed`	No	Error responses from the target site (e.g. 404) must not be billed.
`needs_recurring_free_tier`	No	The plan must be usable every month without paying (a free plan with a monthly allowance or a monthly free credit).
`failed_requests_not_billed`	No	Requests that fail on the provider side (timeouts, blocks, 5xx) must not be billed. A flat monthly price for unlimited requests meets it, since no request is billed on its own; when only success-based billing will do, use only_successful_requests_billed.
`structured_extraction_pages`	No	How many of the pages must come back as JSON fields rather than HTML or text, by any method the plan offers (CSS or XPath selectors, a schema, or AI). When the fields must be found without writing selectors, use ai_extraction_pages instead; each page counts in one of the two.
`only_successful_requests_billed`	No	Billing must count successful requests only: each successful request is charged (or draws credits) and failed ones cost nothing. A flat monthly price for unlimited requests does not meet it, since the price is the same whatever succeeds.

Output Schema

ParametersJSON Schema

Name	Required	Description
`path`	Yes
`as_of`	Yes
`notes`	Yes
`plans`	Yes	Every plan named above, with the official facts its costs were computed from.
`at_end`	Yes	Up to three cheapest full matches at the target workload.
`counts`	Yes
`request`	No
`tracked`	Yes
`at_start`	Yes	Up to three cheapest full matches at the current workload.
`compared`	Yes
`switches`	Yes	Each workload on the path where the cheapest full match changes.
`assumptions`	Yes
`needs_input`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: it returns the cheapest fully matching plan at both ends of the path, each workload where the cheapest plan changes, and step-up/coverage/budget breach points, plus the pricing rules (whole packs, per-period limits, browser billing, minimums). It does not describe pagination or result sizing, but the output richness is well disclosed.

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

Conciseness4/5

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

Front-loaded with the when/when-not routing, then the output semantics, then pricing rules; each sentence carries information. It is dense and long, but the length is justified by the tool's complexity and no sentence is redundant filler.

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

Completeness4/5

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

For a 27-parameter, nested-object tool with an output schema, the description covers routing, the shape of the path output, and the pricing assumptions that govern the computation. The schema and output schema handle the rest, so it is complete enough to invoke correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so all 27 parameters are already documented; baseline is 3. The description only illustrates scale ('twice the pages or a larger share of JavaScript pages') and the target-vs-scale choice in passing, adding no syntax or format detail the schema lacks.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (shows how web data API plan costs change as workload changes) and immediately scopes it against a named sibling: fixed workload goes to search. An agent can tell this apart from search/check_conditions without opening a schema.

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

Usage Guidelines5/5

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

Explicit 'Use this when' (cost changes as workload grows/shifts, or at what volume another plan becomes cheapest) and 'Do not use this when' with the alternative named (search). Both the trigger and the exclusion are stated outright.

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

get_detailsGet recorded conditions of a plan or productA

Read-onlyIdempotent

Inspect

Use this when: you need every recorded condition, pricing rule and source sentence of one plan or product found by search or named by the user. Do not use this when: you want to compare plans against a workload (use search or check_conditions). Get every recorded condition for one plan or product: value, which plans it applies to, exceptions, official source sentence, check date and purchase link. A product too long for one response comes with one source sentence per fact.

ParametersJSON Schema

Name	Required	Description	Default
`offer_id`	No	A plan id, e.g. "firecrawl-standard".
`product_id`	No	A product id, e.g. "firecrawl-api".

Output Schema

ParametersJSON Schema

Name	Required	Description
`as_of`	Yes
`offers`	Yes
`product`	Yes
`provider`	Yes
`evidence_detail`	No	Present when the product was too long for one response: each fact carries one source sentence. Ask for a plan by offer_id for every sentence.

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: what the response contains (value, applicable plans, exceptions, source sentence, check date, purchase link) and the truncation behavior for long products. It could say more about pagination or limits, but this is solid added value.

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

Conciseness4/5

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

Front-loaded with the when/not-when decision before the description of contents, which is the right ordering. Three sentences, each earning its place, though the closing sentence about long products is slightly cryptic and the middle sentence is dense with a long enumeration.

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

Completeness4/5

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

An output schema exists, so return-value structure need not be explained, and annotations cover the safety profile; the description nonetheless summarizes the payload and the truncation edge case. Together with routing guidance this is nearly complete, with only minor gaps around result limits or pagination.

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

Parameters3/5

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

Schema description coverage is 100% and the schema itself states 'Give exactly one of offer_id or product_id', so parameter semantics are fully documented structurally. The description only loosely implies single-entity scope ('one plan or product') and adds no syntax or format detail beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('get every recorded condition, pricing rule and source sentence of one plan or product') and scopes it to a single entity. It distinguishes itself from siblings check_conditions and search by naming them explicitly. An agent can identify the correct tool without opening the schema.

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

Usage Guidelines5/5

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

Provides an explicit 'Use this when' condition (need all recorded conditions of one plan/product found by search or named by user) and a 'Do not use this when' exclusion that routes to search or check_conditions for workload comparison. Both positive and negative cases are covered with named alternatives.

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

relax_conditionsSmallest condition changes that admit plansA

Read-onlyIdempotent

Inspect

Use this when: search finds no plan or too few plans and the user wants to know which condition to loosen and by how much. Do not use this when: plans already match (use search or check_conditions). When no plan, or too few plans, meet every required condition: for each condition the user can change, returns the smallest change that lets at least one plan meet everything (for example the monthly budget needed, the concurrency available, or one exit-IP country to drop) and the plans it admits with their monthly cost. Also lists plans that fail only because a condition is not stated on the official pages, with the pages checked and the check date, so the user can confirm with the provider.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum plans listed for each change and under confirm_with_provider (default 3).
`detail`	No	summary returns one source sentence per fact; full returns every recorded fact and sentence.	summary
`preferred`	No	Nice-to-have conditions; they do not filter, they break ties.
`negotiable`	No	Conditions the user said can change: monthly_volume, concurrency, rate_limit, monthly_budget, billing_type, free_allowance, failed_request_billing, success_billing, target_error_billing, geo_targeting, data_region, serp_response_mode, serp_localization, serp_result_types, serp_engines, crawl_page_limit. Default: every required condition, each marked ask_user because the user has not said it can change.
`data_regions`	No	Regions where data must be stored or processed, e.g. ["EU"]. Different from exit-IP countries.
`billing_types`	No	Acceptable billing: monthly_subscription (A plan with a fixed fee (or minimum commitment) billed every month.) annual_subscription (A plan paid for a year at a time.) pay_as_you_go (No plan fee; a price per unit of use, billed after use or drawn from a balance topped up with any amount.) prepaid_credits (A fixed-size credit pack bought before use, usually with an expiry.) Free plans always qualify.
`monthly_pages`	No	Pages per month by type: plain_html (static pages), javascript (needs rendering), premium_proxy (blocked sites that need residential/premium proxies), javascript_premium_proxy (both).
`product_types`	No	Limit to these product types. Default: every type that can serve the workload.
`search_engines`	No	Search engines whose results the plan must return, each at the plan's search price: google, bing, yahoo, yandex, baidu, duckduckgo, naver, brave (brave is Brave's own index). monthly_searches is the total over all of them.
`min_concurrency`	No	Minimum number of concurrent requests (or browsers) the plan must allow.
`monthly_searches`	No	Search requests per month (one results page each).
`search_countries`	No	ISO 3166-1 alpha-2 codes of the countries whose search results the searches must return (the search engine's country setting, e.g. Google gl), e.g. ["GB","CA"]. Different from exit_ip_countries.
`exit_ip_countries`	No	ISO 3166-1 alpha-2 codes of countries the page requests must exit from, e.g. ["US","DE"]. For search results of a country use search_countries.
`ai_extraction_pages`	No	How many of the pages need their fields extracted by an AI model (from a prompt or a schema, or automatically) without writing selectors. Each page counts in one of the two extraction fields.
`min_pages_per_crawl`	No	Pages one crawl job (from one start URL, following links) must be able to reach. A plan whose crawl has no page cap meets any number; give the size of the largest site to crawl. Different from the monthly page total.
`monthly_pages_total`	No	Total pages per month when the split by type is not known yet. Costs and verdicts then cover every share of JavaScript-rendered pages from 0% to 100% of the total (no premium proxies), and the result lists monthly_pages under needs_input.
`search_result_types`	No	Result types the parsed search response must contain: organic, ads, local_pack, knowledge_graph, people_also_ask, related_searches, shopping, news, images, videos, ai_overview.
`max_monthly_cost_usd`	No	Monthly budget in USD before tax. Compared with listed prices; annual plans use their per-month equivalent.
`min_requests_per_minute`	No	Minimum request rate the plan must allow, per minute.
`browser_seconds_per_page`	No	Browser time per page in seconds, for headless-browser products billed by time. Every plan must then serve pages that take this long: a hosted browser does, a request-based API only when one request may run that long.
`realtime_search_required`	No	Search results must be returned in real time (not through a queue).
`target_errors_not_billed`	No	Error responses from the target site (e.g. 404) must not be billed.
`needs_recurring_free_tier`	No	The plan must be usable every month without paying (a free plan with a monthly allowance or a monthly free credit).
`failed_requests_not_billed`	No	Requests that fail on the provider side (timeouts, blocks, 5xx) must not be billed. A flat monthly price for unlimited requests meets it, since no request is billed on its own; when only success-based billing will do, use only_successful_requests_billed.
`structured_extraction_pages`	No	How many of the pages must come back as JSON fields rather than HTML or text, by any method the plan offers (CSS or XPath selectors, a schema, or AI). When the fields must be found without writing selectors, use ai_extraction_pages instead; each page counts in one of the two.
`only_successful_requests_billed`	No	Billing must count successful requests only: each successful request is charged (or draws credits) and failed ones cost nothing. A flat monthly price for unlimited requests does not meet it, since the price is the same whatever succeeds.

Output Schema

ParametersJSON Schema

Name	Required	Description
`as_of`	Yes
`notes`	Yes
`counts`	Yes
`changes`	Yes
`request`	No
`assumptions`	Yes
`needs_input`	Yes
`confirm_with_provider`	Yes

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare this a read-only, idempotent, non-destructive, closed-world operation, so the safety profile is covered. The description adds substantive behavior beyond that: it explains that it enumerates a per-condition smallest change, lists admitted plans with their monthly cost, and separately surfaces plans failing only on conditions not stated on official pages along with the pages checked and the check date.

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

Conciseness4/5

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

Front-loads the when/use-not structure in two crisp sentences, then explains the return. Slightly long in the closing sentence but every clause describes distinct output content, so little waste.

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

Completeness4/5

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

Given an output schema exists, the description needn't detail returns, yet it usefully explains the confirm-with-provider edge case. It covers when to use, what it yields, and the caveat about unstated conditions; the only gap is that the negotiable-condition semantics are left to the schema.

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

Parameters3/5

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

Schema description coverage is 100% across 26 parameters, so the schema carries the semantic load and 3 is the baseline. The description adds only examples of what a 'change' can be (monthly budget, concurrency, exit-IP country) rather than per-parameter meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('returns the smallest change that lets at least one plan meet everything') and scopes it precisely to the no-plan / too-few-plans case. An agent can distinguish it from search and check_conditions without opening schemas.

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

Usage Guidelines5/5

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

Explicit 'Use this when' and 'Do not use this when: plans already match (use search or check_conditions)' clauses name the alternatives and the selecting condition. Routing is unambiguous.

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

searchFind web data API plans by conditionsA

Read-onlyIdempotent

Inspect

Use this when: the user wants to know which web data API plans (web scraping, crawling, SERP search result APIs) fit a monthly workload, budget or required conditions, or what one would cost per month at that workload. Do not use this when: the user wants to scrape or search the web itself (this tool reads no pages), needs proxies only, or asks about other kinds of software. Find web data API plans (scraping, crawling, SERP search) that meet required conditions: monthly pages by type (plain HTML, JavaScript rendering, blocked sites that need premium proxies), monthly searches, concurrency, requests per minute, monthly budget before tax, billing type, exit-IP countries, search engines, search-result countries and parsed result types, pages per crawl, data storage region and structured (JSON) or AI extraction. Returns each plan's monthly cost, whether it meets every required condition, and for every condition met / not met / unknown with the official source sentence and check date, plus a purchase link. Plans with an unknown required condition are listed separately as partial matches. If nothing matches, returns how many plans each condition excluded and the cheapest plan that meets all the other conditions.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum plans returned in each list (default and maximum 5).
`detail`	No	summary returns one source sentence per fact; full returns every recorded fact and sentence.	summary
`preferred`	No	Nice-to-have conditions; they do not filter, they break ties.
`data_regions`	No	Regions where data must be stored or processed, e.g. ["EU"]. Different from exit-IP countries.
`billing_types`	No	Acceptable billing: monthly_subscription (A plan with a fixed fee (or minimum commitment) billed every month.) annual_subscription (A plan paid for a year at a time.) pay_as_you_go (No plan fee; a price per unit of use, billed after use or drawn from a balance topped up with any amount.) prepaid_credits (A fixed-size credit pack bought before use, usually with an expiry.) Free plans always qualify.
`monthly_pages`	No	Pages per month by type: plain_html (static pages), javascript (needs rendering), premium_proxy (blocked sites that need residential/premium proxies), javascript_premium_proxy (both).
`product_types`	No	Limit to these product types. Default: every type that can serve the workload.
`search_engines`	No	Search engines whose results the plan must return, each at the plan's search price: google, bing, yahoo, yandex, baidu, duckduckgo, naver, brave (brave is Brave's own index). monthly_searches is the total over all of them.
`min_concurrency`	No	Minimum number of concurrent requests (or browsers) the plan must allow.
`monthly_searches`	No	Search requests per month (one results page each).
`search_countries`	No	ISO 3166-1 alpha-2 codes of the countries whose search results the searches must return (the search engine's country setting, e.g. Google gl), e.g. ["GB","CA"]. Different from exit_ip_countries.
`exit_ip_countries`	No	ISO 3166-1 alpha-2 codes of countries the page requests must exit from, e.g. ["US","DE"]. For search results of a country use search_countries.
`ai_extraction_pages`	No	How many of the pages need their fields extracted by an AI model (from a prompt or a schema, or automatically) without writing selectors. Each page counts in one of the two extraction fields.
`min_pages_per_crawl`	No	Pages one crawl job (from one start URL, following links) must be able to reach. A plan whose crawl has no page cap meets any number; give the size of the largest site to crawl. Different from the monthly page total.
`monthly_pages_total`	No	Total pages per month when the split by type is not known yet. Costs and verdicts then cover every share of JavaScript-rendered pages from 0% to 100% of the total (no premium proxies), and the result lists monthly_pages under needs_input.
`search_result_types`	No	Result types the parsed search response must contain: organic, ads, local_pack, knowledge_graph, people_also_ask, related_searches, shopping, news, images, videos, ai_overview.
`max_monthly_cost_usd`	No	Monthly budget in USD before tax. Compared with listed prices; annual plans use their per-month equivalent.
`min_requests_per_minute`	No	Minimum request rate the plan must allow, per minute.
`browser_seconds_per_page`	No	Browser time per page in seconds, for headless-browser products billed by time. Every plan must then serve pages that take this long: a hosted browser does, a request-based API only when one request may run that long.
`realtime_search_required`	No	Search results must be returned in real time (not through a queue).
`target_errors_not_billed`	No	Error responses from the target site (e.g. 404) must not be billed.
`needs_recurring_free_tier`	No	The plan must be usable every month without paying (a free plan with a monthly allowance or a monthly free credit).
`failed_requests_not_billed`	No	Requests that fail on the provider side (timeouts, blocks, 5xx) must not be billed. A flat monthly price for unlimited requests meets it, since no request is billed on its own; when only success-based billing will do, use only_successful_requests_billed.
`structured_extraction_pages`	No	How many of the pages must come back as JSON fields rather than HTML or text, by any method the plan offers (CSS or XPath selectors, a schema, or AI). When the fields must be found without writing selectors, use ai_extraction_pages instead; each page counts in one of the two.
`only_successful_requests_billed`	No	Billing must count successful requests only: each successful request is charged (or draws credits) and failed ones cost nothing. A flat monthly price for unlimited requests does not meet it, since the price is the same whatever succeeds.

Output Schema

ParametersJSON Schema

Name	Required	Description
`as_of`	Yes
`notes`	Yes
`counts`	Yes
`request`	No
`assumptions`	Yes
`needs_input`	Yes
`zero_result`	Yes
`full_matches`	Yes
`partial_matches`	Yes

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is settled. The description goes further than the annotations by disclosing output semantics: partial matches are separated when a required condition is unknown, and a no-match case returns per-condition exclusion counts plus the cheapest near-miss. It stops short of any latency/cost 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.

Conciseness4/5

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

Front-loaded with the use/do-not-use decision, then the matching criteria, then return behavior — a good information hierarchy. It loses a point for the near-duplicate condition list: the opening paragraph and the following 'Find web data API plans ... that meet required conditions:' sentence both enumerate the same criteria.

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

Completeness4/5

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

For a 25-parameter, zero-required, nested-schema tool with an output schema, the description covers intent, exclusions, the condition vocabulary, and edge-case return behavior including partial matches and no-match diagnostics. Given the output schema exists, return values need not be spelled out, so this is close to complete; only the required/preferred distinction is left implicit.

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

Parameters3/5

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

Schema description coverage is 100% across 25 parameters, so the schema carries the parameter burden and baseline 3 applies. The description only re-enumerates the condition categories already documented in the schema and does not clarify the filtering-vs-tie-breaking role of required vs preferred conditions, which is the one semantic an agent would most benefit from having surfaced.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Find web data API plans') and enumerates exactly what it matches on (monthly pages by type, searches, concurrency, budget, regions, extraction). It does not, however, differentiate from the closest siblings (check_conditions, cost_scenarios), which an agent must infer from usage context alone.

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

Usage Guidelines5/5

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

Explicit 'Use this when' scoping (fit a monthly workload, budget, or required conditions) paired with an explicit 'Do not use this when' exclusion list (scraping/searching the web itself, proxies only, unrelated software). It also states a decisive constraint — 'this tool reads no pages' — that rules out a common misuse.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateOct 2, 2026

Changedrelax_conditions2 fields changed

added

Output schema / properties / changes / items / properties / options / items / properties / admitted / items / properties / meets_all_after_change

Added value: +{
+  "description": "Against the request with this change applied: always true, because only plans that then meet every required condition are listed.",
+  "enum": [
+    true
+  ],
+  "type": "boolean"
+}

changedOutput schema / properties / changes / items / properties / options / items / properties / admitted / items / required

Previous value: -[
-  "offer_id",
-  "offer_name",
-  "provider_name",
-  "billing",
-  "monthly_cost",
-  "meets_all",
-  "was",
-  "facts",
-  "link"
-]New value: +[
+  "offer_id",
+  "offer_name",
+  "provider_name",
+  "billing",
+  "monthly_cost",
+  "meets_all",
+  "meets_all_after_change",
+  "was",
+  "facts",
+  "link"
+]

5 tool updatesOct 2, 2026
- First observedcheck_conditions
- First observedcost_scenarios
- First observedget_details
- First observedrelax_conditions
- First observedsearch

Related MCP Connectors

ScrapeSelect A
com.scrapeselect
Current pricing, cost estimates and recommendations for web scraping APIs, with official sources.
Web Scraping Browser Automation Developer Tools
61
Spider CloudOAuth
cloud.spider
Crawl, scrape, search the web, and automate browsers at scale with anti-bot bypass.
Browser Automation Web Scraping
2
prismcrawlOAuth
io.github.prismcrawl
Live Google, Bing, Amazon, Maps, Yelp & app store data. As low as $0.15/1K successes; failures free.
Web Scraping Search Browser Automation
1
AgentMart Procurement A
online.agentmart
Procure, compare, quote, budget, and execute web extraction or scraping across providers for agents
Browser Automation Web Scraping
81

Related MCP Servers

alterlab-mcp-server
Web Scraping Browser Automation
RapierCraft
A
license
A
quality
A
maintenance
Enables web scraping, structured data extraction, and screenshot capture with automatic anti-bot bypass, supporting JavaScript rendering, proxy rotation, and tiered pricing.
Updated 3 days ago (2026-09-30 11:11 UTC)
25
127 npm
MIT
saas-pricing-extractor
Web Scraping Browser Automation
DataLeadsPRO
F
license
Not graded
quality
B
maintenance
Extracts and structures pricing pages from any SaaS site, including plans, tiers, and features.
Updated 16 days ago (2026-09-17 16:39 UTC)
-
ComparEdge Pricing API MCPofficial
AI & Machine Learning Search Data Platforms
comparedge
F
license
Not graded
quality
B
maintenance
Provides verified pricing data for SaaS, AI tools, and LLMs across 490+ tools. No API key required, returns sourced records with attribution links.
Updated 3 months ago (2026-07-15 11:25 UTC)
3
-
volthq-mcp-server
AI & Machine Learning Finance Monitoring
newageflyfish-max
A
license
Not graded
quality
D
maintenance
Compare AI inference pricing across 9 providers in real time. Routing recommendations, spend tracking, and budget alerts for AI agents.
Updated 5 months ago (2026-04-29 14:30 UTC)
102 npm
MIT