Firecrawl 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 minimal overlap. The descriptions explicitly differentiate use cases (e.g., scrape vs. batch_scrape vs. extract, crawl vs. map vs. search) and provide guidance on when to use each tool. An agent can easily distinguish between them based on their specific functions.
Naming Consistency5/5
All tool names follow a consistent 'firecrawl_' prefix with snake_case naming (e.g., firecrawl_scrape, firecrawl_extract). The verb-noun pattern is uniform throughout, making the tool set predictable and easy to understand at a glance.
Tool Count5/5
With 8 tools, the server is well-scoped for web content extraction and research. Each tool serves a specific role (e.g., mapping, crawling, scraping, extracting, searching), and none feel redundant or unnecessary. The count aligns well with the domain's complexity.
Completeness5/5
The tool set comprehensively covers the web content extraction and research domain. It includes discovery (map, search), extraction (scrape, extract, crawl), analysis (deep_research, generate_llmstxt), and status checking (check_crawl_status). There are no obvious gaps, and the tools support a full workflow from URL discovery to structured data extraction.
Average 4.3/5 across 8 of 8 tools scored. Lowest: 3.3/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. It mentions that the tool returns 'Status and progress of the crawl job, including results if available,' which gives some behavioral insight (e.g., it's a read operation that may include results). However, it doesn't disclose critical details like whether it's idempotent, potential error conditions, rate limits, or authentication needs, leaving significant gaps for a tool with no annotation coverage.
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 front-loaded with a clear purpose statement, followed by a usage example and return information. Every sentence earns its place by providing essential context without redundancy, making it appropriately sized and well-structured for quick understanding.
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 somewhat complete but has gaps. It covers the basic purpose and usage but lacks details on behavioral aspects like error handling or output structure. Without annotations or an output schema, more context on what 'status and progress' entails would improve completeness, but it's minimally viable for this simple tool.
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 doesn't add any extra meaning beyond this, such as format details or examples of valid IDs. With high schema coverage, the baseline is 3, as the schema adequately handles parameter semantics without additional description input.
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 as 'Check the status of a crawl job,' which is a specific verb (check) and resource (crawl job). It distinguishes from siblings like firecrawl_crawl (which initiates crawls) and firecrawl_scrape (which extracts data), but doesn't explicitly contrast them in the description itself, keeping it at a 4 rather than 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by providing an example with a crawl job ID, suggesting it's used after initiating a crawl (e.g., with firecrawl_crawl). However, it lacks explicit guidance on when to use this tool versus alternatives or any prerequisites, such as needing an existing job ID from a previous operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions what the tool generates (llms.txt files) and includes a usage example, but lacks details on behavioral traits like rate limits, authentication needs, error handling, or how it analyzes the domain. The description adds some context but is incomplete for a tool with no annotation coverage.
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 sections like 'Best for:', 'Arguments:', and usage examples, making it easy to scan. It's appropriately sized but includes a prompt example that could be considered slightly redundant, though it adds practical value. Most sentences earn their place.
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 (3 parameters, no output schema, no annotations), the description is fairly complete. It covers purpose, usage guidelines, parameters, and return values ('Returns: LLMs.txt file contents'), but lacks details on behavioral aspects like processing time or error cases, which would be helpful for full completeness.
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 arguments with brief notes (e.g., 'default: 10' for maxUrls), but adds minimal semantic value beyond what's in the schema. 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 tool's purpose: 'Generate a standardized llms.txt (and optionally llms-full.txt) file for a given domain.' It specifies the verb ('generate'), resource ('llms.txt file'), and scope ('for a given domain'), distinguishing it from sibling tools like 'extract' or 'scrape' that handle general 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 explicitly provides usage guidance with 'Best for:' (creating machine-readable permission guidelines for AI models) and 'Not recommended for:' (general content extraction or research), clearly differentiating when to use this tool versus alternatives like 'firecrawl_extract' or 'firecrawl_scrape'.
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 discloses important behavioral traits: it mentions the tool 'can take time' (performance characteristic), describes the output ('Final analysis generated by an LLM', 'may also include structured activities and sources'), and implies resource-intensive operations through parameter explanations. It doesn't mention rate limits or authentication needs, but provides substantial context beyond basic functionality.
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, examples) and front-loads the core purpose. While comprehensive, some sections like the detailed usage example could be more concise. Most sentences earn their place by providing distinct value.
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 (deep research with crawling/search/LLM analysis), no annotations, and no output schema, the description does well by explaining the return format, providing usage guidelines, and detailing parameters. It could benefit from more explicit behavioral constraints (e.g., rate limits, error conditions) but is largely complete for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by providing default values for optional parameters (maxDepth: 3, timeLimit: 120, maxUrls: 50) and contextualizes parameters in the research process, but doesn't significantly expand on the schema's parameter descriptions beyond these defaults.
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 mentioning when not to use it (e.g., 'when you need very specific information from a known page (use scrape)'). It explicitly names the resource (web research) and differentiates from simpler 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 with dedicated sections: 'Best for:' lists complex research questions requiring multiple sources and in-depth analysis, 'Not recommended for:' specifies three clear scenarios including alternatives (e.g., 'use scrape'), and distinguishes from sibling tools like 'scrape' and 'search'. This gives comprehensive when/when-not/alternatives information.
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 performance characteristics ('most powerful, fastest and most reliable scraper tool'), caching behavior ('Add maxAge parameter for 500% faster scrapes using cached data'), and return formats ('Returns: Markdown, HTML, or other formats as specified'). However, it lacks details on error handling, rate limits, or authentication needs, which are important for a complex 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 (Best for, Not recommended for, Common mistakes, Prompt Example, Usage Example, Performance, Returns), making it easy to scan. However, it includes some redundancy (e.g., repeating performance claims) and could be more concise by integrating related points, though all content is relevant.
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, no annotations, no output schema), the description does a good job of covering key aspects like purpose, usage guidelines, and behavioral traits. It falls short in fully explaining the output structure or error scenarios, but the high schema coverage and detailed usage examples compensate adequately 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, so the schema already documents all 14 parameters thoroughly. The description adds minimal parameter-specific information beyond the schema, such as emphasizing the maxAge parameter for performance and providing a usage example with formats and maxAge. 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 tool's purpose as 'Scrape content from a single URL with advanced options,' specifying both the verb (scrape) and resource (content from a URL). It explicitly distinguishes this from sibling tools like batch_scrape, search, and extract, making it easy to understand its unique role.
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 ('Best for: Single page content extraction, when you know exactly which page contains the information') and when not to use it ('Not recommended for: Multiple pages (use batch_scrape), unknown page (use search), structured data (use extract)'). It also names alternatives and includes a prompt example, offering comprehensive usage instructions.
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 describes the core behavior (LLM-based extraction) and mentions support for both cloud and self-hosted LLMs, but doesn't disclose important behavioral traits like rate limits, authentication requirements, error handling, or what happens when extraction fails. The description adds some context but leaves significant gaps.
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 (Best for, Not recommended for, Arguments, Prompt Example, Usage Example, Returns). Every sentence serves a purpose - no redundant information. The usage example is comprehensive but necessary for understanding this complex tool.
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 providing clear purpose, usage guidelines, parameter examples, and return value information. However, it lacks details about error cases, rate limits, and authentication requirements that would be helpful for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by providing a detailed usage example with all parameters shown in context, plus a prompt example that illustrates how the 'prompt' parameter should be structured. This gives practical guidance beyond the schema's basic 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 as 'Extract structured information from web pages using LLM capabilities' with specific examples like 'prices, names, details'. It explicitly distinguishes from sibling tools by stating 'Not recommended for: When you need the full content of a page (use scrape)', directly naming the alternative.
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, clearly stating when to use this tool (extracting specific structured data) versus when to use the 'scrape' sibling tool (when needing full page content). This gives clear context for tool selection.
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 behavior: it discovers URLs, returns an array of URLs, and implies it's a read-only operation (no mention of modification or side effects). However, it doesn't detail potential limitations like rate limits, authentication needs, or error handling, which keeps it from a perfect score.
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 and front-loaded with a clear purpose statement, followed by organized sections (Best for, Not recommended for, etc.). Each sentence adds value, such as usage examples and return information, with no wasted words, making it efficient and easy to parse.
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 (6 parameters, no output schema, no annotations), the description is largely complete: it explains the purpose, usage, returns, and provides examples. However, it lacks details on output format beyond 'Array of URLs' (e.g., structure or pagination) and doesn't cover error cases, which slightly reduces completeness for a tool with multiple parameters.
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 doesn't add any parameter-specific information beyond what's in the schema (e.g., it mentions 'url' in the usage example but doesn't explain parameters like 'search' or 'limit'). This meets the baseline of 3 for high schema coverage without extra value.
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: 'Map a website to discover all indexed URLs on the site.' It specifies the verb ('map'), resource ('website'), and outcome ('discover all indexed URLs'), and distinguishes it from siblings like scrape, crawl, and batch_scrape by emphasizing URL discovery rather than content extraction or crawling.
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 alternatives (scrape, batch_scrape) and clarifying when not to use it (e.g., when you already know the URL or need content). It also warns against common mistakes like using crawl instead of map, offering clear when/when-not/alternatives context.
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. It describes the tool as 'most powerful' and suggests default preference. It explains the optional extraction capability and provides usage examples. However, it doesn't mention rate limits, authentication needs, or error behaviors that might be important for a web search tool.
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 (Best for, Not recommended for, Common mistakes, examples) and every sentence adds value. It's appropriately sized for a complex tool with 8 parameters and multiple sibling alternatives. The information is front-loaded with the core purpose first.
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, no annotations, and no output schema, the description does quite well. It covers purpose, usage guidelines, and provides examples. However, without an output schema, it could better describe the return format ('Array of search results' is minimal). Behavioral aspects like rate limits or error handling aren't addressed.
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 adds some value through the usage example showing parameter combinations, but doesn't provide additional semantic context beyond what's in the schema descriptions. The example helps illustrate how parameters work together but doesn't explain them beyond 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 tool's purpose: 'Search the web and optionally extract content from search results.' It distinguishes from siblings by explicitly mentioning alternatives like scrape, map, and crawl. The verb 'search' and resource 'web' are specific, and sibling differentiation is explicit.
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 dedicated sections: 'Best for' (when to use), 'Not recommended for' (when not to use with specific alternatives), and 'Common mistakes' (clarifying tool selection). It explicitly names sibling tools (scrape, map, crawl) as alternatives for different scenarios.
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 full burden and delivers rich behavioral context. It discloses that the operation is asynchronous, returns an operation ID for status checking, warns about large responses potentially exceeding token limits, mentions crawling can be slow, and advises on parameter limits to avoid token overflow. It also explains the need to use a separate tool (firecrawl_check_crawl_status) to check progress.
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 (Best for, Not recommended for, Warning, Common mistakes, Prompt Example, Usage Example, Returns). Every sentence earns its place by providing essential guidance, warnings, or examples. It's appropriately sized for a complex tool with many parameters and behavioral considerations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, no annotations, no output schema), the description provides comprehensive context. It explains the asynchronous nature, return value (operation ID), how to check status, performance considerations, token limit warnings, when to use alternatives, and includes practical examples. This adequately compensates for the lack of structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (92%), so the baseline is 3. The description adds value beyond the schema by providing a usage example with specific parameters (url, maxDepth, limit, allowExternalLinks, deduplicateSimilarURLs) and contextual advice about limiting maxDepth and limit to avoid token overflow. However, it doesn't explain all 12 parameters' semantics in detail.
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.' It specifies the verb ('starts an asynchronous crawl job'), resource ('website'), and scope ('extracts content from all pages'). It distinguishes from siblings by explicitly mentioning when to use scrape instead for single pages.
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:' (comprehensive coverage of multiple related pages), 'Not recommended for:' (single pages, token limits, fast results), and 'Common mistakes:' (setting limits too high, using crawl for single pages). It names alternatives like 'scrape', 'map + batch_scrape', and 'firecrawl_check_crawl_status' for status checking.
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/ampcome-mcps/firecrawl-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ampcome-mcps/firecrawl-mcp)

Score Badge

Copy to your README.md:

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

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