Firecrawl With Claude: MCP Server or One Key for Everything?
Firecrawl mapped 484 URLs for a tenth of a cent, scraped a page to 20,000 characters of markdown, and refused an agent task when maxCredits was too low.
Copy this line to your agent to give it Firecrawl alongside every other tool it needs.
set up https://monid.ai/SKILL.md and use firecrawl /map then /scrape on a site
On 2026-09-15 we ran three Firecrawl endpoints through one key. Map returned every URL on a site, 484 of them, instantly. Scrape turned one page into twenty thousand characters of markdown with the publish date attached. Agent, asked a question with a credit cap set too low, refused in plain English and charged nothing; asked again without the cap, it answered in a minute with a citation on every field. Wiring that into Claude is the question people search for, and it has two honest answers. This guide runs through Monid, the OpenRouter for agent tools.
How do you use Firecrawl with Claude?
Give Claude a tool that calls Firecrawl, and the whole decision is which tool that is: Firecrawl's own MCP server, or one MCP server that carries Firecrawl and everything else the agent will need.
The two wirings
Direct. Firecrawl publishes an MCP server. You install it, give it a Firecrawl API key, and Claude gains scrape, crawl, map, search and extract as tools. One vendor, one key, one server per vendor.
Through a tool layer. Monid publishes one MCP server that exposes discover, inspect and run. Claude asks it what tools exist, reads the schema of the one it wants, and calls it. Firecrawl's endpoints are in the catalog next to a thousand others, on one key and one balance.
What is the same
The calls. firecrawl/scrape through Monid takes the same url and formats and returns the same markdown and metadata as the direct route. We are not proxying a different product; we are billing the same product per call on a shared balance.
What is different
The number of keys, and what happens when the job turns out to need a second vendor. A research agent that starts with "scrape this page" usually ends with "and enrich the company on it" or "and search for three more like it", and each of those is a different provider with a different signup on the direct route. On the tool-layer route it is the same key.
The honest version of the choice
If Claude will only ever need Firecrawl, the direct MCP server is simpler and there is no reason to add a layer. If Claude will need Firecrawl and anything else, the layer is the difference between one integration and several. That is the same split argued in MCP vs API for AI agents, and it is a question about your agent, not about Firecrawl.
📖 See also What Is an MCP Gateway?
Firecrawl MCP server or one MCP server for every tool?
One server per vendor scales with the number of vendors. One server for the catalog scales with nothing, and the cost is a discovery step the agent runs itself.
What the agent does on each route
On the direct route, Claude has a fixed tool list: the Firecrawl tools you installed. It picks from them. It cannot reach anything you did not install.
On the tool-layer route, Claude calls discover with a description of what it needs, gets back ranked endpoints with provider, price and a verified flag, calls inspect on the one it wants to read the exact schema, and then calls run. The first two steps are free. The tool list is the catalog, and the agent chooses at run time.
What that buys
Late binding. The agent decides which scraper to use after seeing the task, not when you configured the server. A page that Firecrawl handles well and a PDF that another endpoint handles better are one decision away from each other.
One balance. Every call, from every provider, on one account, with the price shown before anything bills. No per-vendor plan to idle against.
One schema discipline. Every endpoint's input is readable through the same inspect call, which is how our own runs in this article found the maxCredits parameter before we tripped on it.
What it costs you
A discovery hop, and a layer you did not write between Claude and the vendor. For a single-vendor agent that is overhead. For a multi-vendor agent it is the integration you would otherwise build yourself, and the gateway comparison is about exactly where that line falls.
For agents
Grab an API key at app.monid.ai, then paste this to your agent and hand it the key:
set up https://monid.ai/SKILL.md
It learns the whole discover, inspect, run workflow itself. More in the agent quickstart.
For humans
npm install -g @monid-ai/cli
monid keys add -k <your-api-key> -l main
What do map, scrape and agent each actually return?
Three different shapes, and "use Firecrawl" is not a complete instruction until you have said which.
Step 1. Map: every URL on a site
What it does. Lists a site's URLs without scraping them.
The endpoints. firecrawl/map, billed per call, takes url.
The call.
monid run -p firecrawl -e /map -i '{"url": "https://monid.ai"}'
What comes back. On 2026-09-15, 484 links for our own domain, each with url, title and description, in under a second.
What it costs. A tenth of a cent for the whole site map. Current figures at monid.ai/tools. This is the cheapest way we know to answer "what is on this domain", and it is the step the URL discovery guide recommends before any crawl.
Step 2. Scrape: one page as markdown
What it does. Renders one URL and returns clean text plus page metadata.
The endpoints. firecrawl/scrape, tiered per call, takes url and formats.
The call.
monid run -p firecrawl -e /scrape \
-i '{"url": "https://monid.ai/blog/guides/hunter-io-api-domain-search-vs-email-finder", "formats": ["markdown"]}'
What comes back. data.markdown, 20,646 characters for one guide, and data.metadata carrying title, ogTitle, ogDescription, ogImage, publishedTime, modifiedTime and the article and twitter card tags.
What it costs. A fraction of a cent at the base tier. The publishedTime and modifiedTime fields are what a freshness-aware RAG index keys re-embedding on, which is the argument in the RAG extraction guide.
Step 3. Agent: a question, answered with citations
What it does. Runs a multi-page research task and returns structured data with a source URL per field.
The endpoints. firecrawl/agent, per call, requires prompt, takes urls, schema, strictConstrainToURLs, maxCredits.
The call.
monid run -p firecrawl -e /agent -w \
-i '{"prompt": "What is the title of the most recent guide on https://monid.ai/blog and when was it published?"}'
What comes back. After 62 seconds:
{
"status": "completed",
"data": {
"title": "Ahrefs API by the Call: Domain Rating, Backlinks, Paid Pages",
"title_citation": "https://monid.ai/blog/guides/ahrefs-api-domain-rating-backlinks",
"published_at": "Sep 14, 2026",
"published_at_citation": "https://monid.ai/blog"
},
"message": "The blog index identifies this as the first and most recent item on page 1; it reports 112 posts across 5 pages."
}
Correct, and every field carries a _citation URL. It also volunteered that the index had 112 posts across five pages, which we did not ask for and which was true.
What it costs. Per call at the base, with the agent's own credit consumption governed by maxCredits. The next section is about that parameter.
Give this to your agent
Set up https://monid.ai/SKILL.md, and then use Monid to map this domain, scrape the ten most recently modified pages to markdown, and give me their publish dates and a one-line summary of each.Why did the agent refuse instead of answering?
Because we told it to stop before it could finish, and it did exactly that, loudly and for free.
The first attempt
Same question, but with urls constrained to the blog index, strictConstrainToURLs: true, and maxCredits: 20. The provider returned HTTP 500 with this body:
{ "status": "failed", "error": "Refusal: Error: Agent reached max credits", "creditsUsed": 0 }
No answer, no partial answer, creditsUsed: 0, and the run was not billed.
What that means
maxCredits is a hard ceiling on the agent's internal spend. Twenty was below what a multi-page research task needs, so the agent stopped rather than returning a half-finished guess. That is the correct behaviour for a research tool: a refusal you can read beats a confident answer built on the two pages it managed to fetch before the cap.
Why it arrived as a 500
The provider reports a refused task as a server error with a structured body. Through Monid the run record shows status: COMPLETED because the call was delivered and the provider answered; the refusal is in providerResponse. Check providerResponse.httpStatus and read the error string, the same discipline noted for a 422 in the Reddit scraper comparison.
The rule
Set maxCredits as a budget you can afford to lose, not as a guess at what the task costs. Too low and you get a free refusal, which is the good outcome. Leave it off for a first run to see what the task actually consumes, then cap the batch. And when you do constrain URLs, expect the agent to need more credits, not fewer: constraint is work.
Which endpoint should I use for which job?
| Endpoint | What it does | Input | Output | Best for | Billing |
|---|---|---|---|---|---|
firecrawl/map | List a site's URLs | url | Links with title and description | The first call on any domain | Per call |
firecrawl/scrape | One page to markdown | url, formats | Markdown plus metadata with dates | Feeding a page to a model | Tiered per call |
firecrawl/crawl | Whole site to content | url, limits | Pages as markdown | Building an index | Tiered per call |
firecrawl/search | Web search, optionally scraped | query | Results with content | Finding pages you do not have URLs for | Tiered per call |
firecrawl/agent | Multi-page research to structured data | prompt, schema, maxCredits | Fields with per-field citations | A question, not a URL | Per call plus credits |
Every row was verified with monid inspect on 2026-09-15. The table gives billing shape rather than figures, because shape drives design and current numbers live on monid.ai/tools.
Map before crawl, always. Map is one cheap call that tells you the crawl's size before you pay for it, and on our domain that was 484 pages, which is a very different crawl from the forty you might have guessed.
When is Firecrawl the wrong tool?
Four cases.
The site has an API. Scraping a page that has a documented data endpoint is paying to reconstruct a table the site would hand you for free. Check for the API first; the scrape is the fallback.
You need a fixed presenter of real-time data at scale. Firecrawl renders pages; it is not a streaming or high-frequency source. For rank tracking, price monitoring on a schedule or anything polled by the minute, the structured routes compared in the SERP tracking guide are the shape you want.
You are running your own crawler already and it works. Crawl4AI and similar tools exist, and if you have the infrastructure and the maintenance appetite, a hosted scraper adds a bill without adding capability. The per-call route wins when you do not want to own the browser fleet.
You want the agent to guess. It will not. A maxCredits cap it cannot finish under produces a refusal, not a partial. If the workflow needs a best-effort answer on every call regardless of completeness, this is the wrong tool and that is to its credit.
And the disclosure: this is Monid's blog and we resell Firecrawl. The honest thing this article says is that if Firecrawl is the only tool your agent needs, Firecrawl's own MCP server is the simpler choice and you should use it.
Conclusion
Using Firecrawl with Claude is a wiring decision with two honest answers: the vendor's own MCP server when Firecrawl is the only tool, or one MCP server carrying the whole catalog when it is one tool among several. The endpoints are identical either way, and the difference is the number of keys you hold and whether the agent can reach a second vendor without you configuring it.
What matters more than the wiring is knowing which of Firecrawl's shapes you are calling. Map is a URL list for a tenth of a cent. Scrape is one page with its publish date attached. Agent is a question answered with a citation on every field, and it would rather refuse than guess when its credit cap runs out. Three tools, one name, and "use Firecrawl" is not an instruction until you have picked one.
Free next step: run monid inspect -p firecrawl -e /agent and read the maxCredits description before your first research call, then map your own domain and see how many pages you actually have. Start at monid.ai.
FAQ
Does Firecrawl have a free tier?
Firecrawl offers a free credit allowance on signup and paid plans above it, priced in credits per month. Through Monid the same endpoints are metered per call with no plan, so there is no monthly allowance to exhaust and no tier to upgrade; a map call is a tenth of a cent and a scrape is a fraction of one. Which is cheaper depends on your volume shape: steady daily crawling favours a plan, bursty and occasional use favours metering. Inspect is free either way and shows the current figure.
Can Firecrawl extract data into a JSON schema?
Yes. The agent endpoint accepts a schema parameter, a JSON Schema describing the fields you want, and shapes its extraction to it. Our run without a schema still returned structured fields with a _citation URL on each, and a schema makes those fields predictable across many runs, which is what a pipeline needs. Pair it with urls to constrain where the agent looks, and raise maxCredits when you do, because constraint costs the agent more work, not less.
What is the difference between crawl and map?
Map lists URLs without fetching their content, in one cheap call. Crawl fetches every page and returns its content as markdown, priced per page. On our domain, map returned 484 links in under a second; a crawl of the same site would be 484 scrapes. Run map first to size the job and to pick which pages are worth crawling, then crawl the subset. Crawling without mapping is paying to discover a site's size after the fact.
Are there rate limits or concurrency caps?
The provider enforces them and they surface through Monid as errors rather than silent truncation, so a batch that runs too hot fails loudly. The agent endpoint additionally has maxCredits as a per-task ceiling, and hitting it produces a refusal with creditsUsed reported. For a large crawl, map first, then scrape with modest concurrency, and read the provider status on every response rather than only the run status.
Last updated September 2026.
