Skip to main content
Glama

Web Data API Plan Finder

Plan costs as the workload changes

cost_scenarios
Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scaleNoMultiply every monthly count by this factor for the end of the path, e.g. 2 for twice the current workload. Give target or scale.
detailNosummary returns one source sentence per fact; full returns every recorded fact and sentence.summary
targetNoWorkload at the end of the path; fields not given keep their current value. Give target or scale.
offer_idsNoCompare 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.
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
pathYes
as_ofYes
notesYes
plansYesEvery plan named above, with the official facts its costs were computed from.
at_endYesUp to three cheapest full matches at the target workload.
countsYes
requestNo
trackedYes
at_startYesUp to three cheapest full matches at the current workload.
comparedYes
switchesYesEach workload on the path where the cheapest full match changes.
assumptionsYes
needs_inputYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources