Loading ToolBench
MCP server for Firecrawl — search, scrape, and interact with the web, and search scientific papers. Supports both cloud and self-hosted instances. Features include web search, scraping, page interaction, batch processing, LLM-powered content analysis, and research paper search over biomedical and arXiv literature (PubMed, bioRxiv, medRxiv, arXiv) with citation-graph expansion and full-text reading.
The Firecrawl MCP server demonstrates solid foundation with tool annotations (destructiveHint/readOnlyHint) and structured parameter schemas. However, critical gaps undermine production readiness: (1) Tool descriptions vary widely in quality, some are comprehensive (firecrawl_developer_search: 386 chars), others are sparse (firecrawl_monitor_list: 94 chars). (2) Parameter descriptions exist but many lack actionable constraints, e.g., 'Monitor name' has no length bounds, 'Webhook URL' lacks format guidance. (3) Error handling is not visible in the code provided; recovery guidance is absent. (4) Output schemas are not documented, the code shows input schemas but no explicit return type documentation. (5) The 'body' parameter in firecrawl_monitor_create and firecrawl_monitor_update is dangerously opaque (type: object, no properties listed), violating schema transparency. Naming is strong (verb_noun pattern), but parameter constraints are incomplete.
For a developer question — code behaviour, a library or framework, an API contract, an error message, or a known bug — search an index built for coding agents. The index covers repositories, GitHub issues, merged pull requests, repository READMEs, and curated documentation sites. Set skills to "only" to limit the search to agent-skill files. Returns ranked results with an ID, source type, URL, title, and the matched passages in markdown.
Create a recurring scrape, crawl, or search monitor that compares each check with its retained predecessor. The simple form accepts `page`/`pages` or `queries` plus a plain-language `goal`; the advanced `body` form controls targets, schedule, change-tracking formats, judging, retention, webhook, and notifications. In the simple form, a `goal` is required. If `queries` contains one or more non-empty values and is supplied with `page`/`pages`, `queries` create the search target and page targets are ignored. A monitor schedules future network checks and can send configured email or webhook notifications. Returns the created monitor.
Delete a monitor by ID.
Get details for a specific monitor by ID.
Opaque 'body' parameter in firecrawl_monitor_create and firecrawl_monitor_update. The schema declares type: object with no properties, leaving LLMs unable to compose valid payloads without external documentation. This violates the constrained-input pattern and forces agents to hallucinate field names.
Output schemas are not documented in the tool definitions. Code shows input schemas (via Zod) but provides no explicit documentation of what fields/types are returned. LLMs cannot plan downstream calls or extract the right data without knowing the response structure.
Parameter descriptions lack actionable constraints. E.g., 'Monitor name' has no length bounds, 'Webhook URL' lacks format validation guidance, 'Timezone' accepts any string without enum constraint. Descriptions should state format (e.g., 'RFC 3339 ISO 8601') and valid ranges.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 75 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
List monitors for the authenticated account with optional pagination controls. Returns one page of monitor records and pagination metadata.
Update an existing monitor configuration.
firecrawl_monitor_list description (94 chars) is under the baseline minimum (194 chars average). It does not explain pagination behavior, cursor semantics, or when to use offset vs limit. Discovery tool descriptions should guide when to call them.
Error handling and recovery guidance are not visible in the provided source. Tools do not document what errors can occur, how to retry, or what next steps the LLM should take. E.g., 'Monitor not found, call firecrawl_monitor_list to see available monitors.'
Irreversible operation (firecrawl_monitor_delete) has no confirmation or dry-run option. Agents can permanently delete monitors without a safety check. Should support a 'confirm_delete' or 'dry_run' parameter to prevent catastrophic errors.
The 'skills' parameter in firecrawl_developer_search accepts only the enum value 'only', but the description does not explain what 'skills' means or what happens when it is omitted (default behavior). Clarify the semantics: does omitting it search all indexes, or only non-skill sources?