BrightData MCP: AI Web Scraping Guide (5000 Free Requests)

BrightData MCP is a web scraping MCP server that gives AI agents live access to the web. Point Claude Code, Cursor, Windsurf, or Droid CLI at it and your assistant can pull structured Amazon data, LinkedIn profiles, Google results, or the clean Markdown of any page, without you writing a scraper or babysitting proxies. The free tier includes 5,000 free requests every month.

So what if your AI assistant could reach Amazon, LinkedIn, Instagram, or any other site in real time and never get blocked? That is what BrightData MCP promises, and it mostly holds up. Where it doesn’t, I’ll say so.

This guide covers setup for four clients, what the free tier actually covers, what each tool costs in requests, how to verify it works in 30 seconds, how to keep the token out of a public repo, and how to remove it all again.

What is BrightData MCP?

BrightData MCP is a web scraping MCP server that gives AI agents live access to the web. Model Context Protocol is the part that matters: scraping is exposed as tools, so “go fetch this page” is just another tool call, the same as reading a file. If MCP is new to you, read my introduction to MCP (Model Context Protocol) for beginners first.

BrightData MCP architecture: AI clients connect to the MCP server over local stdio or the remote hosted endpoint, which routes requests through BrightData’s unlocker, browser, and structured-data layers to Amazon, LinkedIn, Instagram, and search engines

One request, in plain English:

1. You ask something that needs the web.
2. The agent picks a tool, for example search_engine or web_data_amazon_product.
3. The MCP server forwards it to BrightData’s network, which handles the proxy, bot detection, and CAPTCHA.
4. The site responds and BrightData returns clean Markdown or typed JSON.
5. The model reads that and answers you.

Steps 3 and 4 are invisible. That’s the product: a proxy network, an unblocking layer, and maintained parsers behind a protocol your agent already speaks.

What it can do:

Traditional scraping means writing code, rotating proxies, solving CAPTCHAs, and re-fixing everything when a site changes its markup. BrightData MCP moves that layer behind a tool call. The trade: you don’t control the parsing layer, so when a collector changes shape you wait instead of patching. For most operators that’s the right trade.

Free tier vs pay-as-you-go: what’s actually metered?

The old split this guide used to describe — a free “Rapid” mode plus a “Pro mode” switch — is gone. Every account now gets the full tool catalogue, and the 5,000-requests-a-month free tier covers all of it, browser automation included. What differs between tool families is how fast they burn the allowance: one page of Markdown is one request, while a browser flow or a product-plus-reviews pull is several.

Decision chart: use BrightData MCP base tools for search and Markdown scraping, or the structured web_data_ collectors and browser automation when you need typed fields

One correction up front. Earlier versions of this guide described a PRO_MODE env var and an &pro=1 URL flag that unlocked the structured tools. Both are gone. Everything is enabled by default now, and you narrow the tool surface instead: GROUPS/TOOLS env vars on the local install, &groups=/&tools= query params on the remote endpoint. If you copied a config with PRO_MODE from an older post, it’s dead weight — remove it.

Which tools do you need? If Markdown plus search covers your workflow, stick to the base tools and your allowance will last. The moment you want a price field you can trust instead of a number you regex out of prose, reach for the web_data_* collectors — same free tier, they just cost more requests per job.

Two caveats. The 5,000 figure is what the free tier advertised when I wrote this and it has changed before, so verify it and treat it as an order of magnitude. And search_engine returns one SERP, not a crawl of the top 50 pages, so an ambitious prompt can burn an afternoon’s budget.

What can you build with BrightData MCP?

Anywhere an agent needs facts it can’t get from training data. Five patterns worth building.

Affiliate marketing

• Amazon prices, ratings, and review text instead of hand-copied numbers
• Review-derived pros and cons for roundups
• Scheduled price re-checks so tables don’t go stale

The tools: web_data_amazon_product_search for discovery, then web_data_amazon_product and web_data_amazon_product_reviews per ASIN. See how I built an AI affiliate website with Amazon products for the pipeline.

Competitive research

• Competitor pricing and product pages over time
• LinkedIn company records and headcount
• SERP captures for your target queries

Tools: web_data_linkedin_company_profile, search_engine, scrape_as_markdown.

Lead generation

• Prospect lists from LinkedIn people search
• Company enrichment from Crunchbase or ZoomInfo
• Job listings as a buying signal

Tools: web_data_linkedin_people_search, web_data_linkedin_job_listings.

Content research

• Statistics and quotes with the source URL attached
• Trending topics on Instagram, TikTok, or X
• Product specs before writing a review

Tools: search_engine, web_data_instagram_posts. To scale that into a pipeline, build your own AI agent with Mastra (files, web, browser) and hand it the same MCP server, or read how I wired tools in an AI agent with Agno and the Context7 MCP server.

Market intelligence

• Real estate listings, hotel rates, app store reviews
• Financial news and Yahoo Finance on a schedule
• Sentiment shifts across platforms

Tools: web_data_zillow_properties_listing, web_data_booking_hotel_listings, the app store collectors.

Available BrightData MCP tools

BrightData’s README advertises 69 tools and the count moves with every release, so treat that as “a lot of surface area” rather than a spec. If you’re weighing tool styles, I compared the options in Mastra tools vs MCP servers: which should your agent use. Five groups.

Search and basic scraping (base tools)

• search_engine: query against Google, Bing, or Yandex, returns the SERP as Markdown. One request.
• scrape_as_markdown: any URL to clean Markdown, nav stripped. One request per URL.
• scrape_batch: parallel fetch. A batch of 10 URLs is 10 requests, not one. Faster, not cheaper.
• session_stats: your request counters. This is the usage meter, check it first when something feels off.

If you only ever use search_engine and scrape_as_markdown, a free web search and fetch API for AI coding agents gets you the same result without an account.

Amazon data extraction (structured)

• web_data_amazon_product: one product record (title, price, availability, rating, review count, specs) for an ASIN or canonical product URL
• web_data_amazon_product_reviews: review records for pros and cons
• web_data_amazon_product_search: product cards for a keyword query

Input shape is where people break first. The search tool takes a query string; the product tools take an ASIN, not a search URL. Pass a search-results URL and you get an empty record, not an error.

LinkedIn intelligence (structured)

• web_data_linkedin_person_profile, web_data_linkedin_company_profile
• web_data_linkedin_job_listings, web_data_linkedin_posts
• web_data_linkedin_people_search

Public data only. Bulk contact-scraping is how accounts get flagged, so ask for lists in the hundreds.

Browser automation

• scraping_browser_navigate, scraping_browser_click, scraping_browser_type
• scraping_browser_screenshot, scraping_browser_get_html, scraping_browser_wait_for

The most expensive thing in the catalogue. Navigate, type, wait, click, screenshot is five to fifteen requests, and every retry doubles the failed part. Use it when a site needs interaction, not as your default fetcher. If you only need an agent to drive your own browser, browser control via HTTP for AI agents is a cheaper shape.

Social, e-commerce, and other structured sources

You can inspect each tool’s input schema in the Smithery MCP playground.

Prerequisites: what you actually need before you start

The old version of this list had three bullets and no versions, which is why people end up with spawn npx ENOENT.

Get your BrightData API token (60 seconds)

Sign in to the BrightData control panel, open account settings, then the users/API section, copy the token, and put it in a password manager. Not in a note file, not in Slack, not in a chat with your agent.

That token is account-wide. Revoking it breaks every configured client at once, which is exactly what you want when something leaks.

Local stdio or remote hosted? Pick one first

This decision determines which config you copy, and getting it wrong causes most “the tools don’t show up” reports.

If you don’t want a live token sitting in a URL, use the local stdio config everywhere the client supports it. That’s my default. If you want scraping jobs to survive a closed laptop lid, run the client headless on a small Hetzner VPS instead, and see how to set up a VPS for AI coding agents. For chat-driven work on your own machine, a local install is fine.

VPS prices jumped across the board in 2026 — if you’re rethinking a rented box, see what changed and when a mini PC wins.

Setting up BrightData MCP: step-by-step

Four options, each with the same shape: configure, verify, roll back.

Option 1: Factory.ai Droid CLI (recommended)

Droid CLI is where I’d start. It bundles a generous free token allowance for its own model usage, so you’re not paying for two things at once while testing an idea. Verify the current allowance when you sign up, those numbers move faster than any post can track, and I went through the free-model options in how to use Claude Sonnet, GPT-5 and Gemini for free.

Create or edit ~/.factory/mcp.json:

{
  "mcpServers": {
    "brightdata-mcp": {
      "command": "npx",
      "args": ["-y", "@brightdata/mcp"],
      "env": {
        "API_TOKEN": "your_brightdata_api_token_here"
      }
    }
  }
}

Replace the token, then lock the file down:

chmod 600 ~/.factory/mcp.json
ls -l ~/.factory/mcp.json

Verify: run droid and ask it to scrape_as_markdown on https://example.com. You want clean Markdown with no nav junk, and the agent naming the tool it used. If it answers from memory and never mentions a tool, the server isn’t connected.

Rollback: delete the brightdata-mcp key and restart Droid.

Option 2: Claude Code

Claude Code’s documented path is the remote endpoint over HTTP, so the token goes in the URL:

claude mcp add --transport http brightdata "https://mcp.brightdata.com/mcp?token=YOUR_API_TOKEN"

Keep the quotes. Verified against the Claude Code MCP docs when I wrote this.

Verify:

claude mcp list

You should see brightdata: https://mcp.brightdata.com/mcp?token=xxxxx (HTTP) - ✓ Connected.

Limit the tool surface: all 60-plus tools land in the agent’s context, which is a lot of tokens. If you only want search and scraping, restrict it:

claude mcp add --transport http brightdata "https://mcp.brightdata.com/mcp?token=YOUR_API_TOKEN&tools=search_engine,scrape_as_markdown"

Or use &groups= with the group IDs from the tools reference.

Rollback: claude mcp remove brightdata.

One scope note: claude mcp add writes to a user-level or project-level config, and project scope means teammates inherit the server and the token can land in a committed file. Use user scope for anything with a credential. If you don’t have a Claude subscription, one key for Claude Code, Codex and Gemini CLI avoids paying for three plans.

Option 3 and 4: Cursor, Windsurf, and other MCP clients

All of these read the same mcpServers shape. Only the file location and the reload step change, so there’s no reason for three copies of identical JSON.

{
  "mcpServers": {
    "brightdata-mcp": {
      "command": "npx",
      "args": ["-y", "@brightdata/mcp"],
      "env": {
        "API_TOKEN": "your_brightdata_api_token_here"
      }
    }
  }
}

Smoke test: verify BrightData MCP actually works

Don’t trust “the panel says connected”. Three calls, escalating, plus the counter.

1. Cheap, base: Use scrape_as_markdown on https://example.com and summarize it. Expect clean Markdown, about one request.
2. Search, base: Use search_engine to search for "brightdata mcp server" and list the top 3 results with URLs. Expect three real URLs.
3. Structured: Use web_data_amazon_product on ASIN B08XYZ123 and give me price, rating, and review count as JSON. Expect typed fields. Prose or an empty record means you passed a search URL instead of an ASIN, or a tools=/groups= filter excluded the collector.

Practical examples: real-world usage

Five workflows: goal, prompt, which tools fire, what you get back. Then what the request trail actually looks like.

Example 1: building a product comparison roundup

Prompt:

Search Amazon for "wireless noise cancelling headphones" and extract the
top 5 products. For each: name, current price, average rating, review count,
and three pros and cons from the reviews. Format as a markdown table.

Tools: web_data_amazon_product_search, then web_data_amazon_product and web_data_amazon_product_reviews per ASIN. You get: a table you can paste into an article, with prices and ratings you didn’t type.

Example 2: competitor research on LinkedIn

Prompt:

Extract this LinkedIn company profile: [company URL]
I need employee count, description, specialties, the five most recent posts
with engagement, and any open job listings.

Tools: web_data_linkedin_company_profile, web_data_linkedin_posts, web_data_linkedin_job_listings. You get: a competitor snapshot, and hiring trends are the most underrated signal in it.

Example 3: content research from social posts

Prompt:

For each of these Instagram posts, extract like count, comment count, caption,
posting time and hashtags. [URL1] [URL2] [URL3]
Then tell me which patterns repeat across the top performers.

Tools: web_data_instagram_posts, once per URL. You get: engagement metrics plus a pattern summary. If you want that running continuously, build a multi-agent research team with Tavily and Crawl4AI.

Example 4: real estate listing pulls

Prompt:

Extract listings from this Zillow search: [URL]
Give me addresses, prices, square footage, bed/bath, and days on market.

Tools: web_data_zillow_properties_listing. You get: listing fields rather than a screenshot. Outside the US the equivalent collector may not exist, and you’re back to scrape_as_markdown plus your own parsing.

Example 5: price monitoring across retailers

Prompt:

For product [name], compare current price, availability and shipping across
Amazon, Walmart, eBay and Best Buy.

Tools: web_data_amazon_product, web_data_walmart_product, web_data_ebay_product, web_data_bestbuy_products. You get: four records side by side. Schedule it if you want a trend, and remember each run costs four requests plus retries.

What a tool call actually looks like

The trace for Example 1, which is why the cost section makes sense:

Prompt: search Amazon for "wireless noise cancelling headphones", top 5
        products with price, rating and review count, as a table

-> web_data_amazon_product_search({"query": "wireless noise cancelling headphones"})
<- 5 product cards (ASIN, title, price, rating, review count)

-> web_data_amazon_product({"asin": "B0..."})        x5
<- full product records (specs, price, availability)

-> web_data_amazon_product_reviews({"asin": "B0..."}) x5
<- review text and ratings, for the pros/cons column

Requests: about 11. Result: one table with real prices and ratings.

Nothing magic: eleven requests, three tool types, one table.

Rate it before you run it

Order-of-magnitude estimates, not measurements:

Then multiply by retries. An agent that dislikes the first answer will happily re-run the expensive step, which is the biggest source of surprise usage.

Advanced configuration options

Remote MCP server configuration

On the remote endpoint you narrow the tool surface with query parameters: &groups= takes tool-group IDs (like ecommerce,social), &tools= takes individual tool names.

https://mcp.brightdata.com/mcp?token=YOUR_TOKEN&groups=ecommerce,browser

Zone selection isn’t a URL parameter on the current remote endpoint — the remote server uses the zones tied to your account. Custom zones are a local-install feature, below.

What a zone actually is

A zone is a named configuration in your control panel: proxy type, country targeting, auth. You create it there, name it, then reference the name from the local MCP config’s env vars. The server doesn’t create zones for you, which is why “use a specific zone” never worked for anyone who hadn’t made one first.

Local MCP environment variables

{
  "mcpServers": {
    "brightdata-mcp": {
      "command": "npx",
      "args": ["-y", "@brightdata/mcp"],
      "env": {
        "API_TOKEN": "your_token",
        "GROUPS": "ecommerce,browser",
        "WEB_UNLOCKER_ZONE": "my_scraping_zone",
        "BROWSER_ZONE": "my_browser_zone"
      }
    }
  }
}

Env values are strings, including the numbers. "600" with quotes.

Use cases by industry

Cost breakdown: what you’ll actually pay

As of 2026: the free tier is a shared account pool of 5,000 requests a month, and it covers every tool — search, the structured collectors, browser automation, all of it. Past that, pay-as-you-go: $1.50 per 1K results for search, scrape and extract, and browser automation metered per GB. Check the current BrightData pricing and free-tier limits before you budget, I’m not going to pretend a blog post stays current.

What one request costs you

• One tool call on one target is one request. One URL, one query, one ASIN.
• scrape_batch is not a discount. Ten URLs is ten requests, just faster.
• A browser flow is many requests. Navigate, type, wait, click, screenshot is five to fifteen.
• A retry doubles that step. Ask for “more results” and the expensive call runs again.
• Search is cheap, structured is not. Search then five products is 11 requests, and that’s the arithmetic to do before you write the prompt.

Scenario 1: content creator or affiliate marketer

50 product searches, 200 product fetches, 100 review extractions, 150 page scrapes. Roughly 500 requests/month, inside the free tier.

Scenario 2: market research

500 LinkedIn profiles, 300 company records, 200 social pulls, 1,000 page scrapes. Roughly 2,000 requests/month, still inside the free tier. LinkedIn and social collectors count against the same pool — the mix doesn’t matter, the total does.

Scenario 3: small e-commerce operation

2,000 product fetches, 1,000 review extractions, 500 price checks, 1,500 competitor scrapes. Roughly 5,000 requests/month, exactly at the line. This is the scenario where one buggy cron job eats your month in a day, so add caching before volume.

Scenario 4: data-heavy operation

10,000-plus requests, browser flows on interactive sites, scheduled feeds. Order of magnitude $100 to $500/month. That’s an estimate, not a quote, and browser automation is what pushes it up.

Chart comparing BrightData MCP free tier of 5,000 monthly requests against paid proxy and scraping infrastructure costs

Best practices for BrightData MCP

Ordered by how much they matter.

1. Monitor usage first

Show me my BrightData MCP session stats.

One number tells you whether you have a usage problem or a prompt problem. Optimizing before you look at it is guesswork.

2. Cache what you already fetched

Extract this Amazon product data and save it to a JSON file.
Only re-fetch if the file is older than 24 hours.

Prices don’t change hourly for most products, and checking a local file first kills most repeat requests.

3. Batch related requests, and count them

For these 10 Amazon product URLs: [list]
Extract all product data in one run and build a comparison table.

Faster, not cheaper. Batch for latency, cache for cost.

4. Use the specific tool instead of generic scraping

Less efficient: Scrape data from this Amazon product page

More efficient: Use web_data_amazon_product to extract structured data from ASIN B08XYZ123

Same result, one request, typed fields instead of prose to parse. This is the highest-leverage advice on the page.

5. Prefer structured data where a collector exists

Amazon products use web_data_amazon_product, LinkedIn profiles use web_data_linkedin_person_profile, Instagram posts use web_data_instagram_posts. Collectors are maintained upstream, so field shapes stay stable when a site’s HTML changes. Markdown scraping doesn’t have that property.

6. Validate and filter everything you get back

Extract product data from [URL] and validate:
- price is a number
- rating is between 0 and 5
- review count is a plausible integer
If any check fails, show me the raw response instead of guessing.

7. Set timeouts in the client, not the prompt

180 seconds is a reasonable ceiling, and it lives in your client’s MCP server settings. Not in BrightData, not in the prompt text. If requests die at 30 or 60 seconds, that’s your client’s default.

Security and secrets: don’t leak your API token

The setup above has you paste a live credential into a plaintext file and into a URL. That’s normal for local tooling and it’s also how tokens leak. Five rules.

1. Never commit the config. Add it to .gitignore before it exists: echo "~/.factory/mcp.json" >> .gitignore. Check git status before your first commit.

2. chmod 600 the file. Then confirm with ls -l. If another user on the box can read it, so can anything running as them.

3. Treat the remote URL as public. The token is in the query string, so it lands in shell history, client logs, screenshots, and screen shares. If you already pasted it, history -d the line and rotate. Prefer the local stdio config, where the token is in an env var.

4. Use a dedicated token and a dedicated zone. Not your personal admin credential. Create both for this purpose, so revocation is a small blast radius.

5. Keep secrets out of the agent’s reach. An MCP-enabled agent with a live token, shell access, and repo write access is one injected instruction from exfiltrating a secret. For unattended runs, give the process its own environment and nothing it doesn’t need.

Troubleshooting common issues

If you’re solving this on the CMS side instead of the agent side, my roundup of web scraping plugins for WordPress covers that path.

Issue: “spawn npx ENOENT”

Problem: the client can’t find npx, usually because a GUI app launched with a different PATH than your shell.

Solution: point at the full Node binary instead:

{
  "mcpServers": {
    "brightdata-mcp": {
      "command": "/usr/local/bin/node",
      "args": ["node_modules/@brightdata/mcp/index.js"],
      "env": {
        "API_TOKEN": "your_token"
      }
    }
  }
}

Find the path with which node on macOS and Linux, or where node on Windows.

Issue: timeout errors

Problem: requests die before completing, usually on slow targets or browser flows.

Solution: raise the timeout in the client’s MCP server settings, 180 seconds. If you can’t find it, check whether the client caps tool calls globally, because some do and the MCP config won’t override it.

Issue: rate limiting

Problem: you hit limits faster than expected.

Solution: check session stats before changing anything, cache results instead of re-fetching, add delays between scheduled batches, and only consider a paid tier after you’ve cut the waste.

Issue: incomplete data

Problem: fields come back empty or partial.

Solution: use the platform-specific tool rather than generic scraping, confirm the page structure hasn’t changed, verify the URL is public, re-fetch once after a delay, then stop retrying and read the raw response.

Issue: authentication required

Problem: the page needs a login.

Solution: BrightData MCP reads public data. Anything behind a login is out of scope, and authenticated browser automation is an advanced path with its own risk, so don’t start there.

Issue: Claude Code shows the server as “failed” in claude mcp list

Problem: the handshake fails.

Solution: three usual causes. Wrong transport or flag (check the current shape of claude mcp add --transport http), an expired or revoked token, or an unquoted URL where the shell ate the &.

Issue: “invalid JSON” when starting the client

Problem: the config doesn’t parse, so the client ignores it entirely.

Solution: validate instead of eyeballing:

python3 -m json.tool ~/.factory/mcp.json

The culprits in order: a trailing comma, a // comment, smart quotes pasted from a docs panel.

Issue: structured or browser tools don’t appear

Problem: web_data_* or scraping_browser_* are missing from the tool list.

Solution: check whether a GROUPS/TOOLS env var or a &groups=/&tools= URL param is filtering them out, then restart the client, because most clients read MCP config only at startup. If the tools are listed but return nothing useful, check that your account still has requests left.

Issue: 401 or 403 from the BrightData API

Problem: the token isn’t accepted.

Solution: confirm you copied the whole token with no trailing space, confirm it hasn’t been revoked, confirm you’re not pairing a token from one account with a zone from another, and confirm the account still has credit for the tools you’re calling. A stray trailing space beats every exotic cause.

Issue: zone errors, or requests silently falling back to default

Problem: geo-targeting doesn’t take effect and nothing errors.

Solution: copy the zone name exactly from the control panel into WEB_UNLOCKER_ZONE or BROWSER_ZONE on the local install, then verify with a page that reports the serving country. A name mismatch silently gives you the default zone, which is why this looks like bad data.

Issue: npx is slow on first run, or runs a stale cached version

Problem: the first call takes ages, or you’re running last month’s package.

Solution: the slow first call is npx downloading the package, a one-time cost. For stale caches:

npx clear-npx-cache
npx -y @brightdata/mcp@latest --help

Pin a version in args for anything scheduled, so a surprise release doesn’t change behaviour under a cron job.

Issue: Windows, node or npx not found, or a path with spaces

Problem: native Windows throws ENOENT variants because the path has spaces, or npx isn’t resolvable from the client’s environment.

Solution: either quote the full node path in command, or run everything under WSL2, which is what I’d pick because every config in this guide then works unmodified. One more case worth knowing: if the server runs fine by hand but the client never lists the tools, the client is spawning its own process with its own environment. Check the config path matches what that version actually reads, restart the client rather than reloading the window, and read the client’s MCP log, where the spawn error appears verbatim.

Rollback and cleanup: how to remove BrightData MCP

Everything here is reversible.

Verify removal: the client no longer lists brightdata, and a scrape prompt fails cleanly instead of silently succeeding through another path. Web data still coming back means you left a second config behind.

What doesn’t roll back: data you already scraped. It’s on your disk, in your agent transcripts, possibly in a database. If any of it was personal data, that’s a GDPR question rather than a cleanup task.

Frequently asked questions

Real-world success story

On my own site, SmoothieBlenderGuide.com, I used BrightData MCP to migrate and rebuild the whole thing. 40 articles needed moving from WordPress to Astro, every product recommendation needed current Amazon data, and I didn’t have a week to spend on it.

Using Factory.ai Droid CLI with BrightData MCP, I fetched current Amazon data for every recommended blender, pulled reviews for the pros and cons sections, rewrote the articles around the new data, built comparison tables, and generated featured images.

The results: 40 articles in about 3 hours of actual work, total cost under $2 (mostly AI tokens, barely touching the BrightData free tier), $15/month of WordPress hosting eliminated by moving to Cloudflare Pages, page load times down from 3 to 4 seconds to under a second. Those are my numbers from that one project, not a benchmark, and the reason it worked is boring: the structured tools returned the fields I needed, so I wasn’t hand-verifying scraped prose. You can read the full Amazon affiliate site case study for the pipeline.

Getting started checklist

Conclusion

BrightData MCP is the least annoying way I’ve found to give an agent web access it can trust. A web scraping MCP server isn’t a novel idea, but pairing a maintained proxy network with structured collectors and a clean tool interface is what makes it usable without babysitting. As an MCP server for AI agents it drops into whatever client you already use, which is the part that matters.

Key takeaways:

1. The free tier covers most solo-operator work. 5,000 requests/month across every tool is a lot of scraping, but verify the current allowance.
2. Pick a transport before you configure anything. Local stdio keeps the token in an env var, remote puts it in a URL.
3. Verify in 30 seconds with session_stats. Non-zero means the token is being read, zero means it isn’t.
4. Use the structured tools, not generic scraping. web_data_amazon_product returns typed fields in one request.
5. Treat scraping as untrusted I/O. Cache it, validate it, count it, and keep the token out of the agent’s reach.

Related Resources:

• AI affiliate websites with Amazon products
• MCP for beginners: introduction to Model Context Protocol
• Mastra tools vs MCP servers: which should your agent use
• How to build a free blog with Astro and Cloudflare
• BrightData MCP GitHub repository
• BrightData MCP documentation
• Smithery MCP playground