mcp-firecrawl-licensed

Server Quality Checklist

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

Latest release: v0.1.0-alpha.1
Disambiguation5/5
Each tool has a clearly distinct purpose: agent management, crawl management, scraping, searching, mapping, extraction. No overlapping functionality.
Naming Consistency5/5
All tools follow the consistent pattern firecrawl_<action> (or firecrawl_<action>_<sub>), using snake_case throughout.
Tool Count5/5
8 tools is well-scoped for a web scraping/crawling API, covering agent, crawl, scrape, search, map, and extract operations without excess.
Completeness4/5
Covers all core workflows (agent start/status, crawl start/status, scrape, search, map, extract), though missing operations like stop/delete agent.
Average 2.4/5 across 8 of 8 tools scored. Lowest: 1.6/5.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'Run an autonomous Firecrawl agent job' without mentioning whether it is synchronous or asynchronous, side effects, authentication needs, or output behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is short but not sufficiently informative. It under-specifies the tool, making it inadequate for an AI agent to understand usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/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 agent with 3 parameters and no output schema), the description is extremely incomplete. It fails to explain what an agent job does, how to use parameters, or what the result looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the parameter names and types are the only information. The description adds no meaning to 'urls', 'prompt', or 'schema', leaving their purpose and format unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool runs an autonomous Firecrawl agent job, which is a specific verb and resource. However, it is vague about what an autonomous agent job entails and does not distinguish it from sibling tools like 'firecrawl_crawl' or 'firecrawl_extract'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The sibling tools include more specific operations, but the description offers no criteria for choosing this agent over them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'Start a crawl job' without disclosing whether the operation is asynchronous, what happens upon completion, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short but under-informative. It lacks key details, making it insufficient for an agent to use the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and a complex set of sibling tools, the description is severely incomplete. An agent cannot determine expected behavior, return values, or prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only 'options' has a generic description). The description adds no meaning beyond the schema; it does not mention parameters or clarify the 'options' object structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Start a crawl job.' is a verb+resource but lacks specificity about what a crawl job entails and does not distinguish from sibling tools like firecrawl_scrape or firecrawl_map.
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?
No guidance on when to use this tool versus alternatives such as firecrawl_scrape (single page) or firecrawl_search. The description provides no context for appropriate usage.
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?
With no annotations, the description must disclose behavioral traits. It implies a read operation but does not explicitly state it is read-only, nor does it mention side effects, authentication needs, or rate limits. The phrase 'log usage' suggests a possible mutation, but this is unclear.
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 a single concise sentence that front-loads the core action. However, it may be too brief given the tool's complexity, but conciseness itself is well-executed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is severely incomplete for a tool with 11 parameters, no output schema, and no annotations. It lacks explanation of return values, parameter usage, or operational context, making it hard for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the input schema. Schema description coverage is only 9%, and the description does not explain any of the 11 parameters (e.g., id, skip, fetch, stage, etc.). This fails to compensate for low schema coverage.
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 checks crawl status and logs usage for completed pages, using a specific verb and resource. It distinguishes from siblings like firecrawl_crawl (initiates crawl) adequately, though 'log usage' is somewhat vague.
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?
No guidance provided on when to use this tool versus alternatives (e.g., firecrawl_agent_status, firecrawl_crawl). The description does not mention any preconditions or exclusions.
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, and the description does not disclose behavioral traits such as side effects, rate limits, or return format. The description is too brief to cover safety or behavioral 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 a single sentence with no wasted words, achieving efficiency. However, it might be too terse given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has nested parameters and 8 siblings, the description is severely inadequate. It provides no output information, no example usage, and no context on how 'map' differs from similar operations like crawl.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters: 'url' (required string) and 'options' (object described as 'Firecrawl map options'). The description adds no additional meaning; the options object lacks internal property details. With 50% schema description coverage, the description does not compensate for missing info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Map a website to discover URLs,' which gives a verb and resource but is vague. It does not distinguish from sibling tools like firecrawl_crawl or firecrawl_scrape, so purpose is somewhat clear but not differentiated.
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?
No guidance on when to use this tool versus alternatives like firecrawl_crawl or firecrawl_search. No context for prerequisites or limitations.
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?
With no annotations, the description should disclose behavioral traits. It only says 'check the status', which is vague. It does not indicate if the operation is read-only, what the status values are, or if there are side effects or polling behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, but it sacrifices essential information. A single sentence is efficient, but it lacks context that would help the agent. It is not overly verbose but is under-informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is woefully incomplete for a tool that monitors an asynchronous process. It does not explain return values, potential delays, or how the status relates to the agent lifecycle.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameter 'id'. It does not. The description merely repeats the tool's purpose without clarifying what the id represents (e.g., agent job ID from firecrawl_agent).
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 'check' and the resource 'status of an agent job'. It effectively distinguishes this tool from siblings like 'firecrawl_agent' (which creates an agent) and 'firecrawl_check_crawl_status' (which checks crawl status vs agent status).
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 or when not to. It does not mention that it should follow creating an agent via 'firecrawl_agent', nor does it offer alternatives or prerequisites.
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?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states 'extract structured data with license tracking' but does not mention whether the operation is read-only, requires authentication, has rate limits, or what 'license tracking' entails. The term 'extract' suggests data retrieval but no confirmation of safety or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks structure. For a tool with 4 parameters (including a nested object), the description should front-load the core purpose but also provide brief parameter guidance. Currently, it is too brief to be maximally useful.
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 has 4 parameters (with enums and nested objects) and no output schema, the description should explain what the tool returns, prerequisites (e.g., URL validity), and any constraints. It fails to provide this context, leaving a significant gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only the 'options' parameter has a description). The tool description adds 'license tracking' but does not clarify the meaning of parameters like 'stage' or 'distribution' beyond their enum values. For example, 'stage' could be a processing pipeline step, but no context is provided. This leaves agents to guess parameter semantics.
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 extracts structured data from URLs, which is a specific verb+resource. The addition of 'with license tracking' adds nuance. However, it does not clearly distinguish from sibling tools like firecrawl_scrape (which likely also extracts data) or firecrawl_crawl. Slightly more context on what 'structured data' means relative to other tools would improve clarity.
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?
No guidance on when to use this tool vs. alternatives such as firecrawl_scrape or firecrawl_crawl. No mention of prerequisites or ideal scenarios. The description lacks any usage context, leaving agents to infer appropriateness.
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?
With no annotations, the description must disclose behavioral traits. It mentions 'licensed fetch (x402-aware)' but does not explain implications, side effects, or limitations. No information on rate limits, auth, or cost.
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 very concise (one sentence) and front-loads the core action. However, it is too sparse to be truly effective, sacrificing completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 8 parameters, nested objects, and no output schema, the description provides almost no context about return format, pagination, or usage patterns. It is grossly incomplete for the complexity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, and the tool description adds almost no parameter-specific meaning beyond the schema. It only hints at the 'fetch' parameter but does not clarify the other 6 parameters or their roles.
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 it performs web search with an optional licensed fetch feature. However, it does not differentiate from sibling tools like firecrawl_crawl or firecrawl_scrape, which could overlap in perceived function.
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?
No guidance on when to use this tool versus alternatives such as firecrawl_crawl or firecrawl_extract. The description lacks context for decision-making.
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 provided, so the description must fully disclose behavior. It mentions 'x402-aware' but does not explain what this means for the agent (e.g., payment implications, rate limits, or failure modes). No mention of side effects, auth needs, or results.
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?
Single sentence with no wasted words. Front-loaded with the essential action (scrape a single URL) and key differentiator (x402-aware). Efficient and to the point.
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 (8 params, nested objects, no output schema, no annotations), the description is far too sparse. It does not cover the various parameters, their defaults, or expected output. The agent would lack sufficient context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (38%), and the description adds no new parameter information beyond the schema. It only references 'fetch' indirectly. The meaning of stage, options, distribution, payment_method, etc., remains unexplained, leaving the agent without context for correct usage.
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?
Description clearly states 'Scrape a single URL', a specific verb+resource. It also mentions 'licensed fetch (x402-aware)', which hints at a distinguishing feature. Among siblings like firecrawl_crawl (multiple URLs) and firecrawl_search, this tool's singular focus is clear.
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?
No guidance on when to use this tool versus alternatives like firecrawl_extract or firecrawl_map. No exclusions, prerequisites, or context for when 'licensed fetch' is appropriate. The description does not help in decision-making.
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

mcp-firecrawl-licensed-preview MCP server

Copy to your README.md:

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

Score Badge

Copy to your README.md:

[![mcp-firecrawl-licensed-preview MCP server](https://glama.ai/mcp/servers/tymrtn/mcp-firecrawl-licensed-preview/badges/score.svg)](https://glama.ai/mcp/servers/tymrtn/mcp-firecrawl-licensed-preview)

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/tymrtn/mcp-firecrawl-licensed-preview'

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