firecrawl-mcp-server

by firecrawl

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v1.0.1
Disambiguation4/5
Most tools have distinct purposes, especially within their subgroups (monitor, research, feedback). However, there is potential confusion between scrape, extract, and parse, as all three deal with extracting data from pages. Also, agent and interact both involve dynamic page interaction. The descriptions help, but overlap exists.
Naming Consistency5/5
All tools follow the 'firecrawl_verb' or 'firecrawl_verb_noun' pattern consistently. Even the research subgroup uses 'firecrawl_research_action', maintaining a clear and predictable structure.
Tool Count3/5
26 tools is on the higher side. The server covers a broad scope (scraping, crawling, monitoring, research, feedback) which justifies the count, but it feels slightly bloated with very specific tools like firecrawl_interact_stop and separate feedback tools. Could be streamlined.
Completeness4/5
The tool surface is comprehensive for web data extraction and monitoring. It covers all major operations: scrape, crawl, map, search, extract, parse, interact, and monitor. The addition of research tools extends the domain. Minor gaps exist (e.g., no tool for bulk URL management), but overall it's well-covered.
Average 4.3/5 across 26 of 26 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 8 of 59 community issues answered or closed in the last 6 months
- 127 commits in the last 12 weeks
- Last stable release on September 26, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
This repository includes a glama.json configuration file.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds no new behavioral context (e.g., pagination behavior, rate limits, or data freshness).
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 brief (one line plus a code block) but lacks necessary detail. Conciseness is acceptable but at the expense of completeness.
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?
With no output schema and low schema coverage, the description does not explain return format, pagination, or error handling. Incomplete for a listing tool with sibling complexity.
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 0%. The description only shows a usage example with limit, but does not explain the meaning or valid values of limit and offset parameters. Does not compensate for lack of schema documentation.
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 action (list) and resource (Firecrawl monitors) with scope (authenticated account). It distinguishes from sibling tools like firecrawl_monitor_get or firecrawl_monitor_create.
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 alternative monitor tools (e.g., firecrawl_monitor_get for a single monitor). Only a usage example with limit is provided, but no context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds no additional behavioral context such as pagination behavior, rate limits, or sorting order. With annotations covering safety, a baseline score of 3 is appropriate.
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?
Extremely concise: one line of description plus a useful usage example. No wasted words, but the lack of parameter descriptions could be seen as under-specification rather than conciseness. Still, it is well-structured and front-loaded.
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?
Despite being a simple read operation with 4 parameters and no output schema, the description fails to explain parameters (0% coverage) or return format. The usage example provides hints but not completeness. More context on filtering and pagination would be expected.
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 0%. The description does not describe any parameter meanings, and the usage example only shows id, limit, and status but not offset. The enum values for status are not explained. Minimal added value over 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?
Description clearly states 'List historical checks for a monitor', matching the verb 'list' and resource 'historical checks'. It distinguishes from siblings like 'firecrawl_monitor_check' (singular, likely get one check) and 'firecrawl_monitor_list' (list monitors).
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 explicit guidance on when to use this tool vs alternatives. The usage example provides a basic call structure but does not explain when to use this tool over others like 'firecrawl_monitor_check' or filtering with parameters.
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?
Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds no further behavioral context such as error handling or rate limits.
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?
Short and front-loaded with purpose. The usage example is helpful but could be omitted for brevity. Still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool with annotations and one parameter, the description is adequate but does not describe return value or error scenarios.
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 0% and the description does not explain the 'id' parameter beyond an example ('mon_abc123'). It lacks format or 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 'Get a single monitor by ID' with a specific verb and resource. It distinguishes from sibling tools like firecrawl_monitor_list and firecrawl_monitor_create.
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. The description only provides a usage example but does not specify context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's a safe query. The description adds that it returns 'Status and progress of the crawl job, including results if available,' which is helpful but does not cover error states or rate limits.
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 short and to the point: one sentence for purpose, a code example, and a note on return. Every element adds value, and the key information is front-loaded. No unnecessary words.
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 simplicity (1 param, no output schema), the description covers the basics. However, it omits where the 'id' comes from (a crawl job), potential error scenarios, and full return structure. Sibling tools like firecrawl_crawl imply the source, but it's not explicit.
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?
With schema description coverage at 0%, the description fails to explain the 'id' parameter beyond the schema's type string. The usage example shows a UUID but does not state that it must be a valid crawl job ID from a previous firecrawl_crawl call. The only parameter is left ambiguous.
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?
Clearly states 'Check the status of a crawl job' with a specific verb and resource. The usage example reinforces the purpose, and it distinguishes itself from siblings like firecrawl_crawl (starts a crawl) and other unrelated tools.
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?
Provides a usage example showing the 'id' parameter, implying it's used after a crawl job is started. However, it lacks explicit guidance on when to use this tool vs siblings (e.g., firecrawl_agent_status) or when not to use it. No prerequisites or alternatives are mentioned.
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?
Annotations already indicate destructiveHint=true and readOnlyHint=false. Description confirms update behavior but adds no additional details about side effects, permissions, or reversibility.
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?
Very concise, front-loaded with purpose, includes a clear usage example in JSON. No wasted words.
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?
Partially complete: lists updatable fields but does not describe return value, side effects, or error states. For a destructive update with openWorldHint, more context would help.
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 has 0% coverage for body properties. Description compensates by listing expected fields (name, status, schedule, etc.) and some enums (status: 'active'|'paused'). Not exhaustive but adds significant 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?
Description clearly states 'Update a monitor' and lists specific fields that can be patched (name, status, schedule, etc.). This distinguishes it from sibling tools like create or delete.
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?
Implied usage: updating an existing monitor. No explicit when-to-use or alternatives provided, though sibling names suggest 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?
The description goes beyond annotations by specifying the return structure: ranked matches with repo, url, snippet, and optionally full content in markdown. Annotations already indicate read-only and non-destructive, so the description adds value by detailing what the agent can expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundancy. It front-loads the action and resource, then details the return format. Every word is necessary and there is no fluff.
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 simple search tool with 2 parameters and no output schema, the description covers scope and output structure well. However, it omits any mention of pagination, sorting, or result limits (e.g., default k). The absence of these details is a minor gap, but overall it provides sufficient context for most use cases.
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 schema provides no descriptions for query or k. The tool description does not explain what k (likely number of results) represents, nor any details about the query format. Since the description adds no meaning beyond the schema, the score is minimal.
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 uses the verb 'Search' and specifies the resource as 'GitHub issue/PR history and repository readmes', distinguishing it from sibling tools like firecrawl_search (general web search) and firecrawl_research_search_papers (papers). The name also includes 'github' to further clarify the scope.
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 that this tool is for searching GitHub-specific content, but does not explicitly state when to use it over general search or paper search. No alternative tools or exclusions are mentioned, leaving the agent to infer usage context from the tool name and siblings.
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?
Annotations already provide destructiveHint: true, but the description adds key behavioral context: the deletion is permanent, cannot be undone, and stops the schedule. No contradiction with annotations.
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 very concise: two sentences plus a usage example. No wasted words, front-loaded with the essential action.
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 simple destructive tool with one parameter and no output schema, the description covers the main points: action, permanence, and example. It lacks prerequisites or side effects but is still adequate.
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 has 0% description coverage with one required parameter 'id' (string). The description provides an example argument 'mon_abc123' but does not explain what the parameter represents or its format, leaving the agent to infer.
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 action (delete) and resource (monitor), and distinguishes it from sibling tools like create, update, get, list, run, check. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for permanent deletion but does not explicitly state when not to use it or mention alternatives like update for deactivation. There is some implied context but no explicit guidance.
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?
Annotations already declare destructiveHint=true. The description adds that resources are freed, which is useful context beyond annotations. No contradictions.
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?
Very concise: two sentences plus a usage example. Front-loaded with the purpose and usage condition. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool (1 param, no output schema), the description covers the basic action and when to invoke. However, it lacks details on the return format (only 'Success confirmation') and the relation to firecrawl_interact for obtaining the scrapeId.
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 0% (no description in schema). The description only shows a usage example with 'scrape-id-here' but does not explain what the scrapeId represents or how to obtain it, leaving the agent with minimal guidance.
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 ('stop') and resource ('interact session'), and distinguishes from the sibling 'firecrawl_interact' tool which starts the session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Call this when you are done interacting to free resources', providing a clear usage condition. Does not mention when not to use, but the pairing with firecrawl_interact makes it evident.
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?
Annotations provide readOnlyHint=false and destructiveHint=false; description adds that crawl can be slow, responses may exceed token limits, and warns about limit/depth settings. No contradiction. Could mention resource usage more, but sufficient.
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?
Well-structured with sections, front-loaded main action, and every sentence adds value (best-for, warnings, examples). Length is justified given complexity.
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?
Complex tool with many parameters and nested objects; description covers high-level guidance and examples but lacks detailed parameter semantics and output explanation. No output schema, so more detail expected.
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 0% with 17 parameters (including nested scrapeOptions). The description only explains parameters indirectly via a usage example and common mistakes. Inadequate compensation for low 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 it starts a crawl job, polls until terminal, and returns data. It distinguishes from sibling tools like scrape and map via explicit best-for/not-recommended sections.
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?
Explicitly lists when to use (multiple pages) and when not (single page, token concerns, speed), with alternative tool names (scrape, map + scrape). Includes common mistakes and a prompt example.
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?
The description adds context beyond annotations: it notes the action is non-destructive (destructiveHint=false) and readOnlyHint=false, aligning with 'trigger a check' and 'returns the queued check'. It does not detail side effects or permissions, but the behavior is adequately described for a simple trigger action.
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 highly concise: two sentences plus a brief code example. Every sentence is valuable, and the most critical information (verb, resource, return value) is front-loaded. No unnecessary 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 the simple tool (1 required param, no output schema), the description covers the essential aspects: what the tool does, when to use it, and what it returns. The example clarifies usage. While it could mention the return type more explicitly, it is sufficient for an agent to invoke correctly.
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?
With 0% schema description coverage, the description must compensate for the single id parameter. It provides a usage example with 'mon_abc123', implying the ID format, but does not explicitly state that id is the monitor ID. This adds some meaning but falls short of fully documenting the parameter. A baseline of 4 for a single param is reduced due to lack of explicit explanation.
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 'Trigger' and the resource 'monitor check', distinguishing it from sibling tools like firecrawl_monitor_check and firecrawl_monitor_list. It explains immediate execution outside normal schedule, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use ('immediately, outside its normal schedule') and provides a usage example. However, it does not explicitly mention when not to use or list alternatives, such as firecrawl_monitor_check for checking status. Still, guidance is clear enough for a straightforward tool.
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?
The description explains that the tool posts to /v2/feedback, provides constraints on field usage (e.g., no huge outputs, use concise notes), and outlines the return format. Annotations only indicate it is not read-only and not destructive; the description adds context beyond that, meeting the requirement for behavioral disclosure.
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 efficiently structured, starting with the core purpose, then usage guidance, parameter details, and return format. Each sentence adds value without redundancy. At ~250 words, it is appropriately sized for the tool's complexity.
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?
Despite covering the main purpose and many parameters, the description does not address three schema properties (missingContent, valuableSources, querySuggestions). Given the tool has 12 parameters and nested objects, this gap reduces completeness, though the return format and constraints are well covered.
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 0% schema description coverage, the description compensates by explaining 9 of 12 parameters (endpoint, jobId, rating, issues, tags, note, url, pageNumbers, metadata) with examples and constraints. However, it omits three properties (missingContent, valuableSources, querySuggestions), leaving some semantics unaddressed.
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?
Explicitly states the tool sends structured feedback for completed Firecrawl v2 jobs, lists the specific endpoints (scrape, parse, map, search), and distinguishes from the sibling firecrawl_search_feedback by noting it is for endpoint-level feedback whereas search-specific feedback should use the other tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly states when to use the tool (after a job completes, for endpoint-level feedback) and provides an explicit alternative (firecrawl_search_feedback for search-result quality). However, it does not explicitly list situations where this tool should not be used, though the guidance is sufficient for typical use.
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?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so this is a safe read operation. The description adds valuable behavioral context: it is faster and cheaper than firecrawl_agent, and it returns an array of URLs. No contradictions.
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, bold headers, and JSON examples. It is front-loaded with a clear purpose. However, it is slightly verbose, repeating the 'use map before agent' message in multiple places. Still, effective and organized.
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 has 6 parameters, no output schema, but helpful annotations and many siblings, the description covers the core usage well. However, it lacks details on optional parameters like 'limit' and 'sitemap', and the return format is minimally described as 'Array of URLs'. For a tool intended for workflow initiation, more specificity on output and parameter options would be beneficial.
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?
Input schema has 0% description coverage for parameters. The description only demonstrates 'url' and 'search' via examples, but does not explain the other 4 parameters (limit, sitemap, includeSubdomains, ignoreQueryParameters). This leaves the agent without guidance on how to use important optional parameters.
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 defines the tool's purpose: mapping a website to discover URLs. It distinguishes from siblings by explicitly stating it is for URL discovery, not content scraping (firecrawl_scrape) or crawling (firecrawl_crawl). The contrast with firecrawl_agent is also clear.
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?
Excellent usage guidance with explicit 'Best for', 'Not recommended for', 'Common mistakes', and 'IMPORTANT - Use map before agent' sections. It tells when to use the tool (discovering URLs, before scraping) and when not to (when you know the URL, need content). Provides a workflow: map then scrape, agent as last resort.
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?
Annotations indicate readOnlyHint=true; the description adds extensive behavioral detail: different diff modes (Markdown, JSON, Mixed), pagination via `next` URL, judgment structure with meaningful flags, and snapshot formats. No contradiction with annotations.
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 lengthy but well-structured with sections for different diff modes, a JSON example, and a usage example. It front-loads the purpose. Every sentence adds value, though some detail could be trimmed (e.g., repeated JSON examples).
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 no output schema, the description thoroughly covers response structure, pagination, judgment, and diff variations. It anticipates common use cases (filtering, summarizing changes) and explains edge cases like 'meaningful: false'. Complete for this tool's complexity.
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 coverage is 0%, but the description adds meaning for pageStatus and limit (explaining their use). However, id, checkId, and skip are not described beyond their names. The description partially compensates but leaves gaps.
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 starts with a specific verb+resource: 'Get a single check with page-level diff results.' It clearly identifies the tool's function and distinguishes it from siblings like firecrawl_monitor_checks (list checks) and firecrawl_monitor_get (get monitor config).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: how to filter by pageStatus, preference for diff.json over markdown, how to use judgment, and pagination hints (increase limit, next URL). It includes a usage example. However, it does not explicitly state when not to use this tool or list alternative tools.
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?
The description adds value beyond annotations by specifying that the tool fetches metadata and renders it as markdown. Annotations already indicate readOnlyHint=true and openWorldHint=true, which the description aligns with. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the purpose, and contains no unnecessary words. Every word adds value, making it highly efficient.
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 has only one required parameter and no output schema, the description adequately covers what the tool returns (title, abstract, authors, categories, source ids, dates as markdown). It is complete for a simple fetch operation.
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 coverage is 100%, so the description is not required to detail parameters, but it adds context by providing examples of valid paper ID formats (arxiv, pmcid, pmid, doi) and stating it uses primaryId or canonical paperId. This enhances 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 begins with 'Fetch canonical metadata for one paper by primaryId or canonical paperId,' which clearly states the action and resource. It distinguishes from siblings by specifying it is for inspecting a single paper after search or related results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using this tool 'after search/related results when you need the full title, abstract, authors, categories, source ids, and dates rendered as markdown.' This provides clear context for when to use it, though it does not explicitly state when not to use it or offer 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?
Annotations only provide title, readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds significant behavioral context: performance with maxAge, lockdown mode (no outbound requests, cache-only), privacy redaction, JavaScript rendering handling with waitFor and retry strategies, and format-specific behaviors. It does not explicitly state it is read-only, but actions are implied to be non-destructive. The description covers most important traits beyond annotations, though it could be more structured.
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 very long and contains redundant instructions (e.g., format selection guidance appears twice). While it front-loads the main purpose and provides structured sections (Best for, Not recommended, Common mistakes, Critical, Handling JavaScript), the verbosity could be trimmed. Some information could be moved to separate documentation or example files. A more concise version would improve scanability.
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 complexity (23 params, no output schema, nested objects), the description covers most critical aspects: when to use which format, how to handle JavaScript rendering, caching, privacy, and lockdown mode. It mentions return formats (JSON, markdown, branding) but does not detail the structure of each output type. Without an output schema, it could specify fields returned per format, but the examples partially fill this gap. Overall, it is comprehensive enough for effective tool selection and invocation.
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?
The schema has 23 parameters with 0% coverage (no explicit descriptions in schema). The description compensates by explaining key parameters like formats (markdown, json, query, branding), waitFor, onlyMainContent, maxAge, lockdown, redactPII, actions, jsonOptions, and queryOptions in context. It provides usage examples and rules for format selection. However, some parameters like proxy, mobile, excludeTags, includeTags, screenshotOptions are not elaborated. Given the large parameter count, this is acceptable but not exhaustive.
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 scrapes a single URL with advanced options. It distinguishes itself from siblings like crawl (multiple pages) and search (unknown page location), and emphasizes it is the most powerful and reliable scraper. The verb 'scrape' plus 'single URL' is specific and actionable.
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 states best use cases (single page extraction) and not recommended scenarios (multiple pages, unknown location) with alternative tools. It provides common mistakes, critical format selection rules with examples, and a step-by-step approach for JavaScript-rendered pages. This leaves no ambiguity about when to invoke this tool versus siblings.
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?
Annotations indicate read-only and open-world. Description adds behavioral details: return format with id and creditsUsed, credit refund on first feedback, and timeout guidance for scrapeOptions. No contradictions.
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?
Well-structured with sections (Best for, Not recommended for, etc.) but verbose with multiple examples and a long operator table. Could be more concise without losing clarity.
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 11 params, no output schema, and low schema coverage, the description comprehensively covers purpose, alternatives, workflow, return format, and key parameters. Leaves a few minor parameters undocumented but overall adequate.
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 coverage is only 9% (only categories described). Description compensates by explaining sources, categories, domain filters, scrapeOptions, and search operators in detail, though some parameters like tbs, filter, location remain unexplained.
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 'Search the web and optionally extract content from search results' and positions it as the default web search tool. It distinguishes from siblings by explicitly stating when to use search vs scrape, crawl, or map.
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?
Provides explicit when-to-use ('Finding specific information across multiple websites') and when-not-to-use ('filesystem', 'known website', 'comprehensive coverage'), plus common mistakes and an optimal workflow.
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?
Discloses two operational modes (local/non-cloud and hosted CLOUD_SERVICE) with detailed two-call flow for hosted mode. Lists unsupported options, privacy settings, and format selection rules. Annotations indicate readOnlyHint=true, and description confirms read-only behavior, no contradiction.
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?
Description is well-structured with sections (best for, not recommended, common mistakes, etc.) and front-loaded with purpose. However, it is verbose and could be more concise by trimming redundant explanations, such as repeating the two-call flow in multiple places.
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 complexity (17 params, two modes, no output schema), description covers modes, examples, format selection, and limitations. It mentions return types (upload instructions or parsed document). Could add more detail on return structure or error handling, but overall sufficient for agent usage.
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 only 12%, but description compensates by explaining key parameters like filePath, formats, parsers, and the two-phase usage. However, many parameters (proxy, maxAge, excludeTags, etc.) are not explained in detail. Examples cover critical scenarios, but systematic parameter documentation is lacking.
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 the tool parses a local file using Firecrawl's /v2/parse endpoint. It distinguishes from siblings by explicitly noting it is not for remote URLs (use firecrawl_scrape) and not for multiple files. Specific use cases are given (PDF, Word, Excel, HTML), and the verb 'Parse' is precise.
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?
Explicitly instructs when to use (extracting content from local documents) and when not (remote URLs, multiple files, interactive documents). Names alternatives like firecrawl_scrape for remote URLs. Warns about common mistakes in hosted mode, such as not mixing filePath and uploadRef.
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?
Annotations already indicate readOnlyHint=true, openWorldHint=true, destructiveHint=false. The description adds value by specifying that it returns 'best-matching passages' or a notice if full text is unavailable, which goes beyond annotations to explain behavior.
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 three sentences, each serving a purpose: core action, use case, and output. No redundancy or unnecessary words.
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 research paper reading tool with no output schema, the description fully explains the purpose (read passages for verification), the input (paper ID and question), and what to expect (passages or unavailability notice). It is sufficient 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, with descriptions for paperId and k but not for question. The tool description does not add extra parameter details beyond the schema. Since coverage is high, baseline 3 is appropriate.
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 uses specific verbs ('Read', 'VERIFY') and specifies the resource (in-body passages of one paper for a question). It clearly differentiates from sibling tools like firecrawl_research_search_papers by focusing on verification of candidate constraints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear use case ('VERIFY whether a candidate satisfies a constraint') but does not explicitly exclude alternative tools or mention when not to use. The context includes sibling tools for inspection and search, but no direct comparison.
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?
The description fully discloses behavioral traits: monitoring is recurring with a default 30-minute schedule, uses meaningful-change judging, exposes webhooks for page events, and supports diff-based alerts. Annotations (readOnlyHint=false, destructiveHint=false) are consistent. No contradictions.
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 highly verbose, with multiple sections and examples that repeat concepts. While structured, it contains unnecessary detail (e.g., goal guidance, query guidance) that could be condensed. The length impacts readability for an AI agent parsing tool definitions.
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 (15 parameters, no required params, no output schema, multiple modes), the description is comprehensive. It covers all parameters, provides goal guidance, query formatting, examples for each mode (simple, multiple pages, JSON tracking, mixed), and explains behavioral nuances. It leaves no significant gaps for an AI agent to resolve.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides extensive parameter semantics for all 15 parameters, including simple fields (page, pages, queries, goal, etc.) and detailed body structure with examples. It also explains enums like searchWindow and constraints like maxResults range. This fully compensates for the lack of 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: 'Create a Firecrawl monitor — a recurring scrape, crawl, or search that diffs each result against the last retained snapshot.' It uses a specific verb ('Create') and resource ('monitor'), and distinguishes it from sibling tools like firecrawl_monitor_check by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description guides when to use simple parameters (page, pages, queries) vs. the 'body' for advanced requests. It also explains when to use queries vs. fixed URLs. However, it does not explicitly compare against other monitor tools (e.g., firecrawl_monitor_check), leaving some ambiguity for an agent to decide between creation and retrieval.
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?
Annotations already provide readOnlyHint, openWorldHint, and destructiveHint. The description adds substantive behavioral context: semantic search over indexed metadata and abstracts, ranked results, and recall improvement strategy. No contradictions; full disclosure of search methodology.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose and scope, search method and output, usage advice. Front-loaded with essential information. No superfluous text; every sentence earns its place.
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 6 parameters, no output schema, and annotations present, the description explains search method, output format, parameter semantics, and usage strategy. It covers what an agent needs to invoke the tool correctly and interpret results. Absence of pagination details is acceptable for a ranked list.
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 coverage is 100% so baseline is 3. The description adds value by explaining the query should be a natural-language topic/question and advising diverse framings. It also provides the default value for k (40), clarifies case-insensitive substring matching for authors, and gives an example for categories. Meaningful additions beyond 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 it is the 'Primary entry point for finding research papers by topic' across multiple scientific domains. It specifies the search method (semantic HyDE), output fields (paper id, title, authors, abstract), and distinguishes from siblings by positioning itself as the primary search tool among the firecrawl_research_* family.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises running 'SEVERAL distinct framings of the question' for better recall, providing actionable guidance. It implies use before other research tools but does not explicitly contrast with siblings like firecrawl_research_inspect_paper or firecrawl_search. Adequate context for usage.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it uses LLM (cloud or self-hosted) and returns structured data, which provides useful context without contradicting annotations.
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?
Well-structured with sections (Best for, Not recommended, Arguments, Prompt Example, Usage Example, Returns). Every sentence adds value, and the description is appropriately sized for the tool's complexity.
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 tool with 6 parameters (1 required) and no output schema, the description explains the output as structured data per the schema, includes a usage example, and covers key options. It is complete enough for an agent to understand and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by listing all parameters with clear explanations (urls, prompt, schema, allowExternalLinks, etc.) and providing a prompt example and usage example, adding significant meaning 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 it extracts structured information from web pages using LLM capabilities. It distinguishes itself from siblings like scrape by specifying that it's for structured data extraction, not full content.
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?
Explicitly provides 'Best for' and 'Not recommended for' sections, contrasting with scrape for full content. This helps the agent choose the correct 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?
Annotations already indicate openWorldHint=true. Description adds crucial behavioral context: async execution with job ID return, polling requirement, typical duration, and autonomy in navigation. No contradictions with annotations (readOnlyHint=false, destructiveHint=false).
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?
Description is well-structured with markdown headers and sections, front-loading key purpose. While lengthy, it earns its length given async complexity. Could be slightly more concise, but all information is useful and clearly organized.
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 complexity (async, 3 params, no output schema, nested objects), description covers async workflow, polling guidance, timing expectations, argument details, examples, and return value (job ID). No gaps remain for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no property descriptions), but description compensates fully. It explains prompt as 'natural language description of the data you want' with max length, urls as optional focus array, schema as optional JSON schema for structured output. Includes examples.
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 it is an 'Autonomous web research agent' that independently browses and extracts data. It distinguishes from siblings like firecrawl_scrape (single-page extraction) and firecrawl_search (web search), providing specific guidance on when to use which.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Best for' and 'Not recommended for' sections list when to use this tool vs alternatives (e.g., firecrawl_scrape, firecrawl_search). Detailed async workflow with polling intervals (15-30 seconds) and expected wait times (30s to 5+ min) is provided.
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?
Annotations declare readOnlyHint=true, destructiveHint=false. Description adds polling behavior, statuses, and patience advice without contradiction.
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?
Well-structured with sections, example JSON, list of statuses. Detailed yet concise, every sentence adds value.
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?
Covers polling strategy, status meanings, result retrieval. No output schema but describes return types. Complete for a status polling tool.
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?
Only one parameter `id` with no schema description. Description mentions 'id' is from firecrawl_agent, which is adequate context. Could specify format but not necessary.
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?
Explicitly states it checks status of agent job and retrieves results. Clearly distinguishes from sibling `firecrawl_agent` which starts the agent.
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?
Provides detailed polling instructions: interval 15-30s, minimum 2-3 minutes patience, stop only on 'completed' or 'failed'. Explains when to use (after starting agent).
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?
Annotations already provide readOnlyHint, openWorldHint, destructiveHint. Description expands with internal multi-round expansion behavior and mentions return format (candidates plus pool size). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with core purpose, then usage guidance, then technical detail. Every sentence earns its place; no fluff.
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 no output schema, description mentions returns candidates plus pool size. Fully covers behavior, usage context, and parameter semantics for key parameters. No gaps.
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 coverage is low (20%). Description explains seed_ids (arXiv IDs), intent (natural-language), and mode (enum options). Adds value by noting internal expansion. However, k and rerank parameters are not explained in description.
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: expand from anchor papers via citation graph, ranked and filtered to intent. It distinguishes from siblings like firecrawl_research_search_papers by noting it finds papers plain search misses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: use on 'best hits before finishing', explains one call suffices due to internal multi-round expansion, and contrasts with plain search. Also lists modes and their meanings.
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?
Beyond annotations (readOnlyHint=false, destructiveHint=false), the description details behavioral traits: it opens a live browser session, allows interaction (clicking, filling forms), reuses sessions via scrapeId, and returns execution results including stdout, stderr, exit code, and live view URLs. No contradictions with annotations.
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: purpose, best for, two modes, argument list, examples, returns. It is concise yet comprehensive, front-loading key information. Every sentence adds value.
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?
Despite no output schema and complex nested parameters (scrapeOptions), the description covers all parameters, provides usage examples, and explains the return structure. It gives enough context for an AI agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), but the description thoroughly explains each parameter in the 'Arguments' section, including mutual exclusivity (url vs scrapeId, prompt vs code), language options, timeout range, and scrapeOptions usage. This adds significant meaning 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: 'Interact with a page in a live browser session: click buttons, fill forms, extract dynamic content, or navigate deeper.' It uses a specific verb and resource and distinguishes itself from siblings like firecrawl_scrape by emphasizing multi-step workflows.
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 the tool ('Best for: Multi-step workflows on a single page') and explains two targeting modes (url vs scrapeId) with different use cases. It implicitly excludes single-step scraping, suggesting firecrawl_scrape for that.
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?
The description adds significant behavioral context beyond annotations: idempotent per searchId, refund only for billable searches, daily refund cap (100 credits), behavior on cap (still records feedback), time window expiry. Annotations (readOnlyHint=false, destructiveHint=false) are not contradicted; description complements them.
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 headings, bullet points, and examples. It is front-loaded with purpose and immediate usage. Every sentence adds value, covering all aspects without redundancy. Despite length, it remains clear and scannable.
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 has 5 parameters (2 required), no output schema, and nested objects, the description is thorough. It explains return fields (success, feedbackId, creditsRefunded, etc.) even without an output schema. It covers edge cases (time window, idempotency, cap, 4xx handling). For a non-trivial tool, this is highly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at only 20%, the description compensates fully. It explains the `rating` enum values, `valuableSources` structure, `missingContent` as 'most important field' with examples, `querySuggestions` usage. It also provides substantive-feedback requirements per rating. The detailed usage examples further clarify parameters.
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: 'Send structured feedback on a previous `firecrawl_search` result.' It specifies the verb (send feedback), resource (search result), and includes context for quality improvement and credit refund. This distinguishes it from siblings like `firecrawl_feedback`.
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 says when to call: 'Call this immediately after a search where you used the results' and provides when-not-to-call conditions: time window (~2 minutes), failed searches, daily cap reached, with proper responses (HTTP 409, etc.). It also advises not to retry on 4xx, giving clear guidance.
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-server MCP server](https://glama.ai/mcp/servers/firecrawl/firecrawl-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/firecrawl/firecrawl-mcp-server)

Score Badge

Copy to your README.md:

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

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/firecrawl/firecrawl-mcp-server'

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