Docs › MCP Reference › MCP Recipes

MCP Recipes

MCP Recipes

Five 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 orchestrates one or more of 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: 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).

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. Most news and blog sites are server-rendered, so HTTP is fastest (200ms-2s).

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. Lock a proxy IP across multiple calls (cross-tool)

When you need consecutive calls to look like they're coming from the same client — for example, scraping a multi-step checkout flow, or grabbing the JS assets of a page after rendering it — pick one working proxy and reuse its ID.

Manual prompt:

First, call foura_proxy with maxTries:5 and a quick probe URL (httpbin.org/ip is fine) to find a working proxy. Capture the returned `proxy` ID (looks like "4DZ3VE").

Then for every follow-up call:
- HTTP request: foura_single with the SAME `proxy` value — same exit IP, you preserve any IP-based session.
- Rendered page: foura_browser with the SAME `proxy` value — the browser exits through the same pool IP.

If a specific proxy ID starts failing mid-workflow, call foura_proxy again with ignoreProxies:["<failed_id>"] to get a fresh one.

When this is the right recipe: scraping pages where the session state is tied to IP, fetching CSS/JS subresources after rendering, A/B testing how a site behaves from a specific country, or any multi-call flow where you want predictable egress.

7. WAF challenge chain (tier-1: Vercel / Cloudflare / Akamai)

The canonical pattern for sites behind a tier-1 WAF challenge — Vercel Security Checkpoint, Cloudflare 'Just a moment', Akamai Bot Manager. Calling foura_browser directly against these targets usually captures the challenge page rather than the post-challenge content — the snapshot fires before the challenge's deferred reload completes. Solve via foura_proxy first (which clears the challenge by trying many exit IPs until one passes), then chain the returned proxy ID into foura_browser.

Manual prompt:

Step 1 — find an exit IP that clears the challenge:
  foura_proxy({
    maxTries: 30,               // tier-1 WAFs typically need this range
    request: { method: "GET", url: "<TARGET_URL>", unblocker: true }
  })
On success the response carries `proxy: "<BASE36_ID>"`. Capture it.

Step 2 — render the post-challenge page through the same IP:
  foura_browser({
    url: "<TARGET_URL>",
    proxy: "<BASE36_ID>"        // reuse the cleared exit
  })

If foura_proxy still fails after 30 attempts with the same block,
the gate is likely a country / ASN allowlist (country-licensed
bookmakers, government sites). Rotation will never help — pivot
strategy (different data source, partner agreement, etc.).

Triggers that should send you to this recipe:

  • foura_single returns status 429 with header x-vercel-mitigated: challenge or cf-mitigated: challenge
  • Body title matches Vercel Security Checkpoint / Just a moment / Attention Required / We're verifying your browser
  • foura_browser directly captures a tiny challenge HTML instead of real content

When this is the right recipe: SPAs hosted on Vercel/Netlify behind Vercel WAF (iqair.com, many React-rendered marketing sites), Cloudflare-protected stores during attack-mode periods, Akamai-protected high-traffic retail.

Tips that apply to all seven

  • Start with foura_single. It's the fastest tool (200ms–2s) and works for the majority of public sites. Escalate to foura_proxy on 403/captcha, foura_browser on missing JavaScript content.
  • unblocker:true is cheap. Adds realistic browser headers at the wire level; sites that gate on User-Agent or accept-encoding sniffing let your request through.
  • 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.
  • Large bodies are inline by default (v0.2.0+). Pass offload_large: true in any tool call to switch to resource_link + resources/read for token savings on big pages — only useful in clients that support resources/read (Claude Desktop currently does not).

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.

Last updated: May 15, 2026
← MCP Server Errors