Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Firecrawl MCP Server scrape the latest AI news from techcrunch.com"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server implementation that integrates with Firecrawl for web scraping capabilities.
Big thanks to @vrknetha, @knacklabs for the initial implementation!
Web scraping, crawling, and discovery
Search and content extraction
Deep research and batch scraping
Automatic retries and rate limiting
Cloud and self-hosted support
SSE support
Play around with our MCP Server on MCP.so's playground or on Klavis AI.
Related MCP server: Firecrawl MCP Server
env FIRECRAWL_API_KEY=fc-YOUR_API_KEY npx -y firecrawl-mcpnpm install -g firecrawl-mcpConfiguring Cursor 🖥️ Note: Requires Cursor version 0.45.6+ For the most up-to-date configuration instructions, please refer to the official Cursor documentation on configuring MCP servers: Cursor MCP Server Configuration Guide
To configure Firecrawl MCP in Cursor v0.48.6
Open Cursor Settings
Go to Features > MCP Servers
Click "+ Add new global MCP server"
Enter the following code:
{
"mcpServers": {
"firecrawl-mcp": {
"command": "npx",
"args": ["-y", "firecrawl-mcp"],
"env": {
"FIRECRAWL_API_KEY": "YOUR-API-KEY"
}
}
}
}To configure Firecrawl MCP in Cursor v0.45.6
Open Cursor Settings
Go to Features > MCP Servers
Click "+ Add New MCP Server"
Enter the following:
Name: "firecrawl-mcp" (or your preferred name)
Type: "command"
Command: env FIRECRAWL_API_KEY=your-api-key npx -y firecrawl-mcp
If you are using Windows and are running into issues, try
cmd /c "set FIRECRAWL_API_KEY=your-api-key && npx -y firecrawl-mcp"
Replace your-api-key with your Firecrawl API key. If you don't have one yet, you can create an account and get it from https://www.firecrawl.dev/app/api-keys
After adding, refresh the MCP server list to see the new tools. The Composer Agent will automatically use Firecrawl MCP when appropriate, but you can explicitly request it by describing your web scraping needs. Access the Composer via Command+L (Mac), select "Agent" next to the submit button, and enter your query.
Add this to your ./codeium/windsurf/model_config.json:
{
"mcpServers": {
"mcp-server-firecrawl": {
"command": "npx",
"args": ["-y", "firecrawl-mcp"],
"env": {
"FIRECRAWL_API_KEY": "YOUR_API_KEY"
}
}
}
}To run the server using Server-Sent Events (SSE) locally instead of the default stdio transport:
env SSE_LOCAL=true FIRECRAWL_API_KEY=fc-YOUR_API_KEY npx -y firecrawl-mcpUse the url: http://localhost:3000/sse
To install Firecrawl for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @mendableai/mcp-server-firecrawl --client claudeFor one-click installation, click one of the install buttons below...
For manual installation, add the following JSON block to your User Settings (JSON) file in VS Code. You can do this by pressing Ctrl + Shift + P and typing Preferences: Open User Settings (JSON).
{
"mcp": {
"inputs": [
{
"type": "promptString",
"id": "apiKey",
"description": "Firecrawl API Key",
"password": true
}
],
"servers": {
"firecrawl": {
"command": "npx",
"args": ["-y", "firecrawl-mcp"],
"env": {
"FIRECRAWL_API_KEY": "${input:apiKey}"
}
}
}
}
}Optionally, you can add it to a file called .vscode/mcp.json in your workspace. This will allow you to share the configuration with others:
{
"inputs": [
{
"type": "promptString",
"id": "apiKey",
"description": "Firecrawl API Key",
"password": true
}
],
"servers": {
"firecrawl": {
"command": "npx",
"args": ["-y", "firecrawl-mcp"],
"env": {
"FIRECRAWL_API_KEY": "${input:apiKey}"
}
}
}
}FIRECRAWL_API_KEY: Your Firecrawl API key
Required when using cloud API (default)
Optional when using self-hosted instance with FIRECRAWL_API_URL
FIRECRAWL_API_URL (Optional): Custom API endpoint for self-hosted instances
Example: https://firecrawl.your-domain.com
If not provided, the cloud API will be used (requires API key)
FIRECRAWL_RETRY_MAX_ATTEMPTS: Maximum number of retry attempts (default: 3)
FIRECRAWL_RETRY_INITIAL_DELAY: Initial delay in milliseconds before first retry (default: 1000)
FIRECRAWL_RETRY_MAX_DELAY: Maximum delay in milliseconds between retries (default: 10000)
FIRECRAWL_RETRY_BACKOFF_FACTOR: Exponential backoff multiplier (default: 2)
FIRECRAWL_CREDIT_WARNING_THRESHOLD: Credit usage warning threshold (default: 1000)
FIRECRAWL_CREDIT_CRITICAL_THRESHOLD: Credit usage critical threshold (default: 100)
For cloud API usage with custom retry and credit monitoring:
# Required for cloud API
export FIRECRAWL_API_KEY=your-api-key
# Optional retry configuration
export FIRECRAWL_RETRY_MAX_ATTEMPTS=5 # Increase max retry attempts
export FIRECRAWL_RETRY_INITIAL_DELAY=2000 # Start with 2s delay
export FIRECRAWL_RETRY_MAX_DELAY=30000 # Maximum 30s delay
export FIRECRAWL_RETRY_BACKOFF_FACTOR=3 # More aggressive backoff
# Optional credit monitoring
export FIRECRAWL_CREDIT_WARNING_THRESHOLD=2000 # Warning at 2000 credits
export FIRECRAWL_CREDIT_CRITICAL_THRESHOLD=500 # Critical at 500 creditsFor self-hosted instance:
# Required for self-hosted
export FIRECRAWL_API_URL=https://firecrawl.your-domain.com
# Optional authentication for self-hosted
export FIRECRAWL_API_KEY=your-api-key # If your instance requires auth
# Custom retry configuration
export FIRECRAWL_RETRY_MAX_ATTEMPTS=10
export FIRECRAWL_RETRY_INITIAL_DELAY=500 # Start with faster retriesAdd this to your claude_desktop_config.json:
{
"mcpServers": {
"mcp-server-firecrawl": {
"command": "npx",
"args": ["-y", "firecrawl-mcp"],
"env": {
"FIRECRAWL_API_KEY": "YOUR_API_KEY_HERE",
"FIRECRAWL_RETRY_MAX_ATTEMPTS": "5",
"FIRECRAWL_RETRY_INITIAL_DELAY": "2000",
"FIRECRAWL_RETRY_MAX_DELAY": "30000",
"FIRECRAWL_RETRY_BACKOFF_FACTOR": "3",
"FIRECRAWL_CREDIT_WARNING_THRESHOLD": "2000",
"FIRECRAWL_CREDIT_CRITICAL_THRESHOLD": "500"
}
}
}
}The server includes several configurable parameters that can be set via environment variables. Here are the default values if not configured:
const CONFIG = {
retry: {
maxAttempts: 3, // Number of retry attempts for rate-limited requests
initialDelay: 1000, // Initial delay before first retry (in milliseconds)
maxDelay: 10000, // Maximum delay between retries (in milliseconds)
backoffFactor: 2, // Multiplier for exponential backoff
},
credit: {
warningThreshold: 1000, // Warn when credit usage reaches this level
criticalThreshold: 100, // Critical alert when credit usage reaches this level
},
};These configurations control:
Retry Behavior
Automatically retries failed requests due to rate limits
Uses exponential backoff to avoid overwhelming the API
Example: With default settings, retries will be attempted at:
1st retry: 1 second delay
2nd retry: 2 seconds delay
3rd retry: 4 seconds delay (capped at maxDelay)
Credit Usage Monitoring
Tracks API credit consumption for cloud API usage
Provides warnings at specified thresholds
Helps prevent unexpected service interruption
Example: With default settings:
Warning at 1000 credits remaining
Critical alert at 100 credits remaining
The server utilizes Firecrawl's built-in rate limiting and batch processing capabilities:
Automatic rate limit handling with exponential backoff
Efficient parallel processing for batch operations
Smart request queuing and throttling
Automatic retries for transient errors
Use this guide to select the right tool for your task:
If you know the exact URL(s) you want:
For one: use scrape
For many: use batch_scrape
If you need to discover URLs on a site: use map
If you want to search the web for info: use search
If you want to extract structured data: use extract
If you want to analyze a whole site or section: use crawl (with limits!)
If you want to do in-depth research: use deep_research
If you want to generate LLMs.txt: use generate_llmstxt
Tool | Best for | Returns |
scrape | Single page content | markdown/html |
batch_scrape | Multiple known URLs | markdown/html[] |
map | Discovering URLs on a site | URL[] |
crawl | Multi-page extraction (with limits) | markdown/html[] |
search | Web search for info | results[] |
extract | Structured data from pages | JSON |
deep_research | In-depth, multi-source research | summary, sources |
generate_llmstxt | LLMs.txt for a domain | text |
firecrawl_scrape)Scrape content from a single URL with advanced options.
Best for:
Single page content extraction, when you know exactly which page contains the information.
Not recommended for:
Extracting content from multiple pages (use batch_scrape for known URLs, or map + batch_scrape to discover URLs first, or crawl for full page content)
When you're unsure which page contains the information (use search)
When you need structured data (use extract)
Common mistakes:
Using scrape for a list of URLs (use batch_scrape instead).
Prompt Example:
"Get the content of the page at https://example.com."
Usage Example:
{
"name": "firecrawl_scrape",
"arguments": {
"url": "https://example.com",
"formats": ["markdown"],
"onlyMainContent": true,
"waitFor": 1000,
"timeout": 30000,
"mobile": false,
"includeTags": ["article", "main"],
"excludeTags": ["nav", "footer"],
"skipTlsVerification": false
}
}Returns:
Markdown, HTML, or other formats as specified.
firecrawl_batch_scrape)Scrape multiple URLs efficiently with built-in rate limiting and parallel processing.
Best for:
Retrieving content from multiple pages, when you know exactly which pages to scrape.
Not recommended for:
Discovering URLs (use map first if you don't know the URLs)
Scraping a single page (use scrape)
Common mistakes:
Using batch_scrape with too many URLs at once (may hit rate limits or token overflow)
Prompt Example:
"Get the content of these three blog posts: [url1, url2, url3]."
Usage Example:
{
"name": "firecrawl_batch_scrape",
"arguments": {
"urls": ["https://example1.com", "https://example2.com"],
"options": {
"formats": ["markdown"],
"onlyMainContent": true
}
}
}Returns:
Response includes operation ID for status checking:
{
"content": [
{
"type": "text",
"text": "Batch operation queued with ID: batch_1. Use firecrawl_check_batch_status to check progress."
}
],
"isError": false
}firecrawl_check_batch_status)Check the status of a batch operation.
{
"name": "firecrawl_check_batch_status",
"arguments": {
"id": "batch_1"
}
}firecrawl_map)Map a website to discover all indexed URLs on the site.
Best for:
Discovering URLs on a website before deciding what to scrape
Finding specific sections of a website
Not recommended for:
When you already know which specific URL you need (use scrape or batch_scrape)
When you need the content of the pages (use scrape after mapping)
Common mistakes:
Using crawl to discover URLs instead of map
Prompt Example:
"List all URLs on example.com."
Usage Example:
{
"name": "firecrawl_map",
"arguments": {
"url": "https://example.com"
}
}Returns:
Array of URLs found on the site
firecrawl_search)Search the web and optionally extract content from search results.
Best for:
Finding specific information across multiple websites, when you don't know which website has the information.
When you need the most relevant content for a query
Not recommended for:
When you already know which website to scrape (use scrape)
When you need comprehensive coverage of a single website (use map or crawl)
Common mistakes:
Using crawl or map for open-ended questions (use search instead)
Usage Example:
{
"name": "firecrawl_search",
"arguments": {
"query": "latest AI research papers 2023",
"limit": 5,
"lang": "en",
"country": "us",
"scrapeOptions": {
"formats": ["markdown"],
"onlyMainContent": true
}
}
}Returns:
Array of search results (with optional scraped content)
Prompt Example:
"Find the latest research papers on AI published in 2023."
firecrawl_crawl)Starts an asynchronous crawl job on a website and extract content from all pages.
Best for:
Extracting content from multiple related pages, when you need comprehensive coverage.
Not recommended for:
Extracting content from a single page (use scrape)
When token limits are a concern (use map + batch_scrape)
When you need fast results (crawling can be slow)
Warning: Crawl responses can be very large and may exceed token limits. Limit the crawl depth and number of pages, or use map + batch_scrape for better control.
Common mistakes:
Setting limit or maxDepth too high (causes token overflow)
Using crawl for a single page (use scrape instead)
Prompt Example:
"Get all blog posts from the first two levels of example.com/blog."
Usage Example:
{
"name": "firecrawl_crawl",
"arguments": {
"url": "https://example.com/blog/*",
"maxDepth": 2,
"limit": 100,
"allowExternalLinks": false,
"deduplicateSimilarURLs": true
}
}Returns:
Response includes operation ID for status checking:
{
"content": [
{
"type": "text",
"text": "Started crawl for: https://example.com/* with job ID: 550e8400-e29b-41d4-a716-446655440000. Use firecrawl_check_crawl_status to check progress."
}
],
"isError": false
}firecrawl_check_crawl_status)Check the status of a crawl job.
{
"name": "firecrawl_check_crawl_status",
"arguments": {
"id": "550e8400-e29b-41d4-a716-446655440000"
}
}Returns:
Response includes the status of the crawl job:
firecrawl_extract)Extract structured information from web pages using LLM capabilities. Supports both cloud AI and self-hosted LLM extraction.
Best for:
Extracting specific structured data like prices, names, details.
Not recommended for:
When you need the full content of a page (use scrape)
When you're not looking for specific structured data
Arguments:
urls: Array of URLs to extract information from
prompt: Custom prompt for the LLM extraction
systemPrompt: System prompt to guide the LLM
schema: JSON schema for structured data extraction
allowExternalLinks: Allow extraction from external links
enableWebSearch: Enable web search for additional context
includeSubdomains: Include subdomains in extraction
When using a self-hosted instance, the extraction will use your configured LLM. For cloud API, it uses Firecrawl's managed LLM service. Prompt Example:
"Extract the product name, price, and description from these product pages."
Usage Example:
{
"name": "firecrawl_extract",
"arguments": {
"urls": ["https://example.com/page1", "https://example.com/page2"],
"prompt": "Extract product information including name, price, and description",
"systemPrompt": "You are a helpful assistant that extracts product information",
"schema": {
"type": "object",
"properties": {
"name": { "type": "string" },
"price": { "type": "number" },
"description": { "type": "string" }
},
"required": ["name", "price"]
},
"allowExternalLinks": false,
"enableWebSearch": false,
"includeSubdomains": false
}
}Returns:
Extracted structured data as defined by your schema
{
"content": [
{
"type": "text",
"text": {
"name": "Example Product",
"price": 99.99,
"description": "This is an example product description"
}
}
],
"isError": false
}firecrawl_deep_research)Conduct deep web research on a query using intelligent crawling, search, and LLM analysis.
Best for:
Complex research questions requiring multiple sources, in-depth analysis.
Not recommended for:
Simple questions that can be answered with a single search
When you need very specific information from a known page (use scrape)
When you need results quickly (deep research can take time)
Arguments:
query (string, required): The research question or topic to explore.
maxDepth (number, optional): Maximum recursive depth for crawling/search (default: 3).
timeLimit (number, optional): Time limit in seconds for the research session (default: 120).
maxUrls (number, optional): Maximum number of URLs to analyze (default: 50).
Prompt Example:
"Research the environmental impact of electric vehicles versus gasoline vehicles."
Usage Example:
{
"name": "firecrawl_deep_research",
"arguments": {
"query": "What are the environmental impacts of electric vehicles compared to gasoline vehicles?",
"maxDepth": 3,
"timeLimit": 120,
"maxUrls": 50
}
}Returns:
Final analysis generated by an LLM based on research. (data.finalAnalysis)
May also include structured activities and sources used in the research process.
firecrawl_generate_llmstxt)Generate a standardized llms.txt (and optionally llms-full.txt) file for a given domain. This file defines how large language models should interact with the site.
Best for:
Creating machine-readable permission guidelines for AI models.
Not recommended for:
General content extraction or research
Arguments:
url (string, required): The base URL of the website to analyze.
maxUrls (number, optional): Max number of URLs to include (default: 10).
showFullText (boolean, optional): Whether to include llms-full.txt contents in the response.
Prompt Example:
"Generate an LLMs.txt file for example.com."
Usage Example:
{
"name": "firecrawl_generate_llmstxt",
"arguments": {
"url": "https://example.com",
"maxUrls": 20,
"showFullText": true
}
}Returns:
LLMs.txt file contents (and optionally llms-full.txt)
The server includes comprehensive logging:
Operation status and progress
Performance metrics
Credit usage monitoring
Rate limit tracking
Error conditions
Example log messages:
[INFO] Firecrawl MCP Server initialized successfully
[INFO] Starting scrape for URL: https://example.com
[INFO] Batch operation queued with ID: batch_1
[WARNING] Credit usage has reached warning threshold
[ERROR] Rate limit exceeded, retrying in 2s...The server provides robust error handling:
Automatic retries for transient errors
Rate limit handling with backoff
Detailed error messages
Credit usage warnings
Network resilience
Example error response:
{
"content": [
{
"type": "text",
"text": "Error: Rate limit exceeded. Retrying in 2 seconds..."
}
],
"isError": true
}# Install dependencies
npm install
# Build
npm run build
# Run tests
npm testFork the repository
Create your feature branch
Run tests: npm test
Submit a pull request
Thanks to @vrknetha, @cawstudios for the initial implementation!
Thanks to MCP.so and Klavis AI for hosting and @gstarwd, @xiangkaiz and @zihaolin96 for integrating our server.
MIT License - see LICENSE file for details
Check the status of a crawl job.
Usage Example:
{
"name": "firecrawl_check_crawl_status",
"arguments": {
"id": "550e8400-e29b-41d4-a716-446655440000"
}
}Returns: Status and progress of the crawl job, including results if available.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Crawl job ID to check |
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.
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.
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.
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.
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.
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.
Starts an asynchronous crawl job on a website and extracts content from all pages.
Best for: Extracting content from multiple related pages, when you need comprehensive coverage. Not recommended for: Extracting content from a single page (use scrape); when token limits are a concern (use map + batch_scrape); when you need fast results (crawling can be slow). Warning: Crawl responses can be very large and may exceed token limits. Limit the crawl depth and number of pages, or use map + batch_scrape for better control. Common mistakes: Setting limit or maxDepth too high (causes token overflow); using crawl for a single page (use scrape instead). Prompt Example: "Get all blog posts from the first two levels of example.com/blog." Usage Example:
{
"name": "firecrawl_crawl",
"arguments": {
"url": "https://example.com/blog/*",
"maxDepth": 2,
"limit": 100,
"allowExternalLinks": false,
"deduplicateSimilarURLs": true
}
}Returns: Operation ID for status checking; use firecrawl_check_crawl_status to check progress.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Starting URL for the crawl | |
| excludePaths | No | URL paths to exclude from crawling | |
| includePaths | No | Only crawl these URL paths | |
| maxDepth | No | Maximum link depth to crawl | |
| ignoreSitemap | No | Skip sitemap.xml discovery | |
| limit | No | Maximum number of pages to crawl | |
| allowBackwardLinks | No | Allow crawling links that point to parent directories | |
| allowExternalLinks | No | Allow crawling links to external domains | |
| webhook | No | ||
| deduplicateSimilarURLs | No | Remove similar URLs during crawl | |
| ignoreQueryParameters | No | Ignore query parameters when comparing URLs | |
| scrapeOptions | No | Options for scraping each page |
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.
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.
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.
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.
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.
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.
Conduct deep web research on a query using intelligent crawling, search, and LLM analysis.
Best for: Complex research questions requiring multiple sources, in-depth analysis. Not recommended for: Simple questions that can be answered with a single search; when you need very specific information from a known page (use scrape); when you need results quickly (deep research can take time). Arguments:
query (string, required): The research question or topic to explore.
maxDepth (number, optional): Maximum recursive depth for crawling/search (default: 3).
timeLimit (number, optional): Time limit in seconds for the research session (default: 120).
maxUrls (number, optional): Maximum number of URLs to analyze (default: 50). Prompt Example: "Research the environmental impact of electric vehicles versus gasoline vehicles." Usage Example:
{
"name": "firecrawl_deep_research",
"arguments": {
"query": "What are the environmental impacts of electric vehicles compared to gasoline vehicles?",
"maxDepth": 3,
"timeLimit": 120,
"maxUrls": 50
}
}Returns: Final analysis generated by an LLM based on research. (data.finalAnalysis); may also include structured activities and sources used in the research process.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The query to research | |
| maxDepth | No | Maximum depth of research iterations (1-10) | |
| timeLimit | No | Time limit in seconds (30-300) | |
| maxUrls | No | Maximum number of URLs to analyze (1-1000) |
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.
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.
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.
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.
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.
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.
Extract structured information from web pages using LLM capabilities. Supports both cloud AI and self-hosted LLM extraction.
Best for: Extracting specific structured data like prices, names, details. Not recommended for: When you need the full content of a page (use scrape); when you're not looking for specific structured data. Arguments:
urls: Array of URLs to extract information from
prompt: Custom prompt for the LLM extraction
systemPrompt: System prompt to guide the LLM
schema: JSON schema for structured data extraction
allowExternalLinks: Allow extraction from external links
enableWebSearch: Enable web search for additional context
includeSubdomains: Include subdomains in extraction Prompt Example: "Extract the product name, price, and description from these product pages." Usage Example:
{
"name": "firecrawl_extract",
"arguments": {
"urls": ["https://example.com/page1", "https://example.com/page2"],
"prompt": "Extract product information including name, price, and description",
"systemPrompt": "You are a helpful assistant that extracts product information",
"schema": {
"type": "object",
"properties": {
"name": { "type": "string" },
"price": { "type": "number" },
"description": { "type": "string" }
},
"required": ["name", "price"]
},
"allowExternalLinks": false,
"enableWebSearch": false,
"includeSubdomains": false
}
}Returns: Extracted structured data as defined by your schema.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | List of URLs to extract information from | |
| prompt | No | Prompt for the LLM extraction | |
| systemPrompt | No | System prompt for LLM extraction | |
| schema | No | JSON schema for structured data extraction | |
| allowExternalLinks | No | Allow extraction from external links | |
| enableWebSearch | No | Enable web search for additional context | |
| includeSubdomains | No | Include subdomains in extraction |
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.
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.
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.
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.
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.
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.
Generate a standardized llms.txt (and optionally llms-full.txt) file for a given domain. This file defines how large language models should interact with the site.
Best for: Creating machine-readable permission guidelines for AI models. Not recommended for: General content extraction or research. Arguments:
url (string, required): The base URL of the website to analyze.
maxUrls (number, optional): Max number of URLs to include (default: 10).
showFullText (boolean, optional): Whether to include llms-full.txt contents in the response. Prompt Example: "Generate an LLMs.txt file for example.com." Usage Example:
{
"name": "firecrawl_generate_llmstxt",
"arguments": {
"url": "https://example.com",
"maxUrls": 20,
"showFullText": true
}
}Returns: LLMs.txt file contents (and optionally llms-full.txt).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to generate LLMs.txt from | |
| maxUrls | No | Maximum number of URLs to process (1-100, default: 10) | |
| showFullText | No | Whether to show the full LLMs-full.txt in the response |
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.
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.
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.
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.
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.
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.
Map a website to discover all indexed URLs on the site.
Best for: Discovering URLs on a website before deciding what to scrape; finding specific sections of a website. Not recommended for: When you already know which specific URL you need (use scrape or batch_scrape); when you need the content of the pages (use scrape after mapping). Common mistakes: Using crawl to discover URLs instead of map. Prompt Example: "List all URLs on example.com." Usage Example:
{
"name": "firecrawl_map",
"arguments": {
"url": "https://example.com"
}
}Returns: Array of URLs found on the site.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Starting URL for URL discovery | |
| search | No | Optional search term to filter URLs | |
| ignoreSitemap | No | Skip sitemap.xml discovery and only use HTML links | |
| sitemapOnly | No | Only use sitemap.xml for discovery, ignore HTML links | |
| includeSubdomains | No | Include URLs from subdomains in results | |
| limit | No | Maximum number of URLs to return |
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.
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.
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.
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.
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.
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.
Scrape content from a single URL with advanced options.
Best for: Single page content extraction, when you know exactly which page contains the information. Not recommended for: Multiple pages (use batch_scrape), unknown page (use search), structured data (use extract). Common mistakes: Using scrape for a list of URLs (use batch_scrape instead). Prompt Example: "Get the content of the page at https://example.com." Usage Example:
{
"name": "firecrawl_scrape",
"arguments": {
"url": "https://example.com",
"formats": ["markdown"]
}
}Returns: Markdown, HTML, or other formats as specified.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to scrape | |
| formats | No | Content formats to extract (default: ['markdown']) | |
| onlyMainContent | No | Extract only the main content, filtering out navigation, footers, etc. | |
| includeTags | No | HTML tags to specifically include in extraction | |
| excludeTags | No | HTML tags to exclude from extraction | |
| waitFor | No | Time in milliseconds to wait for dynamic content to load | |
| timeout | No | Maximum time in milliseconds to wait for the page to load | |
| actions | No | List of actions to perform before scraping | |
| extract | No | Configuration for structured data extraction | |
| mobile | No | Use mobile viewport | |
| skipTlsVerification | No | Skip TLS certificate verification | |
| removeBase64Images | No | Remove base64 encoded images from output | |
| location | No | Location settings for scraping |
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.
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.
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.
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.
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.
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.
Search the web and optionally extract content from search results.
Best for: Finding specific information across multiple websites, when you don't know which website has the information; when you need the most relevant content for a query. Not recommended for: When you already know which website to scrape (use scrape); when you need comprehensive coverage of a single website (use map or crawl). Common mistakes: Using crawl or map for open-ended questions (use search instead). Prompt Example: "Find the latest research papers on AI published in 2023." Usage Example:
{
"name": "firecrawl_search",
"arguments": {
"query": "latest AI research papers 2023",
"limit": 5,
"lang": "en",
"country": "us",
"scrapeOptions": {
"formats": ["markdown"],
"onlyMainContent": true
}
}
}Returns: Array of search results (with optional scraped content).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query string | |
| limit | No | Maximum number of results to return (default: 5) | |
| lang | No | Language code for search results (default: en) | |
| country | No | Country code for search results (default: us) | |
| tbs | No | Time-based search filter | |
| filter | No | Search filter | |
| location | No | Location settings for search | |
| scrapeOptions | No | Options for scraping search results |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.9.0firecrawl_check_crawl_statusfirecrawl_crawlfirecrawl_deep_researchfirecrawl_extractfirecrawl_generate_llmstxtfirecrawl_mapfirecrawl_scrapefirecrawl_searchEach 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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Firecrawl MCP — wraps the Firecrawl API (firecrawl.dev) for web
40+ web scraping tools from Firecrawl, Bright Data, Jina, Olostep, ScrapeGraph, Notte, and Riveter. Scrape, crawl, screenshot, and extract from any website. Starts at $0.01/call. Get your API key at app.xpay.sh or xpay.tools
Turn any URL into clean Markdown and structured data. Scrape, crawl, search and extract.
Web search, browser automation, scraping, crawling and CAPTCHA solving for AI agents.
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