firecrawl-mcp
Server Details
Adds powerful web scraping and search to Cursor, Claude and any other LLM clients.
- Status
- Healthy
- Uptime
- 100.0% over 70 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
Scored across 3 tools
The core split between parsing local documents, scraping a URL, and searching the web is clear enough. However, scrape and search both discuss Alexandria providers and similar output formats, creating some overlap in provider-discovery versus execution workflows.
All three tools use the same firecrawl_ prefix followed by a concise verb: parse, scrape, search. The snake_case convention is consistent and predictable.
Three tools are a lean core for a broad web-data server, and each is quite multi-purpose. The descriptions reference several additional Firecrawl tools that are not exposed, making the set feel under-scoped relative to the stated capabilities.
Search, scrape, and parse cover a basic pipeline, but the descriptions repeatedly direct agents to firecrawl_map, firecrawl_crawl, firecrawl_find_tools, firecrawl_gov_search, and firecrawl_research_* tools that are absent. These dead-end references create significant gaps for crawling, mapping, and specialized search workflows.
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 | ||
| 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}`. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile (readOnly, non-destructive, closed-world); the description adds substantial behavior beyond them — the two-call hosted upload handshake, PII redaction semantics, the authentication prerequisite for zeroDataRetention, and the optional scrapeId feedback hook. No contradiction with the read-only annotation.
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-loaded with purpose and supported inputs, then the two-phase flow, then behavioral notes. Every sentence carries information, though the paragraph is dense and slightly long given how many schema-level details remain.
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?
An output schema exists so return values needn't be detailed, and annotations cover safety. The description handles the two-phase upload model and auth requirements well, but with 19 parameters and low schema coverage it still leaves many optional parameters unexplained, which an agent working from this tool alone would need.
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 26%, so the description must carry the load. It explains the critical flow parameters (filePath phase 1, uploadRef phase 2, pdfOptions.maxPages, redactPII, zeroDataRetention, formats) but leaves roughly a dozen parameters (proxy, parsers, excludeTags/includeTags, jsonOptions, queryOptions, storeInCache, onlyMainContent, declaredSizeBytes, removeBase64Images, skipTlsVerification) undocumented in both schema and description.
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), enumerates the output formats (markdown, HTML, links, summary, answers, JSON), and names supported input types. It explicitly carves out the sibling boundary by saying remote web URLs belong in firecrawl_scrape, so the agent can distinguish it from firecrawl_scrape without reading the 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?
Explicitly routes the agent: local MCP reads filePath, hosted MCP requires a two-phase filePath-then-uploadRef flow with an explicit 'do not send both together' warning, and remote URLs go to firecrawl_scrape. It also conditions zeroDataRetention on an eligible authenticated account and tells the agent to omit it for keyless use.
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.
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 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. | |
| 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 | ||
| 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. |
| 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. |
| 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 mark it read-only, open-world, and non-destructive, and the description adds useful behavioral context: cached/indexed content may be served, maxAge controls staleness, successful responses do not confirm freshness, profiles load saved session data without saving changes, and alexandria providers may require accepted terms. These are meaningful operational details beyond the annotations.
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 definition is front-loaded: the first sentence explains the core action and output formats, followed by usage guidance and behavioral caveats. It is long, but the length is largely justified by the tool's 28 parameters and multiple operational modes; a few details, such as scrapeId feedback, are niche but not disruptive.
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 the output schema and annotations, the description does not need to explain return values or safety hints, and it covers the main selection criteria, format choices, caching behavior, profiles, and alexandria mode. The remaining gap is that many of the 28 parameters are undocumented, which keeps it from being fully complete despite strong high-level coverage.
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?
The description adds real meaning for key parameters such as formats, maxAge, profile, and alexandria, including default markdown output and JSON/query modes. However, with 28 parameters and only 25% schema description coverage, many parameters such as proxy, waitFor, includeTags/excludeTags, storeInCache, onlyMainContent, redactPII, and screenshotOptions are left unexplained in both schema and description.
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 first sentence states a specific verb and resource: "Scrape one URL and return its content," then enumerates the main output formats. It also distinguishes itself from firecrawl_search, firecrawl_map, and firecrawl_crawl by describing when each is appropriate.
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?
It gives explicit usage criteria: use this when the request identifies a page and needs its content or defined fields, with concrete examples like a URL, PDF, prices, specs, or table extraction. It also names alternatives, including firecrawl_search for additional web sources and firecrawl_map/firecrawl_crawl for authenticated site collections.
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
Search web, news, or image sources and return ranked results with query-relevant highlights. Use it for current information, or to list businesses, people, products, jobs or events with websites, prices or contacts. Each web result is a title, URL, and description; use firecrawl_scrape on a result URL when the excerpt is not enough.
Authenticated search also returns matching Alexandria data providers in data.tools (companies, people, jobs, finance and filings, public records and government spending, real estate, places and restaurants, retail and prices, package registries and developer data, news, research, and more). Prefer a provider over scraping pages when the task needs the same fields across several entities, exact figures or timestamps, provenance, or many records; use web results when they already answer the question. 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 capabilities; firecrawl_find_tools returns their contracts and firecrawl_scrape with an alexandria body executes a selected capability. Keyless sessions get no Alexandria matches in data.tools.
For a programming question, add categories: ["developer"]; its hits return in data.web with category: "developer". For a legal or regulatory question, categories: ["gov"] returns hits 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. categories: ["research"] restricts web results to research-affiliated websites; the firecrawl_research_* tools are a separate surface over paper abstracts and full text (PubMed, bioRxiv, medRxiv, arXiv). Returns source-type result groups and usage metadata. Authenticated responses can include an id for optional search feedback.
| 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. | |
| 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`. |
| 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. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only assert readOnly/openWorld/non-destructive; the description adds far more: authenticated vs keyless session behavior, that authenticated searches always inject alexandria (so sources:["web"] still returns providers), that keyless sessions get no data.tools matches, the optional id for feedback, and a caution to verify issuer/jurisdiction/status/version before citing gov law. That is substantial context beyond structured hints.
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?
Purpose and the scrape alternative are correctly front-loaded, but the body is five dense paragraphs with several overloaded sentences. The sources/domainTools sentence is duplicated nearly verbatim from the schema's own description, and the gov caveat is repeated in both fields, so not every sentence earns its place.
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?
Output schema exists, so return format needn't be described, and the description still covers session modes, provider discovery flow, category routing, and escalation to scrape/gov/research tools. Minor gaps remain for the undocumented limit/tbs/filter/location/enterprise params, which neither the description nor schema explains.
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?
With 15 params at 67% schema coverage, baseline is 3. The description does add real meaning for `categories` (developer/gov hits land in data.web with a category field; gov cannot combine with other categories) and `sources`/`domainTools` interaction, but it leaves tbs, limit, filter, location, enterprise, highlights and toolDetail to the schema, so it does not compensate for the remaining coverage gap.
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 specific verb+resource ('Search web, news, or image sources and return ranked results'), states the return shape (title, URL, description), and explicitly distinguishes itself from sibling firecrawl_scrape by naming when to escalate to it. An agent can place this tool without opening any 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?
Explicit when-to-use ('current information', business/person/product listings) and when-not ('use web results when they already answer the question'), plus named alternatives: firecrawl_scrape for full text, Alexandria providers for cross-entity fields, firecrawl_find_tools for contracts, firecrawl_gov_search for gov, firecrawl_research_* for papers. Also gives a fallback rule for non-US legal questions.
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- 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."
1 tool update
- Changed
firecrawl_search1 field changed- changed
Input schema / properties / scrapeOptions / descriptionPrevious value: -"Attach page content for web results in the same call. These fetches ignore maxAge, so use firecrawl_scrape when you need a live fetch. scrapeOptions fetches web pages, never Alexandria provider tools."New value: +"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."
2 tool updates
- Changed
firecrawl_scrape1 field changed- added
Input schema / requiredAdded value: +[ + "objective" +]
- Changed
firecrawl_search1 field changed- changed
Input schema / requiredPrevious value: -[ - "query" -]New value: +[ + "query", + "objective" +]
1 tool update
- Changed
firecrawl_search1 field changed- changed
Input schema / properties / sources / descriptionPrevious value: -"Search sources; authenticated sessions default to web + alexandria, keyless sessions to web only. A search with sources: [\"web\"] omits semantic provider discovery; domainTools: true can still return website-matched tools. Web-only results use domainTools: false. Use [\"alexandria\"] alone for provider discovery without web results."New value: +"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."
2 tool updates
- Changed
firecrawl_scrape1 field changed- removed
Input schema / requiredRemoved value: -[ - "objective" -]
- Changed
firecrawl_search1 field changed- changed
Input schema / requiredPrevious value: -[ - "query", - "objective" -]New value: +[ + "query" +]
3 tool updates
- Changed
firecrawl_parse1 field changed- removed
Output schema / descriptionRemoved value: -"Parsed document content, or the upload instructions for the hosted two-call flow."
- Changed
firecrawl_scrape1 field changed- removed
Output schema / descriptionRemoved value: -"A scraped document, or the Alexandria execution envelope when `alexandria` was passed."
- Changed
firecrawl_search1 field changed- removed
Output schema / descriptionRemoved value: -"Ranked search results grouped by source."
1 tool update
- Changed
firecrawl_search1 field changed- removed
Input schema / properties / clientModelRemoved value: -{ - "description": "Optional model identifier, if known.", - "maxLength": 128, - "minLength": 1, - "type": "string" -}
2 tool updates
- Changed
firecrawl_scrape1 field changed- added
Input schema / requiredAdded value: +[ + "objective" +]
- Changed
firecrawl_search2 fields changed- changed
Input schema / properties / objective / descriptionPrevious value: -"Optional broader goal for this search, if known. Avoid sensitive information."New value: +"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." - changed
Input schema / requiredPrevious value: -[ - "query" -]New value: +[ + "query", + "objective" +]
Related MCP Servers
- AlicenseNot gradedqualityCmaintenancePerplexity for social: ask what competitors are running across social and get answers grounded in real ad and creative data, not guesses.2Apache 2.0
- AlicenseCqualityBmaintenanceCompetitor Monitor AI - MCP server providing AI-powered tools and automation by MEOK AI Labs113 npm54 PyPIMIT
- AlicenseAqualityCmaintenanceEnables brand visibility monitoring across major AI platforms like ChatGPT, Claude, Gemini, and Perplexity. It allows users to track visibility scores, analyze competitor data, and receive actionable insights to improve AI-generated brand recommendations.164 npm1MIT

industrylens-mcpofficial
AlicenseNot gradedqualityBmaintenanceBrowse IndustryLens's published competitive-intelligence reports and head-to-head competitor comparisons from any AI agent — real, source-backed data.MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.