Firecrawl MCP Server

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.9.0
Disambiguation5/5
Each tool has a clearly distinct purpose: crawl vs deep research, extract vs scrape, map vs search, etc. Descriptions explicitly clarify when to use which, preventing ambiguity.
Naming Consistency5/5
All tools follow the 'firecrawl_' prefix with snake_case verbs (check_crawl_status, crawl, deep_research, extract, generate_llmstxt, map, scrape, search), maintaining a consistent and predictable pattern.
Tool Count5/5
8 tools is well-scoped for a web content extraction server. Each tool adds distinct functionality without redundancy, covering core operations without overwhelming the user.
Completeness4/5
The tool set covers all major workflows: scrape, crawl, search, map, extract, status tracking, and LLM interaction. A dedicated batch_scrape tool is missing but crawl and search can partially compensate.
Average 4.4/5 across 8 of 8 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It mentions returns 'status and progress' but lacks details on polling behavior, rate limits, or error recovery. Basic transparency but incomplete for an operation that may be called repeatedly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise at one sentence plus a usage example. The example provides clear invocation format. No filler, but could include a line about return structure without hurting conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status-check tool with one parameter and no output schema, the description is adequate but lacks context like prerequisite (must have called firecrawl_crawl first) and expected statuses (e.g., 'completed', 'failed').
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter 'id' with an adequate schema description. The tool description adds no further meaning beyond 'Crawl job ID to check'. Schema coverage is 100%, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb 'check status' and resource 'crawl job'. It clearly distinguishes from siblings like firecrawl_crawl (initiates crawl) and firecrawl_scrape (single page scrape) by focusing on monitoring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. While context implies it's for polling after starting a crawl with firecrawl_crawl, the description does not state when not to use it or provide usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool generates and returns file contents, but does not disclose side effects, permissions, rate limits, or whether it is read-only. The behavioral traits are implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but well-structured with clear sections (Best for, Arguments, Examples). It includes a usage example which is helpful. However, some redundancy exists (e.g., arguments listed twice). Overall efficient for the information provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description minimally explains return values ('LLMs.txt file contents'). It covers all parameters and provides usage examples. It could be more precise about the response format or data type, but is sufficient for understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description repeats parameter names and adds minor context (e.g., 'base URL'), but does not add substantial meaning beyond the schema. For maxUrls, it omits the range provided in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a standardized llms.txt file, with a specific verb and resource. It distinguishes from siblings by explicitly stating 'Best for' and 'Not recommended for' contexts, differentiating from general extraction or research tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context with 'Best for' and 'Not recommended for' sections, guiding when to use this tool over alternatives. It does not name specific sibling tools but the contrast is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses that tool discovers URLs (not content), returns an array of URLs, and provides usage example. No annotations given, but the description adequately covers the tool's read-only, non-destructive nature and return type.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with clear sections (Best for, Not recommended, Common mistakes, Examples, Returns). Each sentence adds value; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters all documented in schema and a simple return type (array of URLs), the description covers the tool's purpose and behavior adequately. Usage example further clarifies invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3. Description does not add significant extra meaning beyond the schema's parameter descriptions, but the usage example demonstrates typical invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Map' and resource 'website', clearly states outcome 'discover all indexed URLs'. Differentiates from siblings by explicitly mentioning when to use scrape, batch_scrape, or crawl instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Best for' and 'Not recommended for' sections provide clear guidance on when to use this tool vs alternatives. Also includes 'Common mistakes' to avoid using crawl for URL discovery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It explains return formats and advanced options, and gives usage examples, but does not elaborate on potential side effects or limitations beyond the schema. Still sufficient for a non-destructive scrape operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (Best for, Not recommended, Common mistakes, Prompt Example, Usage Example, Returns). Front-loaded with essential info, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 parameters, nested objects, and no output schema, the description provides sufficient context for using the tool: when, how, and what to expect. Lacks detailed output structure but the return format is stated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add significant meaning to individual parameters beyond what the schema provides, but the overall context and example help with understanding usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Scrape content from a single URL with advanced options' with a specific verb and resource, and explicitly distinguishes from sibling tools by listing best-use cases and alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use (single page extraction) and when not to use (multiple pages, unknown page, structured data), with common mistakes and direct references to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions support for both cloud AI and self-hosted LLM extraction, and states the return type ('Extracted structured data as defined by your schema'). However, it does not disclose important behavioral traits such as rate limits, authentication requirements, or whether the tool modifies any data (though it appears read-only). The description is adequate but not comprehensive in this dimension.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose, best/not recommended, arguments list, example, and returns. It is front-loaded with the main purpose and every sentence adds value. There is no redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the parameter count of 7 (all documented), no output schema, and nested objects, the description covers purpose, usage guidelines, all parameters with examples, and return type. It references sibling tools for differentiation. It is complete and self-contained for an AI agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. However, the description goes beyond by providing a prompt example and a full usage example that demonstrates how to use the parameters together, especially the 'schema' as a nested object. This added context elevates the score to 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool extracts structured information from web pages using LLM capabilities. It provides a specific verb ('Extract') and resource ('web pages'), and distinguishes itself from sibling tools by noting that it's best for structured data and not recommended for full content (which points to scrape). This meets the highest standard for purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly includes 'Best for' and 'Not recommended for' sections, giving clear when-to-use and when-not-to-use guidance. It directly references the sibling tool 'scrape' as an alternative for full page content. This provides excellent usage guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behaviors. It mentions the tool takes time, uses LLM analysis, and returns a final analysis along with structured data. However, it does not detail error handling, rate limits, or potential costs associated with deep research.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections, bold headers, and bullet points. Every sentence adds value. Includes a brief prompt example and a JSON usage example. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description covers the return format (finalAnalysis and activities/sources), parameter meanings, and usage context. It could mention error handling or output structure in more detail, but is fairly complete for a complex research tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but descriptions are minimal. The tool description adds meaningful context: explains query as 'research question or topic', provides defaults for maxDepth (3), timeLimit (120), maxUrls (50), and includes a usage example. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool conducts deep web research using crawling, search, and LLM analysis. It distinguishes this from siblings by specifying it is best for complex multi-source questions, not for simple searches or known-page scraping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states best for complex research, not recommended for simple questions, specific pages (use scrape), or when quick results are needed. Also mentions time investment, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It explains the return type (array of search results with optional scraped content) and includes parameters like time filter and location, but does not explicitly state it is non-destructive, which is minor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear sections (Best for, Not recommended for, Common mistakes, Prompt Example, Usage Example, Returns) and no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, nested objects, no output schema), the description covers the purpose, usage, parameters, and return type adequately. It includes examples and guidance, making it complete for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented. The description adds value with a usage example and contextual grouping (e.g., scrapeOptions), improving understanding beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches the web and optionally extracts content. It distinguishes from siblings like scrape, map, and crawl by providing specific use cases (Best for, Not recommended for).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given on when to use (Best for) and when not to use (Not recommended for), along with common mistakes and a detailed usage example, making it easy for an AI agent to decide correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: asynchronous nature, potential token overflow, returns operation ID for status checking, and warns about large responses. No annotations exist, so description carries full burden and meets it well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections (Best for, Warning, etc.), usage example, and prompt example. Every sentence is informative without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 12 parameters and no output schema, the description covers purpose, usage, behavioral traits, and return value. It is complete enough for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 92%, so baseline is 3. Description adds value through usage example and common mistakes (e.g., setting limit too high), enhancing understanding beyond schema, but does not detail every parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts an asynchronous crawl and extracts content from all pages, distinguishing it from siblings like scrape (single page) and map (for token concerns).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides 'Best for', 'Not recommended for' sections with specific alternatives (scrape, map + batch_scrape), and common mistakes, guiding when to use this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![firecrawl-mcp-server MCP server](https://glama.ai/mcp/servers/0xzapata/firecrawl-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/0xzapata/firecrawl-mcp-server)

Score Badge

Copy to your README.md:

[![firecrawl-mcp-server MCP server](https://glama.ai/mcp/servers/0xzapata/firecrawl-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/0xzapata/firecrawl-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/0xzapata/firecrawl-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server