Skip to main content
Glama
Replicant-Partners

Firecrawl Agent MCP Server

by Replicant-Partners
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

Firecrawl Agent MCP Server

A Model Context Protocol (MCP) server that provides AI-powered web data extraction and research capabilities through Firecrawl's Agent API.

Features

šŸ¤– AI Agent Mode: Let the agent autonomously search, navigate, and gather data from complex websites šŸ” Web Search: Search and scrape multiple results at once šŸ“„ Single Page Scraping: Extract content from specific URLs šŸ“Š Structured Data: Define JSON schemas for type-safe data extraction šŸ’° Cost Control: Set maximum credit limits per request āš” Async Jobs: Start long-running tasks and poll for results

What is Firecrawl Agent?

Firecrawl Agent is a magic API that:

  • No URLs Required: Just describe what you need via prompt

  • Autonomous Navigation: Searches and navigates deep into sites to find your data

  • Parallel Processing: Processes multiple sources simultaneously for faster results

  • Structured Output: Returns data in your specified JSON schema format

Perfect for:

  • Research tasks across multiple websites

  • Extracting structured data (company info, pricing, contacts)

  • Finding hard-to-reach information

  • Competitive analysis and market research

Installation

1. Clone or Copy Files

cd firecrawl-agent-mcp

2. Install Dependencies

npm install

3. Configure API Key

Copy the example environment file and add your Firecrawl API key:

cp .env.example .env

Edit .env and add your API key:

FIRECRAWL_API_KEY=fc-YOUR_API_KEY_HERE

Get your API key from: https://www.firecrawl.dev/

4. Build the Server

npm run build

Configuration in Claude Code

Add the Firecrawl Agent MCP server to your Claude Code configuration:

Option 1: Edit .claude/settings.json

{
  "mcpServers": {
    "firecrawl-agent": {
      "command": "node",
      "args": ["/absolute/path/to/firecrawl-agent-mcp/dist/server.js"],
      "env": {
        "FIRECRAWL_API_KEY": "fc-YOUR_API_KEY_HERE"
      }
    }
  }
}

Option 2: Use .mcp.json in Project Root

{
  "mcpServers": {
    "firecrawl-agent": {
      "command": "node",
      "args": ["./firecrawl-agent-mcp/dist/server.js"],
      "env": {
        "FIRECRAWL_API_KEY": "fc-YOUR_API_KEY_HERE"
      }
    }
  }
}

Available Tools

agent_execute

Execute the AI agent synchronously (waits for completion).

Use when: You need immediate results for research tasks.

Parameters:

  • prompt (required): Describe what data you want to extract

  • urls (optional): Specific URLs to search (otherwise searches web)

  • schema (optional): JSON schema for structured output

  • maxCredits (optional): Maximum credits to spend

Example:

{
  "prompt": "Find the founders and founding year of Anthropic",
  "schema": {
    "type": "object",
    "properties": {
      "founders": { "type": "array", "items": { "type": "string" } },
      "founded": { "type": "number" }
    }
  }
}

agent_start

Start an agent job asynchronously (returns job ID immediately).

Use when: You have long-running research tasks and want to poll for results.

Parameters: Same as agent_execute

Returns: Job ID to use with agent_status

agent_status

Check the status of an asynchronous agent job.

Parameters:

  • jobId (required): Job ID from agent_start

Returns: Current status, progress, and results if completed

scrape

Scrape a single URL without AI agent capabilities.

Use when: You just need to extract content from one specific page.

Parameters:

  • url (required): URL to scrape

  • formats (optional): Output formats (markdown, html, rawHtml, links, screenshot)

  • onlyMainContent (optional): Extract only main content (default: true)

  • includeTags (optional): HTML tags to include

  • excludeTags (optional): HTML tags to exclude

  • waitFor (optional): Wait time for JS rendering (ms)

  • timeout (optional): Request timeout (ms)

search

Search the web and scrape multiple results.

Use when: You want to find and extract data from multiple sources at once.

Parameters:

  • query (required): Search query

  • limit (optional): Maximum number of results (default: 5)

  • formats (optional): Output formats for each result

Usage Examples

Example 1: Research Company Information

// Ask Claude Code:
"Use Firecrawl Agent to find information about Anthropic's founding team"

// Claude will call:
agent_execute({
  prompt: "Find the founders of Anthropic and when the company was founded",
  schema: {
    type: "object",
    properties: {
      founders: {
        type: "array",
        items: { type: "string" }
      },
      founded: { type: "number" },
      description: { type: "string" }
    }
  }
})

Example 2: Extract Pricing Information

// Ask Claude Code:
"Get pricing information for Claude API"

// Claude will call:
agent_execute({
  prompt: "Extract all pricing tiers and costs for Claude API",
  urls: ["https://www.anthropic.com/pricing"]
})

Example 3: Competitive Analysis

// Ask Claude Code:
"Compare the features of the top 5 AI coding assistants"

// Claude will call:
agent_execute({
  prompt: "Find and compare features of top AI coding assistants: GitHub Copilot, Cursor, Claude Code, Tabnine, and Codeium",
  schema: {
    type: "object",
    properties: {
      tools: {
        type: "array",
        items: {
          type: "object",
          properties: {
            name: { type: "string" },
            features: { type: "array", items: { type: "string" } },
            pricing: { type: "string" }
          }
        }
      }
    }
  }
})

Example 4: Long-Running Research

// Ask Claude Code:
"Start a deep research job on quantum computing breakthroughs in 2024"

// Claude will call:
const job = await agent_start({
  prompt: "Research all major quantum computing breakthroughs and papers published in 2024"
})

// Then poll for status:
const status = await agent_status({ jobId: job.jobId })

Cost Management

Firecrawl Agent uses dynamic billing based on task complexity:

  • Simple extractions: Fewer credits

  • Complex research: More credits

Control costs using:

{
  prompt: "Your task",
  maxCredits: 100  // Limit spending to 100 credits
}

Development

Watch Mode

npm run dev

Run Directly

npm start

SSE Transport Mode

For HTTP-based communication:

npm run start:sse

Troubleshooting

"FIRECRAWL_API_KEY environment variable is required"

Make sure you've:

  1. Created a .env file with your API key

  2. Or configured the env variable in your Claude Code settings

"HTTP 401: Unauthorized"

Your API key is invalid. Get a new one from https://www.firecrawl.dev/

"HTTP 429: Too Many Requests"

You've hit rate limits. Wait a moment and try again, or upgrade your Firecrawl plan.

Tools not showing up in Claude Code

  1. Make sure you've built the server: npm run build

  2. Check that the path in your MCP configuration is correct

  3. Restart Claude Code after configuration changes

Learn More

License

MIT

Support

For issues with:

Built with ā¤ļø using the Model Context Protocol

Available Tools

5 tools
agent_executeB

Execute Firecrawl Agent to search, navigate, and gather data from the web. The agent autonomously finds and extracts information based on your prompt. Waits for completion and returns results. Use this for immediate results.

ParametersJSON Schema
NameRequiredDescriptionDefault
promptYesDescribe what data you want to extract. Be specific about what information you need. Examples: "Find the founders of Anthropic", "Get pricing information for Claude API", "Extract contact emails from YCombinator companies"
urlsNoOptional: Specific URLs to search. If not provided, agent will search the web.
schemaNoOptional: JSON schema for structured output. Define the exact structure you want the data returned in.
maxCreditsNoOptional: Maximum credits to spend on this request. Use to control costs.

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It mentions the agent 'waits for completion and returns results', which implies synchronous behavior, and hints at cost control via 'maxCredits'. However, it lacks details on error handling, rate limits, authentication needs, timeouts, or what specific data formats are returned. For a complex web scraping/agent tool with no annotations, this is insufficient.

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 concise (3 sentences) and front-loaded with the core purpose. Each sentence adds value: first defines the tool, second explains behavior, third gives usage tip. However, the last sentence 'Use this for immediate results' could be more integrated with the context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (autonomous web agent with 4 parameters), no annotations, and no output schema, the description is incomplete. It doesn't explain the return format, error cases, or operational constraints. The schema covers inputs well, but the description fails to compensate for missing behavioral and output context.

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 the schema already documents all 4 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain 'prompt' usage further or provide examples for 'schema' or 'maxCredits'). With high schema coverage, the baseline is 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Execute Firecrawl Agent to search, navigate, and gather data from the web. The agent autonomously finds and extracts information based on your prompt.' This specifies the verb (execute/search/navigate/gather) and resource (web data). However, it doesn't explicitly differentiate from sibling tools like 'scrape' or 'search' beyond mentioning 'autonomously' and 'agent'.

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?

The description provides some usage context: 'Use this for immediate results' and mentions the agent will search the web if URLs aren't provided. However, it doesn't explicitly state when to use this tool versus alternatives like 'agent_start' (which might be for async execution), 'scrape', or 'search'. The guidance is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

agent_startA

Start a Firecrawl Agent job asynchronously. Returns a job ID immediately without waiting for completion. Use this for long-running research tasks. Poll with agent_status to check progress.

ParametersJSON Schema
NameRequiredDescriptionDefault
promptYesDescribe what data you want to extract. Be specific about what information you need.
urlsNoOptional: Specific URLs to search. If not provided, agent will search the web.
schemaNoOptional: JSON schema for structured output. Define the exact structure you want the data returned in.
maxCreditsNoOptional: Maximum credits to spend on this request. Use to control costs.

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: asynchronous execution ('Returns a job ID immediately without waiting for completion'), long-running nature, and the need for polling. However, it doesn't mention potential costs, rate limits, error handling, or what happens if maxCredits is exceeded. For a tool with no annotations, this is good but not exhaustive.

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?

Three sentences, zero waste. First sentence states the core action and immediate return. Second provides usage context. Third gives essential follow-up instruction. Every sentence earns its place, and the structure is front-loaded with the most critical 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 the complexity (asynchronous job execution with 4 parameters, no output schema, and no annotations), the description is mostly complete. It covers the asynchronous behavior, polling requirement, and high-level use case. However, it lacks details on error responses, job lifecycle, or output format expectations. With no output schema, some guidance on what 'agent_status' returns would help, but the description is sufficient for basic use.

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 the schema already documents all parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain prompt formatting best practices or credit costs). Baseline 3 is appropriate when the schema does the heavy lifting.

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 verb ('Start'), resource ('Firecrawl Agent job'), and key behavioral trait ('asynchronously'). It distinguishes from sibling tools by mentioning 'Poll with agent_status to check progress' and contrasts with 'agent_execute' by emphasizing the asynchronous nature. The purpose is specific and unambiguous.

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 provided: 'Use this for long-running research tasks' tells when to use it, and 'Poll with agent_status to check progress' names the alternative for checking status. It implicitly contrasts with 'agent_execute' (likely synchronous) and 'scrape'/'search' (different functionalities). The guidelines are comprehensive and actionable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

agent_statusA

Check the status of an asynchronous Firecrawl Agent job. Returns current status, progress, and results if completed. Job results are available for 24 hours after completion.

ParametersJSON Schema
NameRequiredDescriptionDefault
jobIdYesThe job ID returned from agent_start

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It discloses key behavioral traits: the tool returns status/progress/results, results are temporary (24-hour retention), and it works with asynchronous jobs. However, it doesn't mention error handling, rate limits, authentication requirements, or what happens after 24 hours. The description adds value but lacks comprehensive behavioral context.

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 perfectly concise with two sentences that each earn their place: the first states the purpose and return values, the second provides critical behavioral context about result retention. No wasted words, and information is front-loaded appropriately.

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 the tool's moderate complexity (status checking with temporal constraints), no annotations, and no output schema, the description does well but has gaps. It explains what the tool does, when to use it, and key behavioral constraints. However, without an output schema, it doesn't detail the structure of returned status/progress/results, leaving some uncertainty about the response format.

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%, with the single parameter 'jobId' well-documented in the schema. The description adds minimal value beyond the schema by mentioning 'job ID returned from agent_start,' which provides context but no additional semantic meaning. This meets the baseline of 3 when schema coverage is high.

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 specific action ('Check the status'), target resource ('asynchronous Firecrawl Agent job'), and scope ('current status, progress, and results if completed'). It distinguishes from siblings like agent_start (which initiates jobs) and agent_execute (likely executes synchronously) by focusing on status monitoring of existing jobs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool: after starting an asynchronous job with agent_start, to monitor its progress and retrieve results. It implies an alternative (waiting for completion) but doesn't explicitly name when NOT to use it or compare with other status-checking methods. The 24-hour retention period provides useful temporal guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

scrapeA

Scrape a single URL and extract content in various formats (markdown, html, links, screenshot). Use this for simple single-page scraping without AI agent capabilities.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesThe URL to scrape
formatsNoOutput formats to return. Default: ["markdown"]. Can request multiple formats.
onlyMainContentNoExtract only main content, removing headers, footers, nav, etc. Default: true
includeTagsNoHTML tags to include (e.g., ["article", "main"])
excludeTagsNoHTML tags to exclude (e.g., ["nav", "footer"])
waitForNoMilliseconds to wait before scraping (for JS rendering)
timeoutNoRequest timeout in milliseconds

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool's limitation ('without AI agent capabilities') and scope ('simple single-page scraping'), which adds useful context. However, it doesn't disclose important behavioral traits like rate limits, authentication requirements, error handling, or what happens with invalid URLs, leaving gaps for a mutation-like 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?

The description is perfectly concise with two sentences that each earn their place. The first sentence states the core functionality, and the second provides crucial usage guidance. There's zero waste or redundancy, making it highly efficient and front-loaded.

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 tool with 7 parameters, no annotations, and no output schema, the description provides good purpose and usage guidance but lacks behavioral details about what the tool returns, error conditions, or operational constraints. Given the complexity and absence of structured metadata, it should do more to explain the tool's behavior and output expectations.

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?

The input schema has 100% description coverage, providing detailed documentation for all 7 parameters. The description adds no additional parameter semantics beyond what's already in the schema, so it meets the baseline of 3. It doesn't compensate for any gaps since there are none in the schema coverage.

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 specific action ('scrape a single URL') and resource ('extract content in various formats'), distinguishing it from sibling tools like agent_execute or search. It explicitly mentions the scope ('simple single-page scraping without AI agent capabilities'), which helps differentiate it from more complex 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?

The description provides explicit guidance on when to use this tool ('for simple single-page scraping') and when not to use it ('without AI agent capabilities'), clearly positioning it against more advanced alternatives. This helps the agent choose between this tool and sibling tools like agent_execute for different scraping needs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose with no ambiguity: agent_execute for immediate agent tasks, agent_start for async jobs, agent_status for job monitoring, scrape for single URLs, and search for web searches. The descriptions explicitly differentiate use cases, preventing misselection.

Naming Consistency5/5

All tool names follow a consistent snake_case pattern with clear verb_noun or noun_verb structures (e.g., agent_execute, agent_start, scrape, search). There are no deviations in naming conventions, making the set predictable and readable.

Tool Count5/5

With 5 tools, the server is well-scoped for web data extraction and agent tasks. Each tool earns its place by covering distinct aspects: synchronous and asynchronous agent execution, job monitoring, single-page scraping, and multi-source search. This count is neither too sparse nor bloated.

Completeness4/5

The tool surface covers core workflows for web scraping and agent-based data gathering, including start, execute, status, scrape, and search operations. A minor gap exists in lacking explicit tools for managing or canceling async jobs, but agents can work around this by using the provided tools effectively.

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Latest Blog Posts

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/Replicant-Partners/Firecrawler-MCP'

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