Firecrawl CLI: scraping, searching and agent skills from the terminal

What Firecrawl CLI actually solves

Getting a web page into an agent's context usually means one of three things: writing a small fetch script, pasting text by hand, or wiring an MCP server into an editor. Firecrawl CLI takes a fourth route. It is a command named `firecrawl` that turns a URL into markdown, HTML or structured output in one line, and it ships skill files that teach a coding agent how to run those same commands. The README describes the scope as search, scrape, interact, crawl, map, research paper search and agent jobs, all from the terminal.

The audience is narrow but specific. You are already using Firecrawl, or willing to, and you want the same capability in two places: a shell where you can pipe output into a file, and an AI coding agent that should be able to look things up on the web without you leaving the editor. The package description also mentions a research paper index covering PubMed, bioRxiv, medRxiv and arXiv, which points at a second audience: people doing literature work who would rather type a command than open four browser tabs.

What it is not is a self-hosted scraper. Every invocation goes to a Firecrawl endpoint, and the repository's own setup path is built around authenticating to a Firecrawl account.

How the command, the skills and the MCP server fit together

There are three separable pieces here, and the README treats them as layers.

The first is the CLI binary itself. `package.json` maps the `firecrawl` bin to `dist/index.js`, so the command is a compiled TypeScript entry point. Commands like `scrape`, `crawl`, `map` and `search` are thin clients over the Firecrawl API. Multi-URL scrapes run concurrently and, per the README, each result is saved into a `.firecrawl/` directory automatically rather than dumped to stdout.

The second layer is skills: markdown files installed into the directories your coding agent reads. The README splits them into CLI skills, which teach an agent to call the `firecrawl` command for live web work, and workflow skills, which are end-to-end recipes such as research briefs, SEO audits, QA reports and lead lists. A third family, build skills, covers integrating the Firecrawl API into application code and lives in a separate catalog repository.

The third layer is `firecrawl setup defaults`, which goes further than installing files. It rewrites agent configuration so that native web fetch and search are disabled and web work is routed through Firecrawl instead. That is a real change to how your editor behaves, and it is the part of this tool most worth understanding before you run it.

Installing Firecrawl CLI and running a first scrape

The README gives a global npm install as the plain path. Because it is published as `firecrawl-cli`, the package name differs from the binary name you type afterwards.

npm install -g firecrawl-cli

After that, `firecrawl` is on your PATH. The quickest check is to pass a URL with no subcommand, which the README documents as equivalent to `scrape`:

firecrawl https://example.com

The first run prompts for authentication, offering browser login or a manually entered API key, and notes that `FIRECRAWL_API_KEY` can be set instead. For non-interactive environments, the key can be passed per command:

firecrawl scrape https://example.com --api-key fc-your-api-key

Output defaults to markdown. `--html` or `-H` returns raw HTML, `--format markdown,links,images` switches the output to JSON, and `-o output.md` writes to a file.

If you would rather have the whole environment set up at once, the README offers a single command that installs the CLI globally, authenticates and adds skills across every detected coding editor:

npx -y firecrawl-cli@latest init -y --browser

Here `-y` skips prompts and `--browser` opens the browser for authentication. Note what the flags imply: without `--agent`, skills route to every detected harness, not just the one you are thinking of.

Scoping skills to one editor and undoing the defaults change

Blanket installation is the default, and that is a design decision with consequences. If you have Claude Code, Cursor and Windsurf installed, one `firecrawl setup core` touches all of them. The README provides `--agent` for exactly this reason, with values including `claude-code`, `codex`, `cursor`, `windsurf`, `opencode`, `openclaw`, `openhands` and `hermes-agent`.

firecrawl setup skills --agent openclaw
firecrawl setup workflows --agent openclaw

There is also a one-shot path from the install script, where arguments after `bash -s --` are forwarded to `firecrawl init`:

curl -fsSL https://firecrawl.dev/install.sh | bash -s -- --agent openclaw

The README notes that `--skip-auth` can be added for a skills-only setup with no login. When run interactively without `--agent`, init shows a checkbox of detected harnesses with all of them selected, so the safe habit is to deselect rather than accept.

The defaults command is the one to be careful with. `firecrawl setup defaults` disables native web fetch and search in supported agents so that web work goes through Firecrawl. The README documents the reversal:

firecrawl setup defaults --undo --agent claude

That `--undo` flag is the reason this section exists. Any tool that edits another tool's configuration should document its own rollback, and this one does, harness by harness.

Self-hosted endpoints and the authentication skip

Firecrawl CLI is not locked to the hosted service. The README documents `--api-url` for self-hosted instances and local development, and describes a behaviour worth knowing before you debug a failed request: when the API URL is anything other than `https://api.firecrawl.dev`, authentication is skipped automatically, so a local instance needs no API key.

firecrawl --api-url http://localhost:3002 scrape https://example.com

The same value can be set through the environment:

FIRECRAWL_API_URL=http://localhost:3002 firecrawl scrape https://example.com

Self-hosted with a key works too, by passing both flags. The automatic skip is convenient and slightly surprising: if you point at a staging URL expecting a key check and get none, that is the documented behaviour rather than a misconfiguration. Whether the self-hosted server enforces its own authentication is outside what this repository describes.

Where Firecrawl CLI is the wrong tool

The dependency on a Firecrawl endpoint is the first limit. Nothing in the README suggests the CLI contains its own fetcher, parser or renderer. If the endpoint is unreachable or your key is invalid, the command fails; there is no offline mode described. For air-gapped work, or for scraping a site you would rather not send to a third party, this is the wrong layer.

The second limit is the setup surface. Skills install globally across detected editors by default, and `setup defaults` disables native web fetch and search in those editors. That is a lot of configuration changed by a command whose name suggests file copying. The README does document `--agent` and `--undo`, but the interactive picker selects everything unless you intervene.

Third, the repository's `package.json` currently reports version `1.23.4-alexandria-beta.2` with `publishConfig.tag` set to `alexandria`, while the recent releases listed are 1.23.0, 1.23.1 and 1.23.3. A prerelease version on the default branch under a non-default dist tag means what you get from a plain install and what the maintainers are currently building may not be the same thing. Check the resolved version rather than assuming.

Finally, the licence. The README does not state one, and the repository's `package.json` declares ISC. Those two sources disagree in the sense that only one of them speaks at all, and the repository metadata itself lists the licence as unknown. If licence terms matter to your organisation, read the actual licence file rather than the package field.

Firecrawl CLI versus the MCP server route

The obvious alternative for the same job is the Firecrawl MCP server, and the README treats it as a sibling rather than a rival: `firecrawl setup mcp` installs the MCP server into editors such as Cursor, Claude Code and VS Code.

The difference is where the capability lives. With MCP, the agent calls tools over a protocol and never sees a command line; the integration is a server the editor talks to. With the CLI, the agent runs `firecrawl` as a subprocess, and you can run the identical command yourself in a terminal. That matters for two reasons. Anything the agent does, you can reproduce and inspect by hand, which is useful when a scrape returns something unexpected. And anything you script in a shell, an agent can reuse without a separate integration.

The trade-off runs the other way too. A CLI subprocess needs the binary on PATH and a shell the agent can use; an MCP server only needs the editor's configuration. If your environment restricts subprocess execution, MCP is the cleaner fit. The README does not argue for one over the other, and `firecrawl setup defaults` works alongside both.

Editorial conclusion

Adopt Firecrawl CLI if you already pay for Firecrawl and want its scrape, crawl and search calls available both to your shell and to a coding agent, and if you are comfortable with the setup commands writing configuration into your editors. Skip it if you need a fully self-contained scraper, since every command here talks to a Firecrawl endpoint, or if you only need one scrape a week and can paste a URL into a browser. Before rolling it out, verify three things: that your key works against the endpoint you intend to use, that `firecrawl setup defaults --undo` restores the native web fetch and search settings you are about to disable, and which version npm resolves for you, because the repository's package.json currently carries a prerelease version under the alexandria tag rather than the 1.23.x releases.

Frequently asked questions

Official sources

1. firecrawl/cli on GitHub
2. Issues
3. Project website
4. README
5. Releases