Firecrawl MCP Server: 25 Tools for Web Scraping Inside an LLM Client
🔥 Official Firecrawl MCP Server - Adds powerful web scraping and search to Cursor, Claude and any other LLM clients.
At a glance
- What is it?
- The official Firecrawl MCP server puts search, scrape, crawl, map, interact and monitor behind the Model Context Protocol, so Cursor, Claude and other MCP clients can fetch the live web. The interesting part is not the scraping itself but how the tool surface is bounded, and where that bounding breaks down.
- Who is it for?
- Adopt it if your agent needs a URL turned into markdown or schema-shaped JSON and you are willing to run Firecrawl's cloud or your own instance behind it. Do not adopt it if you need to drive a browser session step by step from the client: each firecrawl_interact call runs one prompt or code turn to completion, and the README says you cannot drive it interactively within a single call.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Firecrawl MCP Server fills for MCP clients
An MCP client can call tools, but it cannot fetch a page. That is the gap this server covers. It is a Model Context Protocol server, written in JavaScript, that exposes Firecrawl's search, scrape, crawl, map, interact and monitor operations to any MCP-compatible agent. The README frames the output as "clean, agent-ready context", which is the point: the agent gets markdown or structured JSON instead of raw HTML it would have to parse.
The audience is narrow and identifiable. It is people already running an MCP client (Cursor, Claude, Windsurf appear in the setup instructions) who want the model to reach the live web mid-task. The README's own "When to Use This Server" list is the clearest statement of intent: firecrawl_scrape when you have a known URL, firecrawl_map when you only need to discover URLs, firecrawl_crawl when you need many pages under a site, firecrawl_search when you start from a query, firecrawl_interact when a page needs a click or a type before it can be read, and the firecrawl_monitor_* tools when the same page has to be checked on a schedule with diffs. If your task is none of those, the server is not for you.
One caveat worth stating plainly: the README does not describe the extraction pipeline itself. It says scraping returns clean, structured data, and that firecrawl_scrape can return markdown or JSON matching a schema you supply, but the parsing, rendering and anti-bot machinery behind that is not documented here. This repository is the MCP wrapper, not the crawler.
What the 25-tool surface actually exposes
The README states that the server lists 25 tools when the full profile registers with default settings, counting feedback tools and excluding local keyless mode. That number is a design decision, not an accident, and the repository gives you three ways to shrink it.
Setting FIRECRAWL_NO_SEARCH_FEEDBACK=1 removes the search feedback tools. Setting FIRECRAWL_NO_ENDPOINT_FEEDBACK=1 removes the endpoint feedback tools. Local keyless startup also reduces the count. The reason to care is stated in the README: clients with a tool-slot limit. Every tool description an MCP server registers consumes context, so a 25-tool surface is a real cost for a client that is also holding your codebase.
Two hosted endpoints offer pre-trimmed surfaces. The keyless endpoint at https://mcp.firecrawl.dev/v2/mcp exposes only three tools: firecrawl_scrape, firecrawl_search and firecrawl_parse. A separate search-only endpoint at https://mcp.firecrawl.dev/v2/mcp-search exposes a fixed six read-only tools: firecrawl_search, firecrawl_developer_search, and the four firecrawl_research_* tools. The README is explicit that this search-only surface performs no page-content fetching and has its own OAuth identity, and points to docs/search-profile.md for the full contract.
The distinction between firecrawl_search and firecrawl_scrape is worth internalising before you configure anything. The README notes that the search-only endpoint never fetches content, so if you want page bodies you either add scrapeOptions to the search call or follow up with a scrape. That is a two-call pattern versus a one-call pattern, and the choice affects both latency and how much content lands in your context window.
Hosted keyless, OAuth, or npx: three ways in
The fastest path requires no installation. Point an MCP client at https://mcp.firecrawl.dev/v2/mcp. On the keyless free tier, scrape, search and parse work without an API key and are rate-limited. The README states that other tools such as crawl, map and agent still need a key, and recommends OAuth or an API key whenever the human can sign up, since that unlocks the full tool set and higher limits.
For an interactive account connection the URL changes to https://mcp.firecrawl.dev/v2/mcp-oauth. The README warns that this is an MCP endpoint, not a browser page, so you use the client's account-connection flow rather than opening it. It also warns against adding a second Firecrawl server entry when reconnecting.
For unattended integrations you keep the server URL at https://mcp.firecrawl.dev/v2/mcp and supply a header:
Authorization: Bearer <FIRECRAWL_API_KEY>
The README repeats the same warning three times in slightly different forms: never put an API key in the server URL, never put it in an agent chat, configure it in the client or a secret manager instead. That repetition suggests it is a mistake people actually make.
Local installation is two commands. One-shot:
env FIRECRAWL_API_KEY=fc-YOUR_API_KEY npx -y firecrawl-mcp
Global:
npm install -g firecrawl-mcp
In Cursor, the README gives a JSON block for the mcpServers entry with command npx, args ["-y", "firecrawl-mcp"], and FIRECRAWL_API_KEY under env. It notes Cursor version 0.45.6+ is required and gives separate instructions for v0.48.6 and v0.45.6. Windows users are told to try cmd /c "set FIRECRAWL_API_KEY=your-api-key && npx -y firecrawl-mcp". Windsurf configuration goes in ./codeium/windsurf/model_config.json with the same npx command shape.
The interact tool's one-turn-per-call constraint
This is the limitation the README volunteers, and it is the one most likely to bite. firecrawl_interact exists for pages that need a click, a type or a navigate before the content is readable. You pass a url for a fresh page, or a scrapeId to continue on a page you already scraped.
The constraint: each firecrawl_interact call runs one prompt or code turn to completion and returns control. The session can persist across calls via scrapeId and ends with firecrawl_interact_stop, but the README states you cannot drive it interactively step by step from the client side within a single call.
So the tool is not a browser automation framework. If your workflow is "click here, read the result, decide the next click based on what I saw", you are writing that loop yourself across multiple tool calls, and the model has to hold the state between them. The README's own advice is to consider something else when you need to hold a browser session open across many of your own steps with your own retry and termination logic. That is a fair description of the boundary.
A second constraint sits in the crawl tool. Crawling a site can run long and wide, which is why the README tells you to bound it with limit, includePaths/excludePaths, or maxDiscoveryDepth. Those are the knobs that keep a crawl from consuming your quota and your context. There is no stated default for any of them in the material provided, so set them explicitly rather than trusting a default you cannot see.
Retries, rate limiting and where the operational cost sits
The feature list includes automatic retries and rate limiting, and cloud plus self-hosted support. The README does not describe the retry policy, the backoff shape, or the rate limit thresholds. It only says the keyless tier is rate-limited and that OAuth or an API key gives higher limits. Treat those as claims without published numbers.
Operationally, the cost model splits in two. On the hosted path, you pay in API quota and rate limits, and the keyless tier is a trial surface rather than a production one: three tools, no crawl, no map, no agent. On the self-hosted path, the README says self-hosted support exists but does not give deployment steps, environment variables beyond FIRECRAWL_API_KEY, or a compose file. That is a gap. If self-hosting is the reason you are reading this, the material here does not get you there.
Maintenance on the client side is mostly version drift. The repository has moved through v3.0.0 (2025-09-11), v3.2.0 (2025-09-16) and v3.2.1 (2025-09-26), a compressed release cadence. The README also carries Cursor-version-specific instructions, which means client upgrades can invalidate your setup notes. Pinning the package version in your args instead of relying on -y firecrawl-mcp resolving to latest is the practical hedge, though the README does not suggest it.
On licensing: the repository is MIT. The server code being MIT does not tell you anything about the terms of the Firecrawl API you call through it, and the README does not address that. Check the service terms separately. This is not legal advice.
Firecrawl MCP Server versus calling the Firecrawl SDK directly
The obvious alternative is skipping MCP entirely and calling Firecrawl's HTTP API or SDK from your own code. The difference is not capability, it is who holds the loop.
With the SDK, your program owns the control flow: you decide when to scrape, how to bound a crawl, how to retry, and what to do with the result. The server model inverts that. The MCP client's model decides which tool to call and when, based on the conversation. You get less determinism and less visibility, and you give up the ability to write a tight loop around firecrawl_interact because of the one-turn-per-call constraint described above.
What you gain is reach. An agent inside Cursor or Claude can fetch a page mid-task without you building a tool-calling layer, and the hosted keyless endpoint means you can evaluate the whole thing by pasting one URL into a client config. For exploratory work, that trade is usually worth it. For a scheduled pipeline that must produce the same output every night, the SDK is the better fit, because you can test it, log it and pin its behaviour.
A middle path exists in the material: the firecrawl_monitor_* tools handle recurring checks with diffs and change alerts, which is the one case where the server takes over a job you would otherwise schedule yourself. The README does not document the alert delivery mechanism or the schedule granularity, so verify that before relying on it.
Who should wire this in, and what to check first
Adopt it if your agent needs a URL turned into markdown or schema-shaped JSON and you are willing to run Firecrawl's cloud or your own instance behind it. The setup is genuinely short: one npx command locally, or one URL in a client config for the hosted path. The tool descriptions in the README map cleanly onto real tasks, and the search-versus-scrape distinction is documented well enough to design around.
Do not adopt it if you need to drive a browser session step by step from the client. Each firecrawl_interact call runs one prompt or code turn to completion, and the README states you cannot drive it interactively within a single call. Do not adopt it for a deterministic nightly pipeline either; the SDK gives you the control flow that MCP deliberately takes away.
Before wiring it into a client, check three things. First, your tool-slot budget against the 25-tool full profile, and whether FIRECRAWL_NO_SEARCH_FEEDBACK=1 and FIRECRAWL_NO_ENDPOINT_FEEDBACK=1 should trim it. Second, whether the keyless three-tool surface is enough for your first evaluation, or whether you need a key on day one because crawl or map is in scope. Third, if self-hosting is a requirement, get the deployment details from Firecrawl's own documentation, because this README does not contain them.
Editorial conclusion
Adopt it if your agent needs a URL turned into markdown or schema-shaped JSON and you are willing to run Firecrawl's cloud or your own instance behind it. Do not adopt it if you need to drive a browser session step by step from the client: each firecrawl_interact call runs one prompt or code turn to completion, and the README says you cannot drive it interactively within a single call. Before wiring it into a client, check your tool-slot budget against the 25-tool full profile and decide whether FIRECRAWL_NO_SEARCH_FEEDBACK=1 and FIRECRAWL_NO_ENDPOINT_FEEDBACK=1 should trim it.
Community notes