Skip to main content
Glama
ZenRows
by ZenRows

prepare_domain

Idempotent

Prepares a domain for extraction after a domain_not_prepared error by submitting the host and 1–5 example URLs, then checking status before retrying extraction.

Instructions

Prepare a domain so extract (mode=auto) works on it.

Use this when extract returns error REQS007 with reason domain_not_prepared. Send the domain (the host, e.g. shop.example.com; a leading www. is dropped, and each host is prepared separately) and 1 to 5 example URLs of real pages you want extracted. One works; we recommend 3 or more of the same page type, so pass 3 or more when you can, up to 5 (e.g. 3 product pages: https://www.example.com/products/a, /products/b and /products/c), because Extract compares pages of one type to check the fields it found and fill in fields one page is missing. Several page types can share the 5 (e.g. 3 product pages + 2 search-result pages). It returns at once with status "preparing" and never waits; preparation takes a few minutes and costs no credits. Then call prepared_domain_status about every 30 seconds until status is "ready", and call extract again. Each new domain uses one slot of the account's monthly allowance (prepared_domain_status shows it). A domain already being prepared returns its current status; a domain already prepared returns "ready" at once with already_prepared: true and uses no slot.

Do not call this for REQS007 with reason page_not_recognised: the domain is already prepared and preparing again does not change that answer.

Input Schema

NameRequiredDescriptionDefault
domainYesThe host to prepare, e.g. shop.example.com (a URL is accepted; a leading www. is dropped)
example_urlsYes1 to 5 full URLs of real pages on this domain that you want to extract. One works; we recommend 3 or more of the same page type when you can
idempotency_keyNoOptional. Resending the same key with the same body returns the original submission

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.17.0
    • changedInput schema / properties / example_urls / description
      Previous value: -"1 to 5 full URLs of real pages on this domain that you want to extract, one per page kind"New value: +"1 to 5 full URLs of real pages on this domain that you want to extract. One works; we recommend 3 or more of the same page type when you can"
  2. Addedv2.15.1

TDQS

A4.9/5.0
Behavior5/5

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

Goes well beyond the annotations: returns immediately with status "preparing", never blocks, takes a few minutes, costs no credits, and consumes one slot of the monthly allowance per new domain. It also discloses the already-in-progress and already-prepared short-circuits (already_prepared: true, no slot used), which the idempotentHint alone would not convey.

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?

Purpose and trigger are front-loaded and the polling instructions follow in order. It is dense and slightly repetitive on the 1-vs-3+ example URL point, but nearly every sentence carries operational information.

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?

Covers the full lifecycle an agent needs for a 3-param, no-output-schema tool: trigger, exclusions, immediate return shape, polling cadence, cost, quota impact, and idempotent re-entry behavior. No output schema is needed given the described return statuses.

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

Parameters5/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 real semantics: a leading www. is dropped and each host is prepared separately, and 3+ same-type example URLs are recommended (up to 5) because Extract compares pages of one type to fill missing fields, with page types allowed to share the budget. That is guidance the schema cannot express.

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 — "Prepare a domain so extract (mode=auto) works on it" — and ties it to the sibling tool it unblocks. An agent can distinguish it from extract and prepared_domain_status without opening any 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?

Gives an explicit trigger (extract returns REQS007 with reason domain_not_prepared) and an explicit exclusion (do not call for page_not_recognised, with the reason why preparing again will not help). It also names the follow-up sequence: poll prepared_domain_status, then call extract.

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