Skip to main content
Glama

Web Data API Plan Finder

Find web data API plans by conditions

search
Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum plans returned in each list (default and maximum 5).
detailNosummary returns one source sentence per fact; full returns every recorded fact and sentence.summary
preferredNoNice-to-have conditions; they do not filter, they break ties.
data_regionsNoRegions where data must be stored or processed, e.g. ["EU"]. Different from exit-IP countries.
billing_typesNoAcceptable 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_pagesNoPages 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_typesNoLimit to these product types. Default: every type that can serve the workload.
search_enginesNoSearch 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_concurrencyNoMinimum number of concurrent requests (or browsers) the plan must allow.
monthly_searchesNoSearch requests per month (one results page each).
search_countriesNoISO 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_countriesNoISO 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_pagesNoHow 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_crawlNoPages 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_totalNoTotal 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_typesNoResult 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_usdNoMonthly budget in USD before tax. Compared with listed prices; annual plans use their per-month equivalent.
min_requests_per_minuteNoMinimum request rate the plan must allow, per minute.
browser_seconds_per_pageNoBrowser 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_requiredNoSearch results must be returned in real time (not through a queue).
target_errors_not_billedNoError responses from the target site (e.g. 404) must not be billed.
needs_recurring_free_tierNoThe plan must be usable every month without paying (a free plan with a monthly allowance or a monthly free credit).
failed_requests_not_billedNoRequests 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_pagesNoHow 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_billedNoBilling 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
NameRequiredDescriptionDefault
as_ofYes
notesYes
countsYes
requestNo
assumptionsYes
needs_inputYes
zero_resultYes
full_matchesYes
partial_matchesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources