Web Data API Plan Finder

Smallest condition changes that admit plans

relax_conditions

Read-onlyIdempotent

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.

Input Schema

TableJSON 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

TableJSON Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 2, 2026

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"
+]

First observedOct 2, 2026

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.

All Web Data API Plan Finder tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?