Bright Data MCP: 69 Web Tools for AI Agents, and What the Free Tier Actually Covers

What the Bright Data MCP server is for

An MCP client gives a model a list of callable tools. The Bright Data server fills that list with web access. According to the README, it exposes 69 tools split across web search (Google, Bing, Yandex), page scraping as Markdown or HTML, structured extraction from named platforms, remote browser automation, LLM response collection from ChatGPT, Grok and Perplexity, and npm and PyPI package metadata. The audience is anyone building an agent that has to read the live web rather than its training data: research assistants, competitive monitoring jobs, coding agents that need current package documentation.

The design decision that shapes everything else is that the work happens on Bright Data's side. The README states that every request is routed through the company's unblocking infrastructure, so bot detection, CAPTCHAs, rate limits and geo-restrictions are handled before your process sees a response. That is the product. You are not installing a scraper; you are installing a client for a metered network. Teams that expect a self-contained library they can run against their own proxies will find a different shape of tool here.

How the server routes a request

The repository is a Node package, and package.json lists it as an ES module with server.js as the entry point and the bin target. Dependencies include @modelcontextprotocol/sdk, fastmcp, playwright, axios, zod, remark and strip-markdown. That mix tells you the split: fastmcp and the MCP SDK handle tool registration and transport, axios carries HTTP calls to the Bright Data endpoints, and Playwright drives the remote browser sessions used by the navigation tools. remark and strip-markdown are what turn fetched HTML into the Markdown that scraping tools return to the model.

Tool visibility is configurable before the agent ever sees the list. The hosted URL accepts a groups parameter to enable tool groups and a tools parameter to enable individual tools by name, with search_engine and scrape_as_markdown given as examples. The repository also ships tool_groups.js alongside browser_tools.js and browser_session.js, which is where that grouping logic lives. Narrowing the tool list matters more than it sounds: an agent choosing between 69 tools spends context on the catalogue itself, and a smaller surface produces fewer wrong calls. If your client supports it, enabling only the groups you need is the first tuning step, not an afterthought.

Installing Bright Data MCP and making a first call

There are two paths. The hosted server needs no installation at all: you append your API token to a URL and paste it into the client. The README points to the Bright Data account settings page for the token, and new accounts get 5,000 free requests per month.

For Claude Code, the README gives a single command that registers the hosted endpoint over HTTP transport. Replace the token placeholder with your own before running it.

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

Clients that read a JSON config file take the same URL in their own schema. Cursor, for example, uses ~/.cursor/mcp.json with a url key rather than a command. The README also lists Claude Desktop, VS Code, Windsurf, Gemini CLI, Zed and Warp, each with its own key name for the same value, so copy the block for your client rather than adapting another one.

If you prefer to run the server locally, the package is published to npm and the README shows an npx invocation with the token passed as an environment variable. The first run downloads the package; subsequent runs resolve from the local npm cache.

{
  "mcpServers": {
    "Bright Data": {
      "command": "npx",
      "args": ["@brightdata/mcp"],
      "env": {
        "API_TOKEN": "<your-api-token-here>"
      }
    }
  }
}

After the client restarts, the tool list should show the Bright Data tools alongside your existing ones. A first useful call is a search followed by a scrape: ask the agent to search for a topic, then fetch one result as Markdown. That exercises both the search tool and the page-fetching path, and it shows you what the Markdown conversion does to a real page before you build anything on top of it. The repository also contains a Dockerfile that builds from node:22.12-alpine and runs node server.js as its entrypoint, for deployments that want the server in a container rather than spawned by the client.

The free tier is an allowance, not a licence

The README is unusually explicit here, and it is the part most teams should read twice. Free accounts get 5,000 requests per month, renewing on the first of each month, and unused requests do not roll over. On team accounts the allowance is shared across all users. When free requests run out, requests stop, and the README states there are no surprise charges unless you have deposited funds. Adding a credit card is described as a verification step only.

Beyond the free tier, pricing is pay as you go: $1.50 per 1,000 results for search, scrape and extract, and $8 per GB for browser navigation. Those are different units, which matters when you estimate. A thousand page fetches is a predictable line item; browser sessions are billed by bandwidth, so a session that loads heavy media costs more than one that reads text. The README also mentions a spend cap in the control panel so pay-as-you-go usage cannot exceed a budget you set.

Two consequences follow. First, an agent in a loop can consume the monthly allowance faster than a human would, because nothing in the tool list stops it from retrying. Second, the free tier is a recurring quota tied to an account, so the server is not a thing you can fork and run for free. The MIT licence covers the code in this repository; it does not cover the network those tools call.

Where it is the wrong tool

The failure mode is dependency, not correctness. Every tool call leaves your process and reaches Bright Data's infrastructure, so the server is only as available as that endpoint and only as useful as your account balance. If the token expires, the free tier is exhausted, or the account is suspended, the agent does not degrade into a slower scraper; the tools stop returning data. A local npx process does not change this, because the unblocking work still happens remotely.

That makes it a poor fit for a few cases. If your targets are static pages on sites you control, a plain HTTP fetch plus an HTML-to-Markdown step is cheaper, faster and has no quota. If your data cannot leave your network for compliance reasons, routing page content through a third party is a non-starter regardless of how well the unblocking works. If you need deterministic cost per request, browser navigation priced per GB introduces a variable you cannot bound from the client side. And if you need an offline or air-gapped environment, there is nothing to install that helps.

There is also a subtler limitation in the tool design. Sixty-nine tools with overlapping purposes (several search engines, several extraction targets, both Markdown and HTML output) mean the model chooses. The README's groups and tools parameters exist precisely because that choice is not free, and the documentation does not describe how the server handles a wrong tool selection beyond returning whatever the underlying call produces.

How it differs from running your own scraping stack

The obvious alternative is assembling the pieces yourself: Playwright for rendering, a proxy pool for rotation, a CAPTCHA service for challenges, and your own Markdown conversion. The difference is not capability, it is who operates the failure. With a self-built stack, a site changes its bot detection and you debug it; with this server, the README's claim is that bot detection, CAPTCHA solving and proxy rotation are handled automatically on every request, and that maintenance burden sits with the vendor.

A second alternative is a general-purpose scraping framework that runs in your own infrastructure. Those give you full control over where data lands and how requests are scheduled, and no per-request fee, at the cost of building and maintaining the unblocking layer, which is the hard part. The trade is straightforward: pay per result and accept the quota and the external dependency, or own the pipeline and accept the maintenance.

A third comparison point is a plain search API. If all your agent needs is search results, the search tools here are one part of a much larger surface, and a narrower search service may be simpler to reason about. The case for this server is when search, scraping, extraction and browser control need to come from one place with one credential, and when the pages you need are the ones that resist ordinary clients.

Maintenance, releases and what the licence does not cover

The repository is not archived, and the last push was on 2026-08-12. Releases are frequent: v2.11.1 on 2026-07-27, v2.11.0 on 2026-06-16 and v2.9.3 on 2026-03-29, while package.json in the repository already carries version 2.11.2. That gap between the published release and the repository version is normal for a package published from main, but it means the npm package and the repository HEAD are not always the same code.

Upgrade cost is low if you use the hosted URL, because there is nothing on your side to update; the vendor's deployment changes under you. That cuts both ways, since a tool's behaviour can change without a version bump in your config. If you run the local npx instance, you are pinning a version and will need to move it deliberately. The Dockerfile builds from node:22.12-alpine in a builder stage and node:22-alpine for the release stage, copying only server.js, browser_tools.js, browser_session.js, package.json and package-lock.json, which is a small image but also means the container expects the remote endpoints to be reachable.

The licence is MIT for the code in the repository. That governs the server implementation, not the service it calls: requests are governed by Bright Data's account terms, the free tier is a quota on an account, and pricing is set by the vendor. Nothing in the MIT grant gives you the right to run the unblocking infrastructure yourself.

Editorial conclusion

Adopt it if your agent needs pages that block ordinary HTTP clients and you would rather pay per result than maintain proxies, headless browsers and retry logic. Skip it if your targets are static pages you control, if your data cannot leave your network, or if you need a guarantee that a request will never be billed. Before wiring it into an agent, verify two things: that your client speaks Streamable HTTP or can spawn a local npx process, and that the free tier's 5,000 monthly requests are enough for your call volume, since requests stop rather than roll over when the allowance is spent.

Frequently asked questions

Official sources

1. brightdata/brightdata-mcp on GitHub
2. License: MIT
3. Project website
4. README
5. Releases