Firecrawl MCP Server
Server Details
Firecrawl, the context API for AI agents: search, scrape, interact with the web, plus paper search.
- Status
- Healthy
- Uptime
- 100.0% over 41 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- firecrawl/firecrawl-mcp-server
- GitHub Stars
- 7,770
- Server Listing
- Firecrawl MCP Server
- ChatGPT
- –
- Claude
- –
TDQS
Scored across 3 tools
The three tools have mostly distinct purposes: search discovers web results, scrape fetches a single URL, and parse extracts content from a local document. The boundary between parse and scrape can blur for PDFs or HTML files, but the descriptions explicitly direct remote URLs to scrape and local files to parse.
All tools follow the same predictable firecrawl_verb pattern using lowercase snake_case. The verbs parse, scrape, and search are concise and clearly describe the action.
Three tools is a lean but reasonable surface for core web search, scraping, and document parsing. It is slightly under-scoped given the broader Firecrawl feature set referenced in the descriptions.
The server covers the core single-page and document workflows, but notable Firecrawl operations such as crawl, map, batch scraping, and dedicated structured extraction are absent. Agents can partially work around these gaps by repeating scrape and search calls.
Available Tools
3 toolsfirecrawl_parseFirecrawl file parsingARead-onlyInspect
Parse one supported document into markdown, HTML, links, summary, targeted answers, or JSON matching a schema. Supported inputs include common HTML, PDF, Word, RTF, OpenDocument, and spreadsheet files; PDF parsing can be bounded with pdfOptions.maxPages.
Local MCP reads filePath from the server filesystem. Hosted MCP uses two calls: first provide filePath to receive upload instructions, upload locally, then call again with the returned uploadRef; do not send both fields together. Remote web URLs belong in firecrawl_scrape.
Set redactPII to request redaction of personally identifiable information in the returned content. zeroDataRetention requires an eligible authenticated account; omit it for anonymous keyless use. Returns upload instructions for hosted phase one or parsed document content for the final call. Authenticated final responses can include a data.metadata.scrapeId for optional parse feedback.
| Name | Required | Description | Default |
|---|---|---|---|
| proxy | No | ||
| maxAge | No | Ignored: parse never reuses or stores indexed content. | |
| formats | No | ||
| parsers | No | ||
| filePath | No | Phase 1 only: path to the local file on the caller/harness machine. Hosted MCP will not read or stat this path; it is used only to produce upload instructions. | |
| redactPII | No | ||
| uploadRef | No | Phase 2 only: short-lived upload reference returned by phase 1 after the local PUT upload completes. | |
| pdfOptions | No | ||
| contentType | No | Phase 1 MIME type override. If omitted, the server infers it from the file extension without reading the file. | |
| excludeTags | No | ||
| includeTags | No | ||
| jsonOptions | No | ||
| queryOptions | No | ||
| storeInCache | No | ||
| conversationId | No | conversationId from any earlier Firecrawl tool result in this conversation; after parallel calls, any one of theirs. Omit only on the first call of a conversation; the result returns one to pass on every later call. | |
| onlyMainContent | No | ||
| declaredSizeBytes | No | Optional phase 1 size declaration. Hosted MCP does not stat the file; provide this only if the caller already knows it. | |
| zeroDataRetention | No | ||
| removeBase64Images | No | ||
| skipTlsVerification | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| raw | No | Response body when it was not JSON. |
| data | No | Parsed document content; can include `data.metadata.scrapeId` for parse feedback. |
| mode | No | Which phase of the hosted flow produced this response. |
| error | No | Error message or error object when the call did not succeed. |
| notes | No | Hosted phase one: constraints on completing the upload flow. |
| upload | No | Hosted phase one: how to upload the local file. |
| message | No | Guidance for the next call. |
| success | No | Whether the API call succeeded. |
| warning | No | Non-fatal warning about the result. |
| agent_hints | No | Optional response guidance from the Firecrawl API. |
| nextToolCall | No | Hosted phase one: the second `firecrawl_parse` call to make once the upload succeeds, as `{name, arguments}`. |
| conversationId | No | Pass on later Firecrawl calls in this conversation. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the two-phase hosted flow with what each phase returns, the authenticated-account requirement for `zeroDataRetention`, PII redaction semantics, and the optional `data.metadata.scrapeId` feedback channel. It does not address failure modes or size limits beyond the brief `pdfOptions.maxPages` mention.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Organized into a purpose sentence, an input/mode paragraph, and a parameters/returns paragraph, so the mode distinction is front-loaded where an agent needs it. Dense but nearly every sentence carries operational information; the only near-redundancy is restating return values that the output schema already supplies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return values needn't be spelled out, and the critical path (local vs hosted, phase 1 vs phase 2, PDF bounding) is well covered. For a 20-parameter tool with only 30% schema coverage, though, roughly half the options remain opaque to an agent that wants to control tags, image handling, or JSON/query extraction behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 30% across 20 parameters, so the description carries real weight, and it does clarify `filePath`/`uploadRef` phase semantics, `pdfOptions.maxPages`, `redactPII`, and the output-format family of `formats`. However, many parameters (`proxy`, `parsers`, `includeTags`/`excludeTags`, `onlyMainContent`, `storeInCache`, `removeBase64Images`, `skipTlsVerification`, `jsonOptions`) get no meaning from either source, so the gap is only partly closed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (parse) and resource (one supported document) plus the concrete output formats, lists the accepted input file types, and explicitly routes remote web URLs to firecrawl_scrape. An agent can separate this from both siblings without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use conditions: local MCP reads `filePath` from the server filesystem, hosted MCP requires the two-call upload flow, and neither `filePath` nor `uploadRef` may be sent together. It also names the alternative (`firecrawl_scrape`) and the condition that selects it, plus when to omit `zeroDataRetention`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
firecrawl_scrapeFirecrawl scrapeARead-onlyInspect
Scrape one URL and return its content: markdown by default, or HTML, links, screenshots, branding data, a targeted answer, or JSON matching a supplied schema. Use it when the request identifies a page and needs its content or defined fields: the user gives a URL or names a page or PDF and wants it read or summarized, or wants prices, specs, contact details or a table from it. Use firecrawl_search when additional web sources are needed; on an authenticated session, firecrawl_map lists a site's URLs and firecrawl_crawl collects a set of pages. url may omit the scheme (example.com/page); it is read as https.
Firecrawl may serve recently indexed content; set maxAge: 0 for a live fetch or a smaller maxAge to bound staleness. A successful response does not by itself confirm the page is still current. A named browser profile loads saved session data without saving changes to it. Authenticated responses can include a metadata.scrapeId for optional scrape feedback.
On an authenticated session, firecrawl_search and firecrawl_find_tools can discover providers for the same fields across several pages; a matching provider returns typed records in one call.
With alexandria in place of url, the tool runs catalogued provider capabilities instead of fetching a page. Some providers require accepted terms; when a response reports a terms requirement, direct the user to the Firecrawl dashboard URL in that response.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| proxy | No | ||
| maxAge | No | ||
| mobile | No | ||
| formats | No | ||
| parsers | No | ||
| profile | No | Loads a saved browser profile without saving changes to it. | |
| timeout | No | Execution timeout in milliseconds. | |
| waitFor | No | ||
| location | No | ||
| lockdown | No | ||
| objective | Yes | The user's underlying goal for this call, in one sentence: what they are ultimately trying to accomplish, not a restatement of the URL or query. Reuse it across related calls. Avoid sensitive information. | |
| redactPII | No | ||
| requestId | No | Idempotency key bound to one Alexandria execution payload. Generated when omitted and returned with the result. | |
| alexandria | No | Catalogued Alexandria capability invocation, mutually exclusive with url. One {provider, capability, options} object or an array of 1-10, with contracts available through firecrawl_search or firecrawl_find_tools. Each call may include version to pin a published workflow; omitting it uses latest. Only requestId and timeout are supported alongside alexandria. The selected contract marks required inputs and any requiresOneOf groups (at least one member per group); it may include example.request/example.response and a key field under response (which may differ from records). Where pagination is declared, its fields govern paging with the same filters; catalogue next is separate from provider pagination. Returns per-capability results in data.alexandria with data, records, or an error with a code; individual capabilities can fail even when the outer response succeeds. Some providers require accepted terms; when a response reports a terms requirement, direct the user to the Firecrawl dashboard URL in that response. | |
| pdfOptions | No | ||
| toolDetail | No | URL mode only: domain discovery detail, summary by default; compact returns provider/capability/description, full includes contracts. Ignored with alexandria. | |
| domainTools | No | URL mode only: include domain-matched Alexandria tools for the page in tools on the returned document. Ignored with alexandria. | |
| excludeTags | No | ||
| includeTags | No | ||
| jsonOptions | No | ||
| queryOptions | No | ||
| storeInCache | No | ||
| conversationId | No | conversationId from any earlier Firecrawl tool result in this conversation; after parallel calls, any one of theirs. Omit only on the first call of a conversation; the result returns one to pass on every later call. | |
| onlyMainContent | No | ||
| screenshotOptions | No | ||
| zeroDataRetention | No | ||
| removeBase64Images | No | ||
| skipTlsVerification | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | No | Alexandria mode: per-capability results in `data.alexandria`, each with `data`, `records`, or an `error`. |
| html | No | Processed HTML of the page. |
| json | No | Structured data matching the requested JSON schema or prompt. |
| menu | No | Menu data extracted from the page. |
| audio | No | Audio extracted from the page. |
| error | No | Error message or error object when the call did not succeed. |
| links | No | Links found on the page. |
| pages | No | Physical PDF pages, when `parsers[].pages` is set. |
| tools | No | Domain-matched Alexandria tools for the page, when `domainTools` is set. |
| video | No | Video extracted from the page. |
| answer | No | Targeted answer to the question that was asked of the page. |
| blocks | No | Typed PDF layout blocks, when `parsers[].blocks` is set. |
| images | No | Images found on the page. |
| actions | No | Results of the browser actions that ran during the scrape. |
| message | No | Guidance that accompanies the result. |
| product | No | Product data extracted from the page. |
| rawHtml | No | Unprocessed HTML of the page. |
| receipt | No | Billing receipt for the execution. |
| success | No | Whether the API call succeeded. |
| summary | No | Summary of the page content. |
| warning | No | Non-fatal warning about the result. |
| branding | No | Branding data extracted from the page. |
| delivery | No | `retained` when the full result stayed server-side instead of being inlined. |
| markdown | No | Page content as markdown. |
| metadata | No | Page metadata; authenticated responses can include `metadata.scrapeId` for scrape feedback. |
| nextTool | No | A follow-up tool call (`{name, arguments}`) that continues or inspects this result. |
| requestId | No | Identifier of this Alexandria execution. |
| scrape_id | No | Identifier of the underlying scrape. |
| attributes | No | Values collected by the requested attribute selectors. |
| highlights | No | Highlighted passages from the page. |
| screenshot | No | Screenshot of the page. |
| agent_hints | No | Optional response guidance from the Firecrawl API. |
| creditsCost | No | Credits this call consumed. |
| workspaceId | No | Workspace holding a retained result, for inspection through virtual Bash. |
| feedbackRefs | No | Retained results only: `[{provider, capability, feedbackRef}]` per call; pass a ref in `callRatings` of the feedback tool to rate that call. |
| feedbackTool | No | Pointer to the feedback tool for reporting how this result served the task. |
| responseBytes | No | Size of the full result in bytes. |
| changeTracking | No | Change-tracking comparison against the previous scrape. |
| conversationId | No | Pass on later Firecrawl calls in this conversation. |
| idleTtlSeconds | No | Seconds a retained workspace stays available while idle. |
| estimatedTokens | No | Estimated token cost of the full result. |
| inlineTokenBudget | No | Token budget above which a result is retained rather than inlined. |
| tokenEstimateMethod | No | How `estimatedTokens` was derived. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already state read-only, open-world, and non-destructive behavior, and the description adds substantial context beyond them. It discloses indexed-content staleness and `maxAge` controls, profile behavior that does not save changes, authenticated `metadata.scrapeId`, independent Alexandria capability failures, and provider terms requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core scrape purpose and then organized by usage, freshness, authentication, and Alexandria mode. It is dense and some provider-discovery and terms language repeats schema content, but the length is largely justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists and the annotations carry the safety profile, so the description does not need to explain return values. It covers the major modes, freshness caveats, profile behavior, and Alexandria terms, but it is not fully complete because the supplied sibling `firecrawl_parse` is never differentiated and many optional parameters are only named in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 28% across 29 parameters, so the description must add meaning where the schema is sparse. It clarifies key parameters such as URL scheme omission, `maxAge` freshness behavior, `profile` session loading, response formats, and `alexandria`, but leaves many options such as proxy, mobile, waitFor, location, onlyMainContent, include/exclude tags, and screenshot/PDF options without textual semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource: scrape one URL and return its content in various formats, or run catalogued Alexandria capabilities when `alexandria` replaces `url`. It clearly separates the tool from search, map, and crawl usage, so an agent can identify the tool's core purpose immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage conditions: use it when the request identifies a page, URL, or PDF and needs its content, summaries, prices, specs, contacts, or table fields. It also routes the agent to `firecrawl_search` when additional web sources are needed and to map/crawl for authenticated site enumeration. However, it does not distinguish this tool from the supplied sibling `firecrawl_parse`, leaving one sibling relationship unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
firecrawl_searchFirecrawl web searchARead-onlyInspect
Use this when you need current or specific information from the web: recent events, latest releases and versions, prices, people and companies, statistics, or any fact that may have changed since your training data or that you are not sure of. Returns ranked results with query-relevant highlights; each web result is a title, URL, and description. Operators include quoted phrases, -term, site:host, inurl:term, intitle:term, and related:host; the set is non-exhaustive. includeDomains and excludeDomains are mutually exclusive hostname filters; categories limit result types to research, pdf, developer, or gov.
For a programming question, add categories: ["developer"]. It searches an index of public repositories, GitHub issues, merged pull requests, repository READMEs, and code documentation, and returns the results in data.web with category: "developer".
For a legal or regulatory question, categories: ["gov"] returns results in data.web with category: "gov" and cannot be combined with other categories; authenticated sessions also have firecrawl_gov_search as the dedicated tool. Verify gov results' issuer, jurisdiction, status, and version before citing current law.
Authenticated search combines web results, semantic tool summaries and domain matches. Use sources: ["alexandria"] for semantic tools only. Authenticated searches always add alexandria to the sources, so sources: ["web"] also returns providers; domainTools: false turns off website-matched tools only. On an authenticated session, tool matches describe available structured-data capabilities, not executed data. toolDetail: "compact" (default) returns only provider, capability and description; "summary" adds metadata; "full" includes their input and output contracts. firecrawl_scrape with an alexandria body executes a selected capability; firecrawl_find_tools provides catalogue browsing and full contracts.
Returns result groups in data and an operation id.
| Name | Required | Description | Default |
|---|---|---|---|
| tbs | No | ||
| limit | No | ||
| query | Yes | Query for web and semantic tool discovery. Operators include quoted phrases, `-term`, `site:host`, `inurl:term`, `intitle:term`, and `related:host`; the set is non-exhaustive. Catalogue browsing is available through firecrawl_find_tools. | |
| filter | No | ||
| sources | No | Search sources; authenticated sessions default to web + alexandria, keyless sessions to web only. Authenticated searches always add alexandria to the sources, so sources: ["web"] also returns providers; domainTools: false turns off website-matched tools only. enterprise zdr or anon searches do not add it. Use ["alexandria"] alone for provider discovery without web results. | |
| location | No | ||
| objective | Yes | The user's underlying goal for this call, in one sentence: what they are ultimately trying to accomplish, not a restatement of the URL or query. Reuse it across related calls. Avoid sensitive information. | |
| categories | No | Limit results to specific source types. `research` restricts ordinary web results to research-affiliated websites and returns page snippets, which is separate from the `firecrawl_research_*` tools that search paper abstracts and full text across biomedical (PubMed, bioRxiv, medRxiv) and arXiv literature; `pdf` searches PDF results; `developer` searches an index built for coding agents over public repositories, GitHub issues, merged pull requests, repository READMEs, and code documentation; `gov` searches the Government Index of US federal, state, and local legal and regulatory sources, the index behind firecrawl_gov_search, and cannot be combined with other categories; gov hits can include historical versions, bill text, agency guidance, and third-party reproductions, so verify the issuer, jurisdiction, enacted/effective status, and version before citing current governing law, clarify a missing jurisdiction or ambiguous as-of date, and use general search for non-US questions or missing coverage (no hits does not establish that no applicable law exists). `developer` and `gov` return hits in `data.web` with `category` set to their name; the other categories also filter `data.web`. | |
| enterprise | No | ||
| highlights | No | Return query-relevant page excerpts for web and news results when available (default). Highlights appear in web `description` and news `snippet`; otherwise, original snippets are returned. Set to false to keep the original search snippets. | |
| toolDetail | No | Compact by default. Compact returns only provider, capability and description; full includes contracts. Inspect selected compact tools with firecrawl_find_tools providers and capabilities. | |
| domainTools | No | Include domain-matched tools for result URLs. Defaults to true when Alexandria is combined with web, news or images; semantic-only search leaves domain matching off. | |
| scrapeOptions | No | Fetches the full page of every web result in the same call, and each fetched result is billed as a scrape. Leave it unset unless the task needs the full text of a few results: highlights usually answer, and firecrawl_scrape can fetch only the URLs you need. These fetches ignore maxAge, so use firecrawl_scrape for a live fetch. scrapeOptions fetches web pages, never Alexandria provider tools. | |
| conversationId | No | conversationId from any earlier Firecrawl tool result in this conversation; after parallel calls, any one of theirs. Omit only on the first call of a conversation; the result returns one to pass on every later call. | |
| excludeDomains | No | Hostnames to leave out of results. Mutually exclusive with includeDomains. | |
| includeDomains | No | Hostnames to restrict results to. Mutually exclusive with excludeDomains. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | No | Search identifier, for optional `firecrawl_search_feedback`. |
| data | No | Ranked results grouped by source, such as `web`, `news`, `images`, and `alexandria`. Each result carries its `source` and a 1-indexed `position` within that group; pass those pairs to `firecrawl_search_feedback`. |
| error | No | Error message or error object when the call did not succeed. |
| tools | No | Domain-matched Alexandria tools for the results. |
| success | No | Whether the API call succeeded. |
| warning | No | Non-fatal warning about the result. |
| nextTool | No | A follow-up tool call that continues this search. |
| agent_hints | No | Optional response guidance from the Firecrawl API. |
| creditsUsed | No | Credits this search consumed. |
| feedbackTool | No | Pointer to the feedback tool for this search. |
| conversationId | No | Pass on later Firecrawl calls in this conversation. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld annotations it discloses non-obvious behavior: authenticated searches always add alexandria to sources, keyless sessions default to web only, domainTools default depends on source mix, gov cannot combine with other categories, and tool matches describe capabilities rather than executed data. It also notes the return shape (`data` groups plus operation `id`).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the when-to-use case well, but the body is a dense multi-paragraph block where the categories, sources, domainTools and toolDetail details largely restate the schema descriptions verbatim, and it buries high-value cautions (scrape billing, gov verification) among repeated edge-case text. It earns its length functionally but is not tightly edited.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 16 parameters, nested scrapeOptions, and a rich schema plus output schema, the description covers the decision-relevant surface: source selection, categories, domain filters, tool detail, and return structure. It leaves a handful of secondary parameters (tbs, limit, filter, location, enterprise, conversationId) to the schema, which is acceptable since an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds cross-parameter meaning the schema states only thinly or not at all: includeDomains/excludeDomains mutual exclusivity, toolDetail levels and their effect, domainTools default semantics, and authenticated source defaults. Several parameters (tbs, limit, filter, location, enterprise) remain unexplained in the description, but schema coverage at 69% carries most of the rest.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a concrete use case ("current or specific information from the web: recent events, latest releases, prices...") that pins down the verb, resource, and scope. It also names the sibling boundaries explicitly by pointing to firecrawl_find_tools for catalogue browsing and firecrawl_scrape for executing capabilities / full-page fetches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit routing rules: developer category for programming questions, gov for legal/regulatory, alexandria for semantic tool discovery only, firecrawl_scrape when full text of a few results is needed, and firecrawl_find_tools for browsing contracts. Includes a warning to verify gov results and to fall back to general search when coverage is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Changed
firecrawl_scrape1 field changed- added
Output schema / properties / feedbackRefsAdded value: +{ + "description": "Retained results only: `[{provider, capability, feedbackRef}]` per call; pass a ref in `callRatings` of the feedback tool to rate that call." +}
1 tool update
- Changed
firecrawl_scrape1 field changed- removed
Input schema / properties / url / formatRemoved value: -"uri"
3 tool updates
- Changed
firecrawl_parse1 field changed- changed
Input schema / properties / jsonOptions / properties / schema / additionalPropertiesPrevious value: -{}New value: +true
- Changed
firecrawl_scrape2 fields changed- changed
Input schema / properties / alexandria / anyOfPrevious value: -[ - { - "properties": { - "capability": { - "description": "Capability address as returned by search or discover, e.g. \"series/observations\".", - "minLength": 1, - "type": "string" - }, - "options": { - "additionalProperties": {}, - "description": "Capability options as declared by its contract.", - "propertyNames": { - "type": "string" - }, - "type": "object" - }, - "provider": { - "description": "Provider slug, e.g. \"fred\".", - "minLength": 1, - "type": "string" - }, - "version": { - "description": "Optional published workflow version. Omit to use the latest version.", - "maxLength": 128, - "minLength": 1, - "type": "string" - } - }, - "required": [ - "provider", - "capability" - ], - "type": "object" - }, - { - "items": { - "properties": { - "capability": { - "description": "Capability address as returned by search or discover, e.g. \"series/observations\".", - "minLength": 1, - "type": "string" - }, - "options": { - "additionalProperties": {}, - "description": "Capability options as declared by its contract.", - "propertyNames": { - "type": "string" - }, - "type": "object" - }, - "provider": { - "description": "Provider slug, e.g. \"fred\".", - "minLength": 1, - "type": "string" - }, - "version": { - "description": "Optional published workflow version. Omit to use the latest version.", - "maxLength": 128, - "minLength": 1, - "type": "string" - } - }, - "required": [ - "provider", - "capability" - ], - "type": "object" - }, - "maxItems": 10, - "minItems": 1, - "type": "array" - } -]New value: +[ + { + "properties": { + "capability": { + "description": "Capability address as returned by search or discover, e.g. \"series/observations\".", + "minLength": 1, + "type": "string" + }, + "options": { + "additionalProperties": true, + "description": "Capability options as declared by its contract.", + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "provider": { + "description": "Provider slug, e.g. \"fred\".", + "minLength": 1, + "type": "string" + }, + "version": { + "description": "Optional published workflow version. Omit to use the latest version.", + "maxLength": 128, + "minLength": 1, + "type": "string" + } + }, + "required": [ + "provider", + "capability" + ], + "type": "object" + }, + { + "items": { + "properties": { + "capability": { + "description": "Capability address as returned by search or discover, e.g. \"series/observations\".", + "minLength": 1, + "type": "string" + }, + "options": { + "additionalProperties": true, + "description": "Capability options as declared by its contract.", + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "provider": { + "description": "Provider slug, e.g. \"fred\".", + "minLength": 1, + "type": "string" + }, + "version": { + "description": "Optional published workflow version. Omit to use the latest version.", + "maxLength": 128, + "minLength": 1, + "type": "string" + } + }, + "required": [ + "provider", + "capability" + ], + "type": "object" + }, + "maxItems": 10, + "minItems": 1, + "type": "array" + } +] - changed
Input schema / properties / jsonOptions / properties / schema / additionalPropertiesPrevious value: -{}New value: +true
- Changed
firecrawl_search1 field changed- changed
Input schema / properties / scrapeOptions / properties / jsonOptions / properties / schema / additionalPropertiesPrevious value: -{}New value: +true
3 tool updates
- Changed
firecrawl_parse2 fields changed- added
Input schema / properties / conversationIdAdded value: +{ + "description": "conversationId from any earlier Firecrawl tool result in this conversation; after parallel calls, any one of theirs. Omit only on the first call of a conversation; the result returns one to pass on every later call.", + "pattern": "^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}$", + "type": "string" +} - added
Output schema / properties / conversationIdAdded value: +{ + "description": "Pass on later Firecrawl calls in this conversation.", + "type": "string" +}
- Changed
firecrawl_scrape2 fields changed- added
Input schema / properties / conversationIdAdded value: +{ + "description": "conversationId from any earlier Firecrawl tool result in this conversation; after parallel calls, any one of theirs. Omit only on the first call of a conversation; the result returns one to pass on every later call.", + "pattern": "^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}$", + "type": "string" +} - added
Output schema / properties / conversationIdAdded value: +{ + "description": "Pass on later Firecrawl calls in this conversation.", + "type": "string" +}
- Changed
firecrawl_search2 fields changed- added
Input schema / properties / conversationIdAdded value: +{ + "description": "conversationId from any earlier Firecrawl tool result in this conversation; after parallel calls, any one of theirs. Omit only on the first call of a conversation; the result returns one to pass on every later call.", + "pattern": "^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}$", + "type": "string" +} - added
Output schema / properties / conversationIdAdded value: +{ + "description": "Pass on later Firecrawl calls in this conversation.", + "type": "string" +}
3 tool updates
- Changed
firecrawl_parse1 field changed- changed
Input schema / properties / jsonOptions / properties / schema / additionalPropertiesPrevious value: -falseNew value: +{}
- Changed
firecrawl_scrape2 fields changed- changed
Input schema / properties / alexandria / descriptionPrevious value: -"Catalogued Alexandria capability invocation, mutually exclusive with url. One {provider, capability, options} object or an array of 1-10, with contracts available through firecrawl_search or firecrawl_find_tools. Each call may include version to pin a published workflow; omitting it uses latest. Only requestId and timeout are supported alongside alexandria. The selected contract marks required inputs and any requiresOneOf groups (at least one member per group); it may include example.request/example.response and response.key (which may differ from records). Where pagination is declared, its fields govern paging with the same filters; catalogue next is separate from provider pagination. Returns per-capability results in data.alexandria with data, records, or an error with a code; individual capabilities can fail even when the outer response succeeds. Some providers require accepted terms; when a response reports a terms requirement, direct the user to the Firecrawl dashboard URL in that response."New value: +"Catalogued Alexandria capability invocation, mutually exclusive with url. One {provider, capability, options} object or an array of 1-10, with contracts available through firecrawl_search or firecrawl_find_tools. Each call may include version to pin a published workflow; omitting it uses latest. Only requestId and timeout are supported alongside alexandria. The selected contract marks required inputs and any requiresOneOf groups (at least one member per group); it may include example.request/example.response and a key field under response (which may differ from records). Where pagination is declared, its fields govern paging with the same filters; catalogue next is separate from provider pagination. Returns per-capability results in data.alexandria with data, records, or an error with a code; individual capabilities can fail even when the outer response succeeds. Some providers require accepted terms; when a response reports a terms requirement, direct the user to the Firecrawl dashboard URL in that response." - changed
Input schema / properties / jsonOptions / properties / schema / additionalPropertiesPrevious value: -falseNew value: +{}
- Changed
firecrawl_search1 field changed- changed
Input schema / properties / scrapeOptions / properties / jsonOptions / properties / schema / additionalPropertiesPrevious value: -falseNew value: +{}
1 tool update
- Changed
firecrawl_search1 field changed- changed
Output schema / properties / data / descriptionPrevious value: -"Ranked results grouped by source, such as `web`, `news`, `images`, and `alexandria`."New value: +"Ranked results grouped by source, such as `web`, `news`, `images`, and `alexandria`. Each result carries its `source` and a 1-indexed `position` within that group; pass those pairs to `firecrawl_search_feedback`."
1 tool update
- Changed
firecrawl_scrape1 field changed- changed
Input schema / properties / alexandria / descriptionPrevious value: -"Catalogued Alexandria capability invocation, mutually exclusive with url. One {provider, capability, options} object or an array of 1-10, with contracts available through firecrawl_search or firecrawl_find_tools. Each call may include version to pin a published workflow; omitting it uses latest. Only requestId and timeout are supported alongside alexandria. The selected contract marks required inputs and any requiresOneOf groups (at least one member per group); it may include example.request/example.response and response.key (which may differ from records). Where pagination is declared, its fields govern paging with the same filters; catalogue next is separate from provider pagination. Returns per-capability results in data.alexandria with data, records, or an error with a code; individual capabilities can fail even when the outer response succeeds. Requires an API key on a team with Alexandria enabled. Some providers require accepted terms; blocked requests return the applicable requirements."New value: +"Catalogued Alexandria capability invocation, mutually exclusive with url. One {provider, capability, options} object or an array of 1-10, with contracts available through firecrawl_search or firecrawl_find_tools. Each call may include version to pin a published workflow; omitting it uses latest. Only requestId and timeout are supported alongside alexandria. The selected contract marks required inputs and any requiresOneOf groups (at least one member per group); it may include example.request/example.response and response.key (which may differ from records). Where pagination is declared, its fields govern paging with the same filters; catalogue next is separate from provider pagination. Returns per-capability results in data.alexandria with data, records, or an error with a code; individual capabilities can fail even when the outer response succeeds. Some providers require accepted terms; when a response reports a terms requirement, direct the user to the Firecrawl dashboard URL in that response."
Related MCP Connectors
Web scraping, search, crawling, structured extraction and research for AI agents.
Web pages, PDFs and search results as LLM-ready Markdown or chunks. Firecrawl-compatible, EU-hosted.
Web search and page reading for AI agents with zero API credits
Web infrastructure for AI agents: scrape, crawl and search the web, run browsers and agents.
Related MCP Servers
- FlicenseAqualityNot gradedmaintenanceEnables AI-powered web data extraction and research through Firecrawl's Agent API. Autonomously searches, navigates, and scrapes websites to gather structured data without requiring specific URLs.5-
- AlicenseNot gradedqualityBmaintenanceEnables agents to scrape web pages into clean markdown, map and crawl sites, search the web, extract structured data, batch-scrape URLs, conduct multi-source research, and generate llms.txt content through Firecrawl.276 npmMIT
- AlicenseNot gradedqualityDmaintenanceEmpowers LLMs to scrape web pages and generate sitemaps through the Firecrawl Simple API, with support for JavaScript rendering and configurable options.6 npm1MIT
- FlicenseCqualityCmaintenanceBuilt as a Model Context Protocol (MCP) server that provides advanced web search, content extraction, web crawling, and scraping capabilities using the Firecrawl API.41-
Glama MCP Gateway
Add one secure layer between your agents and this server.