MCP Recipes

Six ready-to-paste prompts you can run inside any MCP-compatible client (Claude Desktop, Claude Code, Cursor, Windsurf, VS Code) after installing the FourA MCP server.

Each recipe uses foura_auto (the smart default) or one or more of the lower-level foura_single, foura_proxy, foura_browser for a common scraping job. Two ways to use them:

1. Invoke the built-in prompt - every MCP client surfaces server-provided prompts as a slash command or /prompts panel. Pick the prompt, fill in the arguments, run. The MCP server returns the templated workflow; the LLM executes it with the right tools.
2. Copy the prose below into your own chat. Same effect, less discoverable.

The MCP server ships these as native prompts: smart_fetch, scrape_product_page, extract_article, monitor_pricing, check_endpoint_health, bulk_fetch_urls.

Note on large pages (v0.2.0+): by default, response bodies come back inline in structuredContent regardless of size - this works in every MCP client including Claude Desktop. If you're on a client that supports MCP resources/read AND you want token savings on big pages, pass offload_large: true in the tool call. Responses >= 50 KB then come as a resource_link your client fetches on demand. The built-in prompts below assume the default (inline).

Open source on GitHub; on npm as @fouradata/mcp.

Smart fetch (auto): start here

The simplest recipe: hand a URL to foura_auto and let it make bounded attempts across the available request methods. Use it whenever you want the content and do not need to choose the first tool yourself.

Built-in: smart_fetch(url, must_contain?, extract?)

Manual prompt:

Fetch <URL> using foura_auto.

Pass validate.data.accept:["<a string the real page must contain>"] so only the real page counts as success. Auto makes bounded attempts and returns an error if none satisfies the validation.

For a plain follow-up, call foura_single with session.proxy as proxy, session.cookies serialized as a Cookie header, and session.userAgent as a User-Agent header. For JavaScript, pass the session values to the matching foura_browser fields.

Return the content, or extract the requested fields as JSON.

When this is the right recipe: a first attempt where FourA should choose the method, especially when content validation can distinguish a real page from a block page.

1. Scrape a product page

For e-commerce product detail pages, including single-page-app sites and pages behind anti-bot challenges.

Built-in: scrape_product_page(url)

Manual prompt:

Fetch the product page at <URL> using foura_browser - most product pages are single-page apps and need JavaScript to render.

From the response body extract:
- product title
- price (with currency)
- primary product image URL (absolute, not relative)
- availability / stock status
- product SKU or ID if visible

Return as JSON: {"title": "...", "price": 0, "currency": "USD", "image_url": "...", "in_stock": true, "sku": "..."}

When this is the right recipe: a price comparison agent, a back-in-stock notifier, a competitive analysis spreadsheet.

2. Extract an article

For news articles, blog posts, technical documentation, anything where you want clean reading text without nav, ads, and footer noise.

Built-in: extract_article(url)

Manual prompt:

Fetch <URL> using foura_single with unblocker:true. Use plain HTTP first when the article is present in the server-rendered response.

If foura_single returns a 403, captcha page, or empty content, retry the same URL with foura_proxy (maxTries:3) - it routes through a rotating proxy pool.

From the response, extract:
- headline (the main H1, not the page title bar)
- author byline (may be inside .author, [rel=author], itemprop)
- publication date (look for <time>, .published, or JSON-LD)
- main article body (strip navigation, ads, related-content, footer, comments)
- canonical URL (rel=canonical or og:url)

Return as JSON: {"title": "...", "author": "...", "date_published": "ISO8601", "body": "...", "canonical_url": "..."}

When this is the right recipe: a research summarizer, an RSS-of-one-site, a daily news digest.

3. Monitor a price

For pricing pages and product offers, with optional comparison against a target price.

Built-in: monitor_pricing(url, target_price?)

Manual prompt:

Use foura_proxy with maxTries:5 and unblocker:true to fetch <URL>. Pricing pages often have aggressive bot detection, so go through the proxy pool from the start.

Extract the current price (look for visible $/€/£ amounts, JSON-LD Offer schema, [itemprop=price]).

If a target price is provided, compare: report whether current is below/at/above target and the absolute difference.

Return as JSON: {"url": "...", "current_price": 0.00, "currency": "USD", "target_price": 0, "difference": 0, "status": "below|at|above"}

When this is the right recipe: a savings-alert agent, a travel-fare watcher, a B2B competitor pricing tracker.

4. Check endpoint health

For uptime probes and API endpoint validation.

Built-in: check_endpoint_health(url, expected_text?)

Manual prompt:

Use foura_single with GET on <URL>, timeout_ms:5000, and validate.status.accept:[200]. If an expected substring is provided, also set validate.data.accept:["<EXPECTED>"] so the request only counts as success when the body contains it.

Report:
- reachable (true if any response came back, false on connection error/timeout)
- status_code (HTTP code from target)
- total_time_ms (from the total_time field)
- validation_passed (true if status + body validation conditions were met)

Return as JSON: {"url": "...", "reachable": true, "status_code": 200, "total_time_ms": 0, "validation_passed": true}

When this is the right recipe: an external uptime monitor, a deploy smoke test, a third-party API watchdog.

5. Fetch a list of URLs in parallel

For batch jobs where you want metadata about many URLs without inlining their bodies.

Built-in: bulk_fetch_urls(urls)

Manual prompt:

Parse the following comma-separated URLs and fetch each one concurrently using foura_single (unblocker:true).

URLs: <COMMA_SEPARATED>

For any URL that returns 403, captcha page, or empty body - retry that single URL with foura_proxy (maxTries:3).

Return a JSON array, one entry per URL in input order:
[{"url": "...", "status": 200, "success": true, "body_size_bytes": 0, "via": "single|proxy", "error": null}, ...]

Do NOT inline full response bodies in the output - only metadata. If you need body content, call foura_single individually after this report.

When this is the right recipe: a sitemap reachability sweep, a link-rot audit, a "which of these 50 product URLs still exist" check.

6. Choose and reuse a country-scoped exit

Use this when the target must see the request from one of a specific set of countries, including JavaScript pages where proxy selection must happen before browser rendering.

Manual prompt:

First call foura_proxy for the actual target:
{
  "maxTries": 5,
  "exitCountries": ["FR", "GB"],
  "request": { "method": "GET", "url": "<TARGET_URL>" }
}

Treat exitCountries as a strict allowlist. On success, verify that exitCountry is FR or GB and capture the returned proxy ID.

If the page then needs JavaScript, call foura_browser with the returned proxy ID in foura_browser.proxy. Do not start a new proxy selection, because that may choose a different exit.

If foura_proxy returns no_eligible_proxy, preserve the requested country scope and retry later. Change or widen the list only after the user explicitly changes the requirement. Never retry silently without exitCountries.

When this is the right recipe: regional content, licensed markets, geo-specific pricing, or any workflow that needs a verified target-visible country and then reuses the selected exit.

7. Protected page: proxy first, browser when JavaScript is needed

Use a bounded proxy attempt with content validation when a direct request returns a block page. If the validated response succeeds but the desired content still needs JavaScript, reuse that exact proxy ID in the browser. A visible protection vendor is not a guarantee that any method will succeed.

Manual prompt:

Step 1 - call foura_proxy for <TARGET_URL>. Put a string unique to the real page in request.validate.data.accept. If the user supplied an allowed country list, pass it as exitCountries; do not guess country codes.

Step 2 - if the response passes validation and JavaScript is still required, call foura_browser with the returned proxy ID in the proxy field.

Do not call foura_proxy again after a successful selection, because the new call may choose a different exit. If the bounded attempt fails, report the failure honestly instead of claiming support for the target's protection vendor.

When this is the right recipe: a protected target where HTTP can select a working exit but the final content requires JavaScript rendering.

Tips that apply to all of them

• Not sure which tool? Use foura_auto. It picks the method and handles escalation for you. Reach for a specific tool only when you want explicit control.
• Start with foura_single when plain HTTP is enough. Escalate to foura_proxy when the direct request is blocked and to foura_browser when the desired content needs JavaScript.
• Use unblocker:true when the target needs browser-like request headers. Keep content validation in place so a block page does not count as success.
• Validation rules save retries. Set validate.data.fail:["captcha", "blocked"] so an obviously-blocked response counts as failure and triggers retry/proxy escalation, rather than being parsed as success.
• Country scope is strict. A no_eligible_proxy result is not permission to retry without exitCountries; preserve the requirement or ask the user before changing it.
• Large bodies are inline by default (v0.2.0+). Pass offload_large: true to switch to resource_link + resources/read on clients that support those capabilities.

Want a recipe that isn't here?

Email support@foura.ai with the use case. The MCP server ships new prompts at the same cadence as REST API releases.