The server turns Firecrawl into MCP tools
Firecrawl MCP Server exposes web work as named tools an agent can call. The current README covers single-page scraping, web search, URL mapping, site crawling, file parsing, developer search, interactive page operation, monitoring, and longer research jobs. That is a wider surface than a basic fetch server. Results can be returned as Markdown, structured JSON, links, screenshots, summaries, or other formats supported by the underlying API.
The server is an adapter, not the crawler itself. By default it sends operations to Firecrawl's cloud API using an API key or OAuth access token. A team can point FIRECRAWL_API_URL at its own Firecrawl deployment, but that backend has to exist separately. Installing this 44-file repository does not create a private crawling platform. This distinction matters for privacy reviews, billing, rate limits, data location, and incident ownership.
The free endpoint exposes only 3 rate-limited tools
The hosted URL can be connected without local setup. Anonymous access covers scrape, search, and parse with rate limits. Crawl, map, agent, and other tools require a key. An OAuth endpoint supports interactive account connection, while unattended systems can send a bearer API key through the MCP client's secret or header configuration. The README warns against putting keys in the server URL or an agent conversation.
There is also a search-only endpoint with 6 read-only tools: one general search tool and 5 research tools. It has a separate OAuth identity and does not fetch page content. That narrower contract is useful when an administrator wants agents to discover sources without granting page interaction or crawl operations. Audience checks prevent a token for the full endpoint from being silently reused against the search resource.
What happened when we ran it
Our sandbox installed 341 pnpm packages in 14 seconds and used 126 MB on disk. The TypeScript build succeeded in 5 seconds. Node's test runner then passed all 74 tests in 24 seconds, with 0 failures. Among this group of reviewed agent tools, that is a clean repository result and a reasonable local feedback loop.
The measured commit was 678c92a in a 3-CPU, 8 GB unprivileged Debian container with no secrets. Its checkout occupied 3.4 MB, contained 44 files and roughly 8,408 source lines, and had 4 CI workflow files. We found a Dockerfile, a tests directory, and monorepo workspace configuration. The run did not call the Firecrawl API, spend credits, compare extraction accuracy, or measure external-site latency.
A passing 74-test suite verifies the adapter cases present in that commit. It cannot guarantee that a target site permits crawling, renders without authentication, or returns the fields an agent expects. Production evaluation should include representative pages, rate-limit responses, secret handling, malformed tool calls, and the exact MCP client or gateway that will validate the published schemas.
Tool choice controls cost and context size
The README gives unusually practical routing advice. Use scrape for a known URL, map to discover URLs, search for an open-ended web question, crawl for a whole site section, and interact when the agent must click or type. For several known URLs, it recommends repeated scrape calls rather than pretending the MCP tool accepts an array. JSON extraction is preferred when a schema can keep the returned context small.
Those choices affect both Firecrawl credits and model tokens. Full-page Markdown is easy to request and easy to overuse. A structured schema can return only a product name and price, while a crawl can fan out across many pages if its limits are vague. The server includes retries and rate handling, but application owners should still cap site scope, result size, and allowed tool names. An agent deciding on its own needs boundaries that a human using curl may not.
Strict MCP gateways need a schema check
Open issue 373 describes a concrete interoperability failure in version 3.24.0. The published input schema for jsonOptions.schema marks the object as rejecting additional properties without declaring allowed properties. A gateway that validates tool arguments can therefore reject ordinary JSON Schema keys such as type, properties, and required, even though the server's internal validation accepts them. The reporter saw the failure specifically with structured scrape output.
That issue should not be generalized to every tool or client. It is a reason to run tools/list through the same validator used in production and execute one structured extraction before rollout. Current pull requests address bounded outputs, structured errors, and schema details, which shows active attention. GitHub recorded 157 combined issues and pull requests, so compatibility work is still moving rather than frozen.
August pushes outweigh the old GitHub release tag
The latest formal GitHub release is v3.2.1 from September 26, 2025, yet the repository was pushed on August 26, 2026. An open issue explicitly notes that package versions advanced without matching tags or releases. The stale release page is poor evidence of abandonment here. Current pull requests and same-day pushes show continued work, while the release process itself is confusing for anyone relying on GitHub tags to pin changes.
Firecrawl MCP Server is a sensible adapter when its service boundary is understood. The 14-second install and fully passing test command make local evaluation cheap. The real adoption questions sit outside that result: which tools an agent may invoke, where page data is processed, how credits are capped, and whether the client's schema validator agrees with the server. Answer those before enabling crawl or interaction for an unattended agent.