Firecrawl MCP Server

Server Quality Checklist

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

Latest release: v1.12.0
Disambiguation5/5
Each tool has a clearly distinct purpose with minimal overlap, and the descriptions explicitly guide users on when to use each tool versus alternatives. For example, scrape is for single pages, batch_scrape for multiple pages, crawl for comprehensive site coverage, and search for open-ended queries, with clear warnings against misuse.
Naming Consistency5/5
All tool names follow a consistent 'firecrawl_' prefix and snake_case pattern (e.g., firecrawl_scrape, firecrawl_extract). This uniformity makes the tool set predictable and easy to navigate, with no deviations in naming style.
Tool Count5/5
With 8 tools, the server is well-scoped for web content extraction and research, covering mapping, scraping, crawling, searching, extraction, and specialized tasks like deep research and llms.txt generation. Each tool serves a unique function without redundancy.
Completeness4/5
The tool set comprehensively covers the domain of web content extraction and research, including discovery (map, search), extraction (scrape, extract, crawl), analysis (deep_research), and utilities (generate_llmstxt, check_crawl_status). A minor gap is the lack of a batch_scrape tool mentioned in descriptions, but agents can work around this by calling scrape multiple times.
Average 4.2/5 across 8 of 8 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

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 states the tool checks status and returns progress and results, but lacks details on error handling, rate limits, authentication needs, or whether it's idempotent. For a status-checking tool with zero annotation coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose. The usage example and returns statement are relevant but could be more integrated. It avoids redundancy, but the structure is slightly fragmented, with the example in a code block and returns info separate, reducing efficiency.
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 low complexity (1 parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and return info, but lacks context on how it fits with siblings or error scenarios. Without annotations or output schema, it should provide more behavioral detail to be fully complete.
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, with the 'id' parameter documented as 'Crawl job ID to check.' The description adds no additional meaning beyond this, such as format examples or constraints. With high schema coverage, the baseline is 3, as the schema adequately handles parameter semantics without extra description.
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: 'Check the status of a crawl job.' It specifies the verb ('check') and resource ('crawl job'), making the action clear. However, it doesn't explicitly differentiate from siblings like 'firecrawl_crawl' or 'firecrawl_search', which might also involve crawl-related operations, so it doesn't reach a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions checking status but doesn't specify prerequisites (e.g., after initiating a crawl) or contrast with siblings like 'firecrawl_crawl' for starting a crawl. The usage example shows how to invoke it, but not when it's appropriate, leaving the agent to infer context.
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 explains what the tool generates (llms.txt files) and mentions optional llms-full.txt, but doesn't describe rate limits, authentication requirements, processing time, error conditions, or what happens when maxUrls is exceeded. It provides basic behavioral context but lacks operational details.
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 well-structured with clear sections (Best for, Not recommended for, Arguments, Prompt Example, Usage Example, Returns). While slightly longer than minimal, every section adds value and the information is front-loaded with the core purpose. The structure helps the agent quickly understand the tool's use.
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 (analyzing a domain to generate permission files), no annotations, and no output schema, the description provides good context about what the tool does, when to use it, parameters, and return values. It could be more complete by explaining the analysis process or output format details, but covers the essentials adequately.
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 lists the parameters with brief explanations but doesn't add significant semantic value beyond what's in the schema. The baseline of 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 specific action ('Generate a standardized llms.txt file') and resource ('for a given domain'), distinguishing it from siblings like 'crawl', 'extract', or 'scrape' by focusing on permission guideline creation rather than content extraction. It explicitly defines the purpose as creating machine-readable permission guidelines for AI models.
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 with 'Best for:' (creating machine-readable permission guidelines) and 'Not recommended for:' (general content extraction or research), clearly differentiating when to use this tool versus its siblings. This gives the agent clear context about appropriate use cases.
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 for behavioral disclosure. It explains the core extraction behavior and mentions support for cloud/self-hosted LLMs, but lacks details about rate limits, authentication requirements, error handling, or processing characteristics. The description doesn't contradict any annotations (none exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, best for/not for, arguments, examples). Every sentence serves a purpose, and the usage example provides concrete implementation guidance without unnecessary verbosity. The formatting with markdown and code blocks enhances readability.
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?
For a complex tool with 7 parameters, no annotations, and no output schema, the description does well by explaining the core functionality, providing usage guidelines, and showing a comprehensive example. However, it lacks information about return format details (beyond 'structured data as defined by your schema') and doesn't address potential limitations or error cases.
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. The description lists parameters but adds minimal semantic value beyond what's in the schema descriptions. The prompt example provides helpful context for the 'prompt' parameter, but overall the description doesn't significantly enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Extract structured information from web pages using LLM capabilities.' It specifies the verb ('extract'), resource ('structured information from web pages'), and distinguishes it from sibling tools by explicitly contrasting with 'scrape' for full content extraction.
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 with 'Best for:' and 'Not recommended for:' sections, naming specific use cases and alternatives. It clearly distinguishes when to use this tool versus the 'scrape' sibling tool, making selection straightforward.
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 full burden and does well by disclosing key behavioral traits: it's a time-intensive operation ('deep research can take time'), involves LLM analysis, and returns a final analysis plus structured activities and sources. It doesn't mention rate limits, authentication needs, or error conditions, but covers the core behavior adequately.
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 well-structured with clear sections (purpose, guidelines, arguments, examples) and front-loads the core purpose. While comprehensive, some redundancy exists (parameter details duplicated from schema). Every section serves a purpose, but it could be more concise by avoiding schema duplication.
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 4 parameters with 100% schema coverage but no annotations and no output schema, the description does well by explaining the tool's behavioral characteristics, usage context, and return values. It covers what the tool does, when to use it, and what it returns, though it could benefit from more detail on error conditions or limitations.
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 baseline is 3. The description repeats parameter information already in the schema (names, types, defaults) without adding significant semantic context beyond what's documented in the schema properties. The 'Arguments' section essentially duplicates schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('conduct deep web research', 'intelligent crawling, search, and LLM analysis') and distinguishes it from siblings by contrasting with 'scrape' for known pages and 'search' for simple questions. It explicitly names the resource (web research) and scope (complex questions requiring multiple sources).
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 with dedicated 'Best for' and 'Not recommended for' sections, naming specific alternatives like 'scrape' and 'search'. It clearly states when to use (complex research questions requiring multiple sources) and when not to use (simple questions, known pages, quick results), directly addressing sibling tool differentiation.
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 of behavioral disclosure. It effectively adds context beyond the input schema by mentioning performance aspects ('500% faster scrapes using cached data'), return formats ('Returns: Markdown, HTML, or other formats as specified'), and reliability claims ('most powerful, fastest and most reliable'). However, it lacks details on error handling, rate limits, or authentication needs, which would be beneficial for a tool with 14 parameters.
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 well-structured with clear sections (e.g., 'Best for,' 'Not recommended for,' 'Common mistakes,' 'Prompt Example,' 'Usage Example,' 'Performance,' 'Returns'), making it easy to scan. It is appropriately sized for a complex tool, though some sections like 'Prompt Example' and 'Usage Example' are slightly redundant, and the opening claim ('most powerful, fastest and most reliable') could be more concise.
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 complexity (14 parameters, nested objects, no output schema, no annotations), the description is largely complete. It covers purpose, usage guidelines, performance tips, and return formats, which compensates well for the lack of annotations and output schema. However, it could improve by detailing error cases or response structures, especially for a tool with advanced options like 'actions' and 'extract.'
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 14 parameters thoroughly. The description adds minimal parameter-specific information beyond the schema, such as a performance tip for 'maxAge' and a general note on return formats. This meets the baseline of 3, as the schema does the heavy lifting, but the description doesn't significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Scrape content from a single URL with advanced options,' specifying the verb (scrape) and resource (single URL content). It explicitly distinguishes from siblings like batch_scrape, search, and extract in the 'Best for' and 'Not recommended for' sections, making the differentiation clear and specific.
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 vs. alternatives: 'Best for: Single page content extraction... Not recommended for: Multiple pages (use batch_scrape), unknown page (use search), structured data (use extract).' It also includes a 'Common mistakes' section warning against misuse and naming specific sibling tools, offering clear when/when-not/alternatives.
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 of behavioral disclosure. It effectively describes the tool's capabilities (searching and optional extraction), power level ('most powerful search tool'), and return format ('Array of search results'). However, it doesn't mention rate limits, authentication needs, or potential costs, leaving some behavioral aspects unspecified.
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 well-structured with clear sections (Best for, Not recommended for, Common mistakes, examples) and front-loads the core purpose. While comprehensive, some sections could be more concise, and the usage example is quite detailed, making it slightly longer than ideal.
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?
For a complex tool with 8 parameters, nested objects, and no output schema, the description provides good context about usage scenarios and alternatives. However, it doesn't fully describe the return value structure beyond 'Array of search results', which could be more detailed given the lack of output schema.
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 minimal parameter semantics beyond the schema, mainly through the usage example showing typical values. It doesn't explain parameter interactions or provide additional context beyond what's in the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('search the web', 'extract content') and resource ('search results'). It explicitly distinguishes this tool from sibling tools like scrape, map, and crawl by stating when to use each, making the purpose distinct and well-defined.
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 with 'Best for' and 'Not recommended for' sections, naming specific sibling tools (scrape, map, crawl) as alternatives. It includes a 'Common mistakes' section and states 'you should always default to using this tool for any web search needs', giving clear when-to-use rules.
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 full burden and does well by explaining what the tool returns ('Array of URLs'), its discovery methods (indexed URLs, with options for sitemap vs HTML links implied), and constraints (maximum via 'limit' parameter). It doesn't mention rate limits, authentication needs, or error behaviors, but provides substantial operational 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 well-structured with clear sections (purpose, best for, not recommended, common mistakes, examples) and every sentence earns its place. It's front-loaded with the core purpose and uses efficient formatting without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no annotations, and no output schema, the description provides good context: purpose, usage guidelines, examples, and return format. It could be more complete by explaining potential limitations (e.g., depth of discovery, timeouts) or error cases, but covers the essential operational context adequately.
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 baseline is 3. The description doesn't add parameter-specific semantics beyond what's in the schema (e.g., it mentions 'search term to filter URLs' but the schema already describes this). The 'Prompt Example' and 'Usage Example' illustrate parameter usage but don't provide additional semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('map a website', 'discover all indexed URLs') and distinguishes it from siblings by explicitly contrasting with 'scrape', 'batch_scrape', and 'crawl'. It identifies the resource (URLs on a site) and scope (all indexed URLs).
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 with dedicated sections: 'Best for' (discovering URLs before scraping, finding sections), 'Not recommended for' (when specific URL known, when content needed), and 'Common mistakes' (using crawl instead). It names alternatives (scrape, batch_scrape) and clearly defines when to use/avoid this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and excels at disclosing behavioral traits. It explicitly warns about crawl responses being 'very large and may exceed token limits', mentions that 'crawling can be slow', explains the asynchronous nature ('starts an asynchronous crawl job'), and clarifies that results require checking status with another tool. This provides crucial behavioral context beyond what parameters alone would indicate.
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 structured and front-loaded: the core purpose comes first, followed by clearly labeled sections (Best for, Not recommended for, Warning, etc.), examples, and return information. Every sentence earns its place by providing distinct guidance or clarification. The formatting with bold headers and code blocks enhances readability without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 12 parameters, no annotations, and no output schema, the description provides exceptional completeness. It covers purpose, usage guidelines, behavioral warnings, common mistakes, practical examples, and clarifies the asynchronous workflow (returns operation ID, need to check status). The only minor gap is not explicitly describing the output format, but given the asynchronous nature and status-checking workflow, this is reasonable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 92% schema description coverage, the baseline would be 3, but the description adds significant value through the usage example that shows typical parameter combinations and the prompt example that contextualizes how parameters like maxDepth and limit work together. While it doesn't explain individual parameters beyond what the schema provides, it gives practical semantic context about how to use them effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Starts an asynchronous crawl job on a website and extracts content from all pages.' This is specific (verb: starts crawl, resource: website pages) and distinguishes it from siblings like 'scrape' for single pages. The title line alone provides complete clarity about what the tool does.
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 excellent usage guidance with explicit sections: 'Best for:' (multi-page comprehensive coverage), 'Not recommended for:' (single page, token limits, speed concerns), and 'Common mistakes:' (limit/depth too high, using for single page). It names specific alternatives like 'scrape' and 'map + batch_scrape', making it very clear when to use this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

[![firecrawl-mcp MCP server](https://glama.ai/mcp/servers/ashishdevthakur3-max/firecrawl-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ashishdevthakur3-max/firecrawl-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/ashishdevthakur3-max/firecrawl-mcp'

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