Firecrawl MCP timeout: Sume crawl_scrape's 35, 40 and 45 s deadlines

A synchronous crawl_scrape call has three deadlines: client abort at 35 s, MCP at 40 s, host watchdog at 45 s. Narrow the page or use crawl_site.

4 min readSume
All posts

A crawl_scrape call made through MCP is synchronous and ends at one of three deadlines: 35 seconds for the client abort, 40 seconds for the MCP deadline, 45 seconds for the ACP host watchdog. Raising your own client timeout does not move them. When a page misses its deadline the call fails with a typed timeout error; narrow the page or switch to crawl_site.

The numbers are from the crawl_scrape tool description in Sume's MCP server code, read 2026-09-30.

Which deadline fires first?

They stack: the client aborts first, then the MCP server, then the host watchdog as a last backstop.

Where a sync scrape can end, read 2026-09-30
OrderLayerSeconds
1Client deadline/abort35
2MCP deadline40
3ACP host watchdog45

Can I wait on a scrape with jobs_wait?

No. The description states: "No jobs_wait for scrape." A scrape returns a result or a typed timeout error in the same call.

What should the agent do after a timeout?

Report that the page did not return in time and stop, as the description says. Do not bypass with web_fetch, raw HTML scripts or guessed CDN URLs. Then change the request, not the client.

Which tool handles many pages?

crawl_site is the async path. Per MCP tools and gates it is a write tool that takes an idempotency_key, then you call jobs_wait and crawl_get on the same id. For the wait-and-resume pattern in general, see jobs_wait for long jobs.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume