Bright Data MCP

Connect a coding agent to Bright Data’s web access and data tools. Use its official Skills to choose browser, fetch, search, or extraction workflows, with credentials, product scope, and costs checked separately.

Choose the right web-data path

A limited sample shows which service surface fits the input and what usage information is available before committing to a larger data job.

Sample URLs, requested fields, permitted service products, configured account, and spending or usage ceiling.

Copy the request into a new Floatboat conversation and provide the required material.

Download Floatboat

Your request for Floatboat

Preview and copy the request. It is not sent automatically from this page.

Reference: Bright Data MCP
https://github.com/brightdata/brightdata-mcp

Read the original documentation and check the current environment and dependencies. Propose any new installation or tool connection before proceeding.

My task:
Select a Bright Data tool for the supplied sample URLs and fields, using only permitted service products. Respect the supplied spending or usage ceiling; if no ceiling is provided, propose the tool and cost-check plan without calling a billable service. Report sources and available usage evidence.

Expected deliverable:
A small sourced result with the chosen service path and usage considerations. Include failed steps and unresolved questions when evidence is insufficient.

About Bright Data MCP

Bright Data MCP exposes remote web-data products rather than a standalone local browser. Search discovers candidate sources, fetching returns page content, structured scrapers target supported data shapes, and browser tools handle stateful interaction. The requested output determines product access, verification, and usage costs.

Official client examples include Cursor, and the Bright Data CLI can configure agent connections. The separate official Skills repository covers onboarding, browsing, scraping, fetching, and cost checks. Choose MCP for tools exposed to an agent client, CLI for terminal workflows, or an SDK for application code.

Prepare an authorized service account and the product access needed by the task. The MCP repository is MIT-licensed, while service use, data products, and usage charges follow Bright Data’s terms. A local MCP process still calls external infrastructure, so do not describe it as local-only data processing.

How Bright Data MCP Fits the Browser Workflow

Several products sit behind the agent interface. Match the deliverable to a tool family, then inspect a small sample before committing to a larger collection or an interactive browser session.

  • Search, fetch, scrape, or browse

    Search discovers URLs, fetching returns content, structured scrapers return supported fields, and browser tools handle stateful interactions.

  • Remote product access over MCP

    Hosted MCP and the local connector expose Bright Data services to agent hosts. Credentials and product access determine which tools can work.

  • Bounded collection

    Sample size, freshness, missing fields, and service usage belong to the output contract before collection expands into a batch.

Bright Data MCP Use Cases

Public extraction, search, interactive browsing, and ready data products require different tools and checks. Start with a bounded sample and keep evidence, freshness, and cost decisions separate from connection setup.

Collect product fields without unnecessary browsing

Supply public product URLs and a name/price/availability schema. Compare a supported structured scraper with page fetching before choosing interactive browser tools. Validate a few values against source pages and record missing fields and available usage data; a larger job should use the same agreed output and cost scope.

Search before opening many pages

For a research question, use the appropriate search surface to identify likely sources, then inspect a bounded subset. Return queries, selected URLs, and the facts they support rather than treating search snippets as verified page content.

Operate a cloud browser

When an interaction genuinely needs a browser, use the relevant Bright Data browser service and configured agent tools. Identify the session and expected page result, then verify the action. A simple fetch task should not be described as having exercised the interactive workflow.

Choose existing data over recrawling

If a ready data product may answer the request, compare coverage, freshness, and access terms before launching a new crawl. Present the choice and cost implications for review; neither an MCP connection nor a Skill authorizes purchases automatically.

Before Using Bright Data MCP

Match the service product, account access, and usage budget to the data task before connecting an agent.

  • Service account and product access

    Configure the relevant Bright Data product and authentication through official onboarding or client settings.

  • Collection scope and costs

    Set a bounded sample, required fields, and usage limits before running a larger job.

Extract Three Product Pages Through Markdown Fetching

Supply exactly three public product URLs, required name/price/stock fields, the intended region or variant, and a permitted sample/usage limit. This first sample uses the documented scrape_as_markdown tool rather than choosing a different product for every page.

  1. Fetch the first supplied product page

    Confirm that scrape_as_markdown is available through the configured Bright Data MCP connection, then fetch the first URL. Inspect the returned content for the requested product and variant before extracting values. Authentication or quota errors are connection/service findings, not product availability.

  2. Extract the same fields from all three URLs

    Use the same tool on the remaining URLs within the agreed sample limit. Produce one row per source with name, displayed price and currency, stock wording, region/variant, and URL. Preserve source wording for ambiguous stock states and mark absent fields instead of borrowing values from another variant.

  3. Check representative values against source evidence

    Compare at least one complete row with the corresponding fetched passages, retaining the price and stock evidence. Where a supplied browser reference is available, check the same region and variant against it. If evidence is absent or inconsistent, label that row unresolved rather than treating a well-formed table as validation.

  4. Handle failed pages without unbounded retries

    Separate failed requests from valid pages with missing fields. Inspect returned access, quota, or source errors before retrying. If an essential field requires interaction, report that limitation and propose a bounded browser fallback under the permitted usage scope; do not silently launch a new collection or buy a dataset.

Related Software Projects

Compare the workflows, operating requirements, and source licenses of these projects.

Bright Data MCP FAQ

Is Bright Data MCP a free standalone scraper?
No. It connects agents to Bright Data services. The MIT repository license covers connector code, not unrestricted service use, data purchases, or browser-session allowance.
Are official Skills available?
Yes. brightdata/skills contains onboarding and task-specific instructions. They can guide CLI, MCP, or SDK use, but the requested service still needs an account and appropriate access.
How should credentials be supplied?
Use the documented client or CLI authentication configuration. Keep API tokens out of task text, generated reports, and source control; a user may need to approve the service login.
Does every task need a browser?
No. Search, fetch, datasets, and extraction can serve different outputs. Reserve interactive browser operations for tasks that require page state or actions rather than assuming browsing is always necessary.
Can a local MCP keep the task offline?
No. The local connector still calls Bright Data’s infrastructure and the host may use a remote model. Review service and model data paths for the content you plan to submit.
What if the sample returns no rows?
Separate account/product access errors, source-page failures, and valid empty results. Inspect the URL and response evidence before changing tools or expanding the sample. Missing data should remain visible rather than being filled with inferred values.