How do I add fastCRW to the Continue extension?

Add an MCP server entry to Continue's config that runs the crw-mcp@0.6.0 npm package (e.g. via npx -y crw-mcp@0.6.0) and passes your fastCRW base URL and API key as environment variables. It connects over the POST /mcp Streamable HTTP transport. After saving, reload Continue and confirm the scrape/crawl/map/search tools appear in its tool list. The same config works in both the VS Code and JetBrains extensions.

Does Continue support MCP servers for web access?

Yes. Continue acts as an MCP client and can register external MCP servers as tool providers for its chat and edit/agent modes. fastCRW's crw-mcp server exposes scrape, crawl, map, and search tools that Continue's model can call on its own during a session to read the live web.

Can Continue use fastCRW in both VS Code and JetBrains?

Yes. Continue shares one config across its VS Code and JetBrains extensions, so a single crw-mcp MCP block enables the same scrape/crawl/map/search tools in either editor. There is no separate fastCRW setup per IDE.

Can I self-host the fastCRW backend for Continue?

Yes. fastCRW's engine is a single static Rust binary (roughly an 8 MB image, one container) licensed AGPL-3.0, so self-hosting is free — you pay only for your own server, with no per-call metering. Point Continue's crw-mcp config at your local host instead of the managed cloud; the tool surface and request shape are identical, so you can switch between local and managed by changing one environment variable.

Continue VS Code + fastCRW: Live Web Context via MCP

By the fastCRW team · Credit costs and footprint verified 2026-05-18 · fastCRW launch pricing expires 2026-06-01 · Verify independently before relying on any figure.

Disclosure: we build fastCRW. This is a setup guide for pairing it with Continue, written by the vendor — so weight the recommendation accordingly, and note the "What fastCRW does not do here" section, which states the real gaps plainly.

Continue VS Code + fastCRW: live web context for chat and edits

Continue is the open-source AI code assistant for VS Code and JetBrains. Out of the box its chat and edit modes reason over your repo, your open files, and whatever its model already knows — which means it cannot see a changelog published this morning, a library's current API reference, or a Stack Overflow thread about an error you are staring at right now. Continue VS Code + fastCRW closes that gap over MCP: you add the crw-mcp@0.6.0 server, and Continue's chat and edit/agent modes can scrape, crawl, search, and map the live web during a session. Because both projects are open — Continue is open source, fastCRW is open-core under AGPL-3.0 — the whole path can run on your own infrastructure with no metered cloud in the loop.

Context providers and MCP in Continue

Continue already ships context providers (@docs, @url, @codebase) for pulling in reference material. MCP is the more general plug point: an MCP server exposes a set of tools that Continue's model can call on its own during chat and edit/agent runs, rather than you manually pasting URLs. fastCRW's MCP server registers as exactly that kind of tool provider.

What live web access adds to chat and edits

With the server connected, you can ask Continue to "read the current Stripe webhooks docs and update this handler," and the model fetches the page itself, gets clean markdown back, and edits with the real, current API in context — instead of guessing from stale training data. That is the difference between an assistant that hallucinates a deprecated method and one that quotes the page you are actually targeting.

Adding crw-mcp to Continue

fastCRW's MCP package is published to npm as crw-mcp@0.6.0 (dist-tag latest). It speaks the Model Context Protocol over the POST /mcp Streamable HTTP transport, which Continue supports as an MCP client.

Editing Continue's config (VS Code / JetBrains)

Continue is configured through its YAML/JSON config file, and the config is shared across both the VS Code and JetBrains extensions — so a single MCP block works in either editor. Add an MCP server entry that runs the crw-mcp package and passes your fastCRW endpoint plus API key as environment variables:

command: npx with args ["-y", "crw-mcp@0.6.0"] so you pin the published latest build.
env: your base URL (managed https://api.fastcrw.com or your self-hosted host) and the API key the server should authenticate with.

After saving, reload Continue and confirm the scrape/crawl/map/search tools appear in its tool list. The exact key names follow Continue's current MCP config schema — check its docs, because that schema evolves faster than this post.

Managed fastcrw.com vs self-hosted binary

You point the server at one of two backends. The managed cloud at fastcrw.com needs only an API key and meters per operation in credits. The self-hosted option is a single static Rust binary — roughly an 8 MB image in one container (per the README structural footprint) — that you run on your own box; Continue then talks to http://localhost:PORT. The tool surface and request shape are identical either way, so you can develop against a local binary and flip to managed (or vice versa) by changing one env var.

Connecting over /mcp Streamable HTTP

fastCRW exposes the MCP transport at POST /mcp (Streamable HTTP). The crw-mcp npm package wraps that endpoint so Continue's MCP client sees standard tool definitions. Because the underlying REST surface is Firecrawl-compatible — drop-in after a base-URL swap — anything you have wired for a Firecrawl MCP setup maps over with minimal change. See the MCP web-scraping server roundup for how the options compare.

Pulling live web context into a session

Once the tools are registered, you invoke them by describing the task in chat — Continue's model decides when to call scrape, search, crawl, or map.

Scrape a changelog or docs page as markdown

Ask Continue to read a specific URL and it calls scrape against /v1/scrape, returning clean markdown (the same extraction path that scores highest of the three tools tested on truth-recall — see below). A single page scrape costs 1 credit regardless of which renderer is used — http, lightpanda, or chrome for JavaScript-heavy pages.

Search the web from a Continue chat

For "find the current way to do X," the model calls search, which runs a web search (1 credit per query) and can optionally scrape the top results. That is how you get Continue to ground an answer in a live thread rather than its training cutoff.

Crawl a reference site for broader context

When you want a whole docs section rather than one page, crawl kicks off an async BFS crawl against /v1/crawl (1 credit per page, flat regardless of renderer), and map can enumerate a site's URLs first (1 credit). Mind the crawl caps — maxDepth tops out at 10 and maxPages at 1000.

Cost, footprint, and self-hosting

Per-operation credit costs

Metering is flat and predictable per the fact sheet: scrape 1 credit (any renderer — no chrome surcharge), search 1 per query, crawl 1 per page, map 1, and any request asking for formats: ["json"] (LLM/JSON extraction) is the 1-credit scrape plus the LLM token cost, billed as usage-metered LLM credits. There is no separate per-page JS multiplier — useful when a Continue session fires several tool calls in a row. For current plan allotments, link out to the live pricing page rather than trusting a number cached in a blog post.

Single ~8 MB binary you can run locally

The self-hosted engine is one statically-linked Rust binary in a single container (~8 MB image), versus a multi-service stack measured at ~2–3 GB across five containers in the README footprint table. That is small enough to run on the same laptop as your editor, so Continue's web backend can live entirely on your machine.

Free self-host under AGPL-3.0

Because the engine is AGPL-3.0, self-hosting is free — you pay only for your own server, with no per-call bill. For a developer who wants Continue to read the web during local work without metering, that is the cheapest path. The managed cloud exists for when you would rather not run the binary yourself. Either way you stay on a Firecrawl-compatible surface, so you are not locked in. See the web context layer for AI agents for the broader pattern.

What fastCRW does not do here

MCP feeds chat and edit/agent modes, not tab-autocomplete

This is the most common misconception, so it is worth stating clearly: the crw-mcp tools feed Continue's chat and edit/agent features. Continue's tab-autocomplete runs on a local completion model optimized for sub-keystroke latency and does not call MCP tools mid-keystroke. If you were hoping fastCRW would pull live docs into autocomplete suggestions, it will not — that is not how Continue's autocomplete is wired, by either project's design.

No autonomous agent endpoint, no screenshots, stateless requests

Other honest gaps, straight from the fact sheet: fastCRW has no /v1/agent (Spark-style autonomous research) endpoint and no /v1/deep-research; a request for formats: ["screenshot"] returns HTTP 422 (no screenshot output); there is no Fire-engine-grade anti-bot for hostile targets; and every request is stateless — there is no persistent browser session across tool calls. LLM-based JSON extraction is limited to OpenAI and Anthropic providers (the managed /v1/search answer mode uses a managed LLM). Plan around these rather than discovering them mid-task.

Where Firecrawl genuinely wins

If your Continue workflow leans on cloud-only capabilities — heavy anti-bot fire-engine paths for protected targets, batched multi-URL /v1/extract, an autonomous agent endpoint, or deep-research synthesis — Firecrawl's managed cloud offers those today and fastCRW does not. Firecrawl also has the larger ecosystem and more community MCP examples. fastCRW's edge is the open, self-hostable footprint and flat metering, not feature breadth. Pick on which of those matters for your project.

Why the extraction quality matters

The reason clean markdown is worth caring about: on Firecrawl's own public scrape-content dataset, fastCRW recovered the most labeled ground truth of the three tools tested — 63.74% truth-recall of 819 labeled URLs (diagnose_3way.py, 2026-05-08), ahead of Crawl4AI (59.95%) and Firecrawl (56.04%), with ~92% scrape success of reachable URLs and 0 thrown errors. Latency context: in fast mode fastCRW's p90 is 4348 ms — the lowest of the three (Crawl4AI 4754 ms, Firecrawl 6937 ms) — and its median (p50 1914 ms) beats Firecrawl's 2305 ms. For an interactive Continue session the cleaner extraction and comfortable tail latency both work in your favor.

Sources

fastCRW MCP package: crw-mcp@0.6.0 on npm.
fastCRW repo and managed cloud: github.com/us/crw · fastcrw.com.
Continue extension docs: docs.continue.dev (verify the current MCP config schema there).