Skip to main content
Glama

Run a crawl recipe

crawl_recipe

Run a recipe of browser steps against a page: fill a form, click through, paginate, and extract fields. Use crawl instead when you only need a page's HTML.

blocks run in order. The first must be {"type": "start", "details": {"source": "<url>"}}; only its url is used, and no later block may be a start block. Then any of: extract (details: selector, name, property -- e.g. textContent, href, innerHTML), click (selector), input (selector, text), remove (selector), scroll-to-element (selector), wait (seconds), paginate (selector to click, startBlock: the id of the block to rewind to; both blocks need an id), screenshot, save-html, jsonschema, datalayer, extract-variable, add-field.

A recipe of only the start block answers with the page's HTML in content (markdown with output, which is refused for anything longer); anything longer answers with the extracted result in data. expectedOutput "item" folds everything into one object, "list" keeps a row per entry. Spends a flat number of credits. If status is "queued" or "running", call crawl_poll with the job_id to collect it.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "blocks": "<blocks>"
    },
    "name": "crawl_recipe"
  }
}

Input Schema

NameRequiredDescriptionDefault
jsNoRender the page in a browser so javascript runs. Turn off for static pages to pay less.
cityNoThe city inside that country to appear to browse from, as the pool spells it: letters, digits, hyphens or underscores, e.g. berlin or new_york. Requires country. Doubles the price of the crawl.
nameNoA label for the run, seen only in the crawler's logs.
touchNoReport the screen as touch capable. Requires viewport.
blocksYesThe steps, in the order they run. The first is the start block naming the url.
imagesNoDownload the images on the page.
mobileNoTell the page it is on a phone. Requires viewport; pair it with user_agent for sites that sniff it.
outputNoHow the page comes back in `content`: "html" verbatim, or "markdown" -- smaller and easier to read. Free either way.html
adblockNoDrop ads and trackers before the page loads. Free either way.
countryNoThe country to appear to browse from, as a two-letter ISO 3166-1 code such as es, us or de. Free. Required to use city.
premiumNoFetch through the premium proxy pool instead of the standard one. Costs more; use it for targets that refuse ordinary requests.
viewportNoThe window size as WIDTHxHEIGHT, e.g. 390x844. Required for device_scale_factor, mobile, landscape and touch.
landscapeNoReport the screen as landscape. Requires viewport.
user_agentNoThe user agent to send instead of the crawler's own.
wait_untilNoWhen the page counts as loaded. Use domcontentloaded or load for pages that keep a connection open.networkidle2
main_contentNoWith `output` "markdown" only: convert just the page's main block, without navigation, header, footer, sidebars or cookie banners. Falls back to the whole page when no main block with real text is found.
cookies_bannerNoHow to answer cookie banners: accept opts in, reject opts out where the banner allows it, none leaves them on the page.accept
expectedOutputNo"item" folds the output into one object; "list" keeps a row per entry, for recipes that paginate or extract many rows.item
device_scale_factorNoThe device pixel ratio, e.g. 3 for a recent phone. Requires viewport.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / cookies_banner
      Added value: +{
      +  "default": "accept",
      +  "description": "How to answer cookie banners: accept opts in, reject opts out where the banner allows it, none leaves them on the page.",
      +  "enum": [
      +    "accept",
      +    "reject",
      +    "none"
      +  ],
      +  "type": "string"
      +}
  2. Changed2 schema fields changed
    • addedInput schema / properties / main_content
      Added value: +{
      +  "default": false,
      +  "description": "With `output` \"markdown\" only: convert just the page's main block, without navigation, header, footer, sidebars or cookie banners. Falls back to the whole page when no main block with real text is found.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / output
      Added value: +{
      +  "default": "html",
      +  "description": "How the page comes back in `content`: \"html\" verbatim, or \"markdown\" -- smaller and easier to read. Free either way.",
      +  "enum": [
      +    "html",
      +    "markdown"
      +  ],
      +  "type": "string"
      +}
  3. Changed1 schema field changed
    • changedInput schema / properties / wait_until / default
      Previous value: -"networkidle0"New value: +"networkidle2"
  4. Added

TDQS

A4.5/5.0
Behavior4/5

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

Annotations only supply openWorldHint and destructiveHint=false, so the description carries most of the burden and does so well: it discloses required block ordering, that only the start block's url is used, the paginate/startBlock rewinding contract, and the flat credit cost. Return behavior is disclosed (start-only recipe yields HTML in `content`, longer recipes yield `data`, `expectedOutput` shapes the result). It stops short of describing failure behavior or what `data` looks like per block type.

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 purpose and the sibling alternative before the dense block catalogue, and every sentence carries operational information. The middle block list is a long run-on sentence, but it is compact rather than padded.

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 19-parameter tool with no output schema, the description covers the pieces an agent cannot get from structured fields: block ordering rules, result shape, credit cost, and the polling handoff. It could go further on error conditions and how `data` is populated for each block type.

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 description coverage is 100%, so the baseline is 3; the description earns above that by explaining the nested `blocks` structure that the schema leaves generic ('details: selector, name, property -- e.g. textContent, href, innerHTML') and by documenting the paginate id pairing constraint. It does not explain details for several block types (screenshot, save-html, jsonschema, datalayer, extract-variable, add-field), so it isn't exhaustive.

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 ('Run a recipe of browser steps against a page') and immediately enumerates the concrete actions (fill a form, click through, paginate, extract fields). It explicitly distinguishes itself from the sibling `crawl` for the HTML-only case, so an agent can route 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?

Names the alternative tool and the condition that selects it ('Use `crawl` instead when you only need a page's HTML'), and adds a second routing rule for the async case ('If status is queued or running, call `crawl_poll` with the job_id'). Both when-to-use and when-to-use-something-else are stated explicitly.

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