Firecrawl MCP Server

Find Tools

firecrawl_find_tools

Read-onlyIdempotent

Discover Alexandria data providers, workflows, and published contracts by category, query, or URL to identify the right data source and inputs before scraping.

Instructions

Browse Alexandria data providers and workflows or read a selected contract. Alexandria covers companies, people, jobs, finance and filings, public records and government spending, real estate, places and restaurants, retail and prices, package registries and developer data, news, research, and more: typed, sourced records through published contracts. Prefer normal firecrawl_search for a data task; it already returns matching providers. Use this tool when the contract you need was not returned in full, to browse a category when search found nothing, or before scraping the same fields from several pages. Discovery is free. Use query for semantic discovery or urls to find providers for a website. With no arguments, browse categories, then providers and tools. Contracts describe the inputs and outputs for execution through firecrawl_scrape. nextTool identifies further discovery or pagination. Discovery does not execute providers. Use firecrawl_search when you also need web results.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "firecrawl_find_tools"
  }
}

Input Schema

Name	Required	Description
`urls`	No
`level`	No
`limit`	No
`query`	No	Semantic lookup of tools for the data you need. Selectors constrain the search.
`expand`	No	Use ["options", "response"] for inputs and output shape without example payloads; [] keeps results compact. Omit for full contracts on selected capabilities.
`groups`	No	Optional group IDs for explicit group browsing.
`offset`	No
`providers`	No	Provider IDs returned by category browsing. Lists compact tools by default.
`categories`	No	Category IDs returned by an empty call. Lists providers by default.
`capabilities`	No	Exact capability IDs. A selected capability expands its complete contract by default.

Output Schema

Name	Required	Description
`data`	No	Discovery page in `data.alexandria[0].data`, with `level`, `items`, `total`, and an optional `nextTool`.
`error`	No	Error message or error object when the call did not succeed.
`message`	No	Guidance that accompanies the result.
`receipt`	No	Billing receipt for the execution.
`success`	No	Whether the API call succeeded.
`delivery`	No	`retained` when the full result stayed server-side instead of being inlined.
`nextTool`	No	A follow-up tool call (`{name, arguments}`) that continues or inspects this result.
`requestId`	No	Identifier of this Alexandria execution.
`scrape_id`	No	Identifier of the underlying scrape.
`agent_hints`	No	Optional response guidance from the Firecrawl API.
`creditsCost`	No	Credits this call consumed.
`workspaceId`	No	Workspace holding a retained result, for inspection through virtual Bash.
`feedbackTool`	No	Pointer to the feedback tool for reporting how this result served the task.
`responseBytes`	No	Size of the full result in bytes.
`idleTtlSeconds`	No	Seconds a retained workspace stays available while idle.
`estimatedTokens`	No	Estimated token cost of the full result.
`inlineTokenBudget`	No	Token budget above which a result is retained rather than inlined.
`tokenEstimateMethod`	No	How `estimatedTokens` was derived.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv3.28.2Nov 4, 2026

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only, idempotent and non-destructive, but the description adds real behavioral context: discovery is free, discovery never executes providers, contracts feed firecrawl_scrape, and nextTool signals further discovery or pagination. It does not cover result-size limits or rate limiting, so it falls short of the top mark.

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?

Purpose and the alternative tool are front-loaded, which is good, but the description is long and partly redundant — the firecrawl_search preference is stated twice ('Prefer normal firecrawl_search' and 'Use firecrawl_search when you also need web results'). The long Alexandria domain list consumes space that might have gone to level/limit/offset semantics.

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?

With an output schema present, the description needn't explain return shapes, and it still flags nextTool for continuation. For a 10-parameter, all-optional browsing tool, the main gap is paging behavior (limit/offset) and how the selectors interact, which are left to the schema.

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?

At 60% schema coverage the description usefully explains the calling pattern: query for semantic discovery, urls to find providers for a website, and no arguments to walk categories down to providers and tools. It also implies how level behaves across these modes, though limit and offset are left entirely to 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?

Opens with a specific verb+resource: 'Browse Alexandria data providers and workflows or read a selected contract', and immediately states what Alexandria covers (typed, sourced records through published contracts). It explicitly separates itself from firecrawl_search and firecrawl_scrape, so an agent can pick the right tool without opening a schema.

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?

Gives a default ('Prefer normal firecrawl_search for a data task'), then three explicit when-to-use conditions (contract not returned in full, category browse when search found nothing, before scraping the same fields across pages), plus an alternative ('Use firecrawl_search when you also need web results'). The exclusion 'Discovery does not execute providers' cleanly routes execution to firecrawl_scrape.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.