Firecrawl puts 26 web tools behind one MCP connection
Firecrawl MCP Server turns the Firecrawl service into tools an agent can select by name. The full default profile lists 26 tools covering known-page scraping, search, URL discovery, multi-page crawling, document parsing, page interaction, recurring monitors, developer search, paper research, and credit checks. That breadth is the appeal: one server can answer a web question, extract a typed object, or follow a page interaction without a custom wrapper for each job.
The package is still an adapter. Its default path sends work to Firecrawl's cloud API using an API key or OAuth access token. Pointing FIRECRAWL_API_URL at another address supports a self-hosted backend, but installing this 3.6 MB checkout does not create that backend. Privacy, billing, site permissions, retention, and outage handling therefore belong in the adoption decision, even when the MCP process itself runs on your laptop.
The keyless tier stops at 3 tools
The hosted keyless endpoint offers rate-limited scrape, search, and parse. Crawl, map, agent, interaction, monitoring, and account-level credit data need an authenticated connection. A separate search endpoint exposes a fixed set of 8 search and research tools, with its own OAuth audience. That gives administrators a narrower option when source discovery is useful but general page operation is too much authority.
Local setup can be one npx command with FIRECRAWL_API_KEY. Stdio fits desktop clients, while Streamable HTTP listens on port 3000 and needs deliberate bearer-token handling. The README is right to warn against placing an API key in the endpoint URL or an agent chat. Credentials belong in the client's secret configuration, where prompts and scraped pages cannot repeat them.
What happened when we ran it
Our sandbox installed 339 pnpm packages in 21 seconds and used 125 MB on disk. The build completed in 8 seconds. Node's test runner then reported 123 passed and 0 failed after 62 seconds. For a server that exposes scraping, research, interaction, and several transports, that is a clean result and a quick enough feedback loop for an engineering team to try locally.
We tested commit 9da9776 in an unprivileged Debian container with 3 CPUs, 8 GB of RAM, and no secrets. The repository contained 63 files, roughly 13,595 source lines, 4 CI workflow files, a Dockerfile, a tests directory, and workspace configuration. Those checks did not contact Firecrawl, spend credits, scrape a live site, or measure extraction quality. They prove the checked-out adapter built and passed its own suite.
File parsing can cross the working-directory boundary
Open issue 306 reports a sharp self-hosting risk in firecrawl_parse. According to the reproduction, the tool resolves any supplied path and reads it without confining access to an approved directory. The reporter used /etc/passwd on version 3.20.2 and says the server uploaded the file to the configured parse API. The issue remained open when checked, so operators should treat local file selection as privileged rather than a harmless document helper.
Container isolation and a narrow mount reduce the consequence, but the 125 MB install result says nothing about that boundary. Do not give the process a home directory full of SSH keys, environment files, or unrelated project secrets. If parsing is unnecessary, remove or deny the tool. If it is necessary, put approved documents in a dedicated directory and verify the current code's path behavior before connecting an agent.
Strict clients can reject structured extraction before execution
Open issue 373 describes a different failure. The published schema for jsonOptions.schema was reported as an object that allows no normal keys, even though the server accepts a free-form JSON Schema internally. A gateway that validates calls against tools/list can reject type, properties, and required before Firecrawl sees the request. That breaks the structured-output path the README recommends for keeping responses smaller.
The right acceptance test is small: list the tools through the production client, then run one schema-based scrape against a controlled page. Our 123 passing tests are useful evidence about commit 9da9776, but they do not reproduce every gateway's schema validator. Issue 311 adds another reason to inspect metadata: it reports that search advertises readOnlyHint: true while its accepted actions include clicking, writing, and JavaScript execution.
A large tool menu needs limits on spend and context
The README tells agents to use scrape for one known URL, map for discovery, crawl for a bounded site section, and agent for research across several sources. That routing advice is unusually concrete. It also reveals the cost model. Full-page Markdown can flood the model context, while broad crawls and autonomous research can consume Firecrawl credits. JSON extraction, path filters, crawl limits, and explicit tool allowlists should be deployment settings, not suggestions left to the prompt.
Open issue 309 argues that the 26 tool definitions themselves are expensive in model context and that many parameters lack descriptions. We did not reproduce that reporter's token estimate, so it should be read as an interoperability warning rather than our benchmark. Clients with tight tool limits can use the 3-tool keyless surface or the 8-tool search surface. Everyone else should measure the actual tools/list payload with the model they pay for.
September commits matter more than the 2025 release page
The repository was pushed on September 28, 2026, and same-day pull requests were being merged. GitHub showed 7,528 stars and 150 combined issues and pull requests. The latest formal GitHub release was still v3.2.1 from September 26, 2025, while the measured commit's package declared version 3.25.5. Open issue 255 calls out that tagging gap. The release page is stale, but the codebase is plainly active.
Firecrawl MCP Server earns a trial because 339 packages installed cleanly and all 123 tests passed. Adoption depends on the service around it: authenticated web work, credit exposure, local file authority, and client-specific schema behavior. Keep the enabled tool set as small as the job allows. The 3-tool hosted tier is enough to learn whether Firecrawl's results suit your agent before granting crawl, interaction, or local file access.