Firecrawl launches Alexandria, with concise descriptions as the default for tool discovery

Firecrawl launched Alexandria on September 22, bringing web pages, specialized indexes, and data providers into a unified discovery and data retrieval workflow. For research agents, the change means first identifying available data capabilities, then inspecting their input/output specifications and invoking them, reducing the work required to integrate each provider’s interface individually. Firecrawl offers access through an API, MCP, and a command-line interface. [Official announcement](https://www.firecrawl.dev/blog/introducing-alexandria-series-b)

The popular repository also includes corresponding changes. A September 20 commit set tool discovery in search to `compact` by default, retaining only the provider, capability name, and description for each result. Summary or full mode can be specified when more information is needed. The commit also updated SDKs across multiple languages and tests to verify that compact results could be parsed successfully. [Implementation commit](https://github.com/firecrawl/firecrawl/commit/4e35739f830edf768719ad583828724f1d9f9dc3)

This design defers loading complete specifications until a tool has been selected, reducing the content introduced during initial discovery. It also changes client assumptions. Programs that previously read parameter schemas, costs, or response formats directly from search results must retrieve detailed specifications separately; a tool description alone is insufficient to construct an executable request. Actual workflows must still be measured to determine how many tokens this saves and whether it adds round-trip latency.

The MCP documentation describes a sequence of searching, expanding the selected capabilities with `firecrawl_find_tools`, and then executing through `firecrawl_scrape`. General search and URL scraping do not automatically invoke matching provider tools, and the search-only MCP endpoint lacks full discovery and execution capabilities. This makes finding a source and retrieving data separately loggable steps. [MCP documentation](https://github.com/firecrawl/firecrawl-mcp-server)

The official command-line guidance also requires checking geographic coverage, required inputs, credit costs, and access requirements before execution. If no suitable tool is found, the workflow should continue using regular web results. For Chinese-language research tasks, engineering teams should test coverage using local data sources and record tool selection errors and gaps. In particular, they should track tool discovery success rates separately from actual data retrieval rates to identify where failures occur. [Command-line guidance](https://github.com/firecrawl/cli/blob/main/skills/firecrawl-search/SKILL.md)

Firecrawl also says that blind AI scoring across 845 tasks showed a 21% improvement in answer quality using the same model and prompt. These are vendor-reported test results and cannot be directly extrapolated to Traditional Chinese, specific databases, or all agent frameworks. Adoption decisions still require comparing answer quality, total data retrieval costs, and latency together. [Evaluation details](https://www.firecrawl.dev/blog/introducing-alexandria-series-b)