Firecrawl Agent MCP Server

Server Quality Checklist

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

Latest release: v1.0.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.
Average 3.8/5 across 5 of 5 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

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.
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 of behavioral disclosure. It mentions that the tool 'scrapes' results and returns 'scraped content from multiple search results,' which implies data extraction behavior. However, it lacks details on rate limits, authentication needs, error handling, or what 'scraping' entails (e.g., potential blocking, legal considerations). For a tool with no annotations, this is a significant gap in transparency.
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 two sentences, front-loaded with the core purpose and followed by usage guidance. Every sentence earns its place: the first defines the action and output, the second specifies the use case. There's zero waste or redundancy, making it appropriately sized and efficient.
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?
Given the tool's complexity (web search and scraping with 3 parameters), no annotations, and no output schema, the description is moderately complete. It covers the purpose and usage but lacks details on behavioral traits, return values, or error handling. The schema handles parameters well, but overall completeness is adequate with clear gaps for a tool of this nature.
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 clear details for all parameters (query, limit, formats). The description adds no parameter-specific information beyond what's in the schema. According to the rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description. The description doesn't compensate but doesn't need to, given the schema's completeness.
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: 'Search the web and scrape the results. Returns scraped content from multiple search results.' It specifies the verb ('search' and 'scrape') and resource ('web' and 'search results'), but doesn't explicitly differentiate from its sibling 'scrape' tool, which might have overlapping functionality. The description is specific but lacks sibling comparison.
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 usage context: 'Use this for finding and extracting data from multiple sources at once.' This indicates when to use the tool (for multi-source data extraction) but doesn't explicitly state when not to use it or name alternatives like the 'scrape' sibling tool. It offers implied guidance but no explicit exclusions.
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?
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.
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.
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.

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:

[![Firecrawler-MCP MCP server](https://glama.ai/mcp/servers/Replicant-Partners/Firecrawler-MCP/badges/card.svg)](https://glama.ai/mcp/servers/Replicant-Partners/Firecrawler-MCP)

Score Badge

Copy to your README.md:

[![Firecrawler-MCP MCP server](https://glama.ai/mcp/servers/Replicant-Partners/Firecrawler-MCP/badges/score.svg)](https://glama.ai/mcp/servers/Replicant-Partners/Firecrawler-MCP)

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

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