Firecrawl MCP Server vs Remotify MCP

A side-by-side look at the Firecrawl MCP Server and Remotify MCP MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.

Firecrawl MCP Server logoFirecrawl MCP ServerSearch & Data Extraction · Local subprocess (stdio)Official Firecrawl server to search the web and scrape, crawl, map, and extract structured data from any site for LLMs. Handles JS-rendered pages, PDFs, and batch jobs; hosted remote MCP with OAuth or self-host.90ExcellentAuth: api key requiredRemotify MCP logoRemotify MCPCommand Line · Local subprocess (stdio)Run approved shell commands on remote computers through AI assistants. The remote machine needs only curl and bash, with no SSH access or installed agent.65GreatAuth: not declared

Verdict: choose Firecrawl MCP Server for search & data extraction work as a local process; choose Remotify MCP for command line as a local process. You can also run both side by side in one mcpServers block.

Which MCP server should you choose?

Firecrawl MCP Server logoChoose Firecrawl MCP Server when

  • You need dedicated capabilities in the Search & Data Extraction domain.
  • You prefer a local stdio subprocess transport.
  • Its auth model fits you: API key required.
  • You have the keys it needs: FIRECRAWL_API_KEY, HTTP_STREAMABLE_SERVER, FIRECRAWL_NO_SEARCH_FEEDBACK, FIRECRAWL_NO_ENDPOINT_FEEDBACK.
  • You want tools like firecrawl_scrape, firecrawl_map, firecrawl_search.
Explore Firecrawl MCP Server

Remotify MCP logoChoose Remotify MCP when

  • You need dedicated capabilities in the Command Line domain.
  • You prefer a local stdio subprocess transport.
  • You have the keys it needs: DOMAIN, SCHEME, PUBLIC_PORT, NGINX_MODE, SESSION_TTL, LONGPOLL_MS, MAX_BODY_SIZE, CERTBOT_EMAIL.
  • You want tools like remote_exec, remote_session_info, remote_session_reset.
Explore Remotify MCP

Feature & specification comparison

Rows where the two servers differ are marked.

SpecFirecrawl MCP Server logoFirecrawl MCP ServerRemotify MCP logoRemotify MCP
CategorySearch & Data ExtractionCommand Line
Quality signal90/100 · Excellent65/100 · Great
Install commandConfirmedConfirmed
TransportLocal subprocess (stdio)Local subprocess (stdio)
AuthAPI key requiredNot declared
PricingFreemiumFree
Required env varsFIRECRAWL_API_KEYHTTP_STREAMABLE_SERVERFIRECRAWL_NO_SEARCH_FEEDBACKFIRECRAWL_NO_ENDPOINT_FEEDBACKDOMAINSCHEMEPUBLIC_PORTNGINX_MODESESSION_TTLLONGPOLL_MSMAX_BODY_SIZECERTBOT_EMAIL
Verified owner VerifiedCommunity listing
GitHub stars7,6423
Directory activity 13 views 0 installs 0 upvotes 4 views 0 installs 0 upvotes
Tools253

Tools & capabilities

Firecrawl MCP Server tools 25

  • firecrawl_scrape Retrieve and extract content from one supplied URL through Firecrawl. Use this when the request identifies a page and needs its content or defined fields. It can return markdown, HTML, links, screenshots, branding data, a targeted answer, or JSON matching a supplied schema; JSON is useful when the requested result has defined fields, while markdown preserves readable page content. This tool operates on a known page. For a set of pages use `firecrawl_crawl`, and to discover page URLs use `firecrawl_map` or `firecrawl_search`. Options include JavaScript render delay, cache age, main-content filtering, PII redaction, and lockdown cache-only retrieval. Browser actions may change the live page when interactive actions are enabled. Firecrawl may reuse recently indexed content instead of refetching the page, and the reuse window varies by domain. Set `maxAge: 0` to force a live fetch, or a smaller `maxAge` to bound how stale reused content may be. A successful response does not by itself confirm that the state it describes is still current. Returns the selected content formats and page metadata.
  • firecrawl_map Enumerate URLs indexed under one website through Firecrawl without fetching each page's content. Use this when the request asks for a site's URL inventory, when several relevant pages must be located, or when the desired page URL is unknown. An optional `search` term narrows the URL list, while sitemap, subdomain, query-parameter, and result-limit options control coverage. Returns matching URLs rather than page bodies. Retrieve one page with `firecrawl_scrape`; collect content across multiple pages with `firecrawl_crawl`.
  • firecrawl_search Search web, news, or image sources and return ranked results. Operators include quoted phrases, `-term`, `site:host`, `inurl:term`, `intitle:term`, and `related:host`; the set is non-exhaustive. `includeDomains` and `excludeDomains` are mutually exclusive hostname filters; categories limit results to GitHub, research, PDF, or developer sources. For a programming question, add `categories: ["developer"]`. It searches an index of GitHub issues, merged pull requests, repository READMEs, and curated documentation sites, and returns the hits in `data.developer` beside the web results. `categories: ["research"]` restricts these web results to research-affiliated websites and returns page snippets. The `firecrawl_research_*` tools are a separate surface that searches paper abstracts and full text across biomedical (PubMed, bioRxiv, medRxiv) and arXiv literature. `scrapeOptions` can attach extracted page content; pages fetched this way use a fixed reuse window and ignore `maxAge`, so use `firecrawl_scrape` when a live fetch is required. Returns source-type result groups and usage metadata. Authenticated responses can include an `id` for optional search feedback.
  • firecrawl_crawl Start a multi-page crawl at a website URL, poll it to a terminal state, and return the final status and collected data. Scope can be bounded with include/exclude paths, depth, page limit, subdomain/external-link controls, sitemap handling, delay, and scrape options. Crawl results can be large; use conservative limits when full-site coverage is unnecessary. Webhooks and interactive scrape actions are unavailable in safe mode. Returns the crawl ID, status, and page data.
  • firecrawl_check_crawl_status Retrieve the current status, progress, and available results for an existing crawl ID. This only reads Firecrawl job state and does not start or modify the crawl.
  • firecrawl_extract Deprecated compatibility entry point. Use firecrawl_scrape once per known URL with formats: ["json"] and jsonOptions containing the prompt and schema. Use firecrawl_search or firecrawl_agent before Scrape when URLs are not known.
  • firecrawl_agent Start an asynchronous web research job from a prompt, optional seed URLs, and an optional JSON schema. Use this for a requested synthesis across multiple sources when the task can wait for asynchronous completion. The agent can search, navigate, read pages, and assemble a structured result. This call returns only a job ID, not the research result. Read the job with `firecrawl_agent_status` until it reaches `completed` or `failed`; research commonly takes several minutes. If the job cannot finish within the task's available time, `firecrawl_search` and `firecrawl_scrape` can gather evidence synchronously.
  • firecrawl_agent_status Retrieve progress or final results for a `firecrawl_agent` job ID. A `processing` response is non-terminal and does not contain the final research result. Check again after 15–30 seconds until the status is `completed` or `failed`; complex jobs can take several minutes. If the job cannot finish within the task's available time, use `firecrawl_search` and `firecrawl_scrape` to complete the requested output. Returns job status, progress information, and result data when completed.
  • firecrawl_interact Open or reuse a live browser session to navigate a page, click controls, fill fields, or run browser code. Provide either `url` or `scrapeId`, and either a natural-language `prompt` or executable `code`; code can run as Bash, Python, or Node with a bounded timeout. This acts on the live site, so actions such as form submission can create persistent external side effects. Returns execution output, stdout/stderr, exit status, and session viewing URLs.
  • firecrawl_interact_stop Stop the live interact session associated with a `scrapeId` and release its resources. Returns a success confirmation.
  • firecrawl_parse Parse one supported document into markdown, HTML, links, summary, targeted answers, or JSON matching a schema. Supported inputs include common HTML, PDF, Word, RTF, OpenDocument, and spreadsheet files; PDF parsing can be bounded with `pdfOptions.maxPages`. Local MCP reads `filePath` from the server filesystem. Hosted MCP uses two calls: first provide `filePath` to receive upload instructions, upload locally, then call again with the returned `uploadRef`; do not send both fields together. Remote web URLs belong in `firecrawl_scrape`. Set `redactPII` to request redaction of personally identifiable information in the returned content. `zeroDataRetention` requires an eligible authenticated account; omit it for anonymous keyless use. Returns upload instructions for hosted phase one or parsed document content for the final call.
  • firecrawl_monitor_create 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.
  • +13 more on the listing page

Remotify MCP tools 3

  • remote_execExecute a shell command on the PROJECT'S REMOTE SERVER via the remotify relay (the deployed/production/staging box, NOT the developer's local machine). Examples: 'check disk usage', 'restart the service', 'tail the app log', 'query the prod DB', 'is port 443 open in prod', 'what version is running in staging'. Chain this tool freely for iterative work - log analysis with grep/awk/sed/head/tail, narrowing a search, cross-checking outputs, diagnosing slow services with ps/vmstat/netstat/iostat. Each call saves a manual copy-paste roundtrip; only surface the meaningful result or synthesis to the user. In supervised mode the operator approves each command on the remote via y/N prompt, so no extra confirmation is needed from the assistant. Returns combined stdout+stderr as plain text on success. HARD RULE: the user connects the remote by pasting a listener one-liner; that is the ONLY execution path. NEVER fall back to ssh, scp, or any other transport, and NEVER try to start the listener yourself. The user chose remotify precisely so that no agent gets shell access. Pending handling: the response text may start with one of these markers. '[pending]' WITH paste one-liners = no remote listener is connected; nothing can run until the user pastes one. STOP: end your turn immediately with a short message that shows BOTH one-liners (supervised and auto) verbatim in a fenced code block. Do not call any tool after that message: hosts collapse text written between tool calls, so the one-liners only reach the user as the final message of the turn. The command stays queued; when the user replies that the listener is running, call remote_exec again with the EXACT SAME arguments to collect the output. It will not execute twice. '[pending]' WITHOUT one-liners = the listener is online but the relay cannot confirm pickup yet. Call remote_exec again with the EXACT SAME arguments; loop silently, do not ask the user anything, and give up only after about 10 consecutive [pending] responses. '[in-flight]' = the command IS already being executed on the remote (cmd was picked up, no output yet). In that case: 1. Do NOT give up. Long operations (mongodump, restic, rsync, big installs, slow restarts) routinely take many minutes. 2. Call remote_exec again with the EXACT SAME arguments; the relay will return the output the moment the command finishes. 3. Do NOT tell the user the listener disconnected; do NOT ask them to re-paste the listener; do NOT switch to a different command. 4. There is no LLM-side retry cap on '[in-flight]'; keep waiting until the result lands or the relay returns something else. '[busy]' = you tried to issue a NEW command while a previous one is still executing on the remote. Each session is single-flight (one command at a time). In that case: 1. If you know the previous command, call remote_exec with ITS exact arguments first to drain its result, then issue the new one. 2. If you do NOT know it (e.g. it was issued by an earlier session), keep calling remote_exec with the NEW command's arguments: stale state left by a dead session is cleared automatically (see '[recovered]'). 3. If the [busy] response contains paste one-liners, the listener is disconnected and the wedge can ONLY clear once the user reconnects it: end your turn with BOTH one-liners verbatim, exactly as for a no-listener [pending]. '[recovered]' = wedged state left by a dead session/listener was cleared automatically. Read the rest of the message: either the command already proceeded, or you are asked to call remote_exec again with the EXACT SAME arguments. '[resumed]' = the returned output was already waiting on the relay and belongs to the most recent run (e.g. you re-issued a command after an interruption). Use it if it matches what you expected; if not, issue the command again. '[unknown-result]' = the session expired while the command was already running on the remote. Its output was lost and it may or may not have completed. A new session was minted; end your turn with BOTH reconnect one-liners verbatim, then decide whether re-running is safe once the user is back. The server will NOT silently re-run it. '[session-renewed]' = the session key changed; the one-liners that follow are for the NEW key. Treat it like a no-listener [pending]: end your turn with both lines verbatim.
  • remote_session_infoReturn the current relay session: key, URLs, and the exact one-liners to paste on the remote machine to start the listener (remote_quickstart = supervised, y/N per command; remote_quickstart_auto = unattended). When you show them to the user, show BOTH verbatim in a fenced code block and make them the final message of your turn.
  • remote_session_resetRecover a wedged remotify session. Default (no arguments): clear stuck relay state in place - drops any queued command/result and the in-flight marker; the session key and a connected listener keep working. With {"rotate": true}: abandon the current session and mint a brand-new key - the old key dies, the remote listener disconnects, and the user must paste the NEW runner one-liner (returned by this tool) on the remote. Normally NOT needed: remote_exec auto-recovers from stale state by itself. Use it only when remote_exec stays wedged (repeated [busy] for a command you never issued) despite same-args retries, or when the user explicitly asks to reset or rotate the session.

Ready-to-paste client configs

Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.

Firecrawl MCP Server

mcpServers (Claude Desktop / Cursor)
{
  "mcpServers": {
    "firecrawl-firecrawl-mcp-server": {
      "command": "npx",
      "args": [
        "-y",
        "firecrawl-mcp"
      ],
      "env": {
        "FIRECRAWL_API_KEY": "YOUR_FIRECRAWL_API_KEY_HERE",
        "HTTP_STREAMABLE_SERVER": "YOUR_HTTP_STREAMABLE_SERVER_HERE",
        "FIRECRAWL_NO_SEARCH_FEEDBACK": "YOUR_FIRECRAWL_NO_SEARCH_FEEDBACK_HERE",
        "FIRECRAWL_NO_ENDPOINT_FEEDBACK": "YOUR_FIRECRAWL_NO_ENDPOINT_FEEDBACK_HERE"
      }
    }
  }
}

Remotify MCP

mcpServers (Claude Desktop / Cursor)
{
  "mcpServers": {
    "remotify-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "remotify-mcp@latest"
      ],
      "env": {
        "DOMAIN": "YOUR_DOMAIN_HERE",
        "SCHEME": "YOUR_SCHEME_HERE",
        "PUBLIC_PORT": "YOUR_PUBLIC_PORT_HERE",
        "NGINX_MODE": "YOUR_NGINX_MODE_HERE",
        "SESSION_TTL": "YOUR_SESSION_TTL_HERE",
        "LONGPOLL_MS": "YOUR_LONGPOLL_MS_HERE",
        "MAX_BODY_SIZE": "YOUR_MAX_BODY_SIZE_HERE",
        "CERTBOT_EMAIL": "YOUR_CERTBOT_EMAIL_HERE"
      }
    }
  }
}

Frequently asked questions

Firecrawl MCP Server is categorized under Search & Data Extraction and uses a local stdio subprocess. Remotify MCP belongs to Command Line and uses a local stdio subprocess. Pick Firecrawl MCP Server for search & data extraction work and Remotify MCP for command line.

Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.

Firecrawl MCP Server is listed as freemium — a free tier with paid plans. Auth: api key required. Remotify MCP is listed as free. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.

Yes. MCP clients support multiple servers: add firecrawl-firecrawl-mcp-server and remotify-mcp as separate keys in the same mcpServers object, and your assistant will call tools from either one.

On AllMCPs, Firecrawl MCP Server has a quality signal of 90/100 (Excellent) with 13 views, 0 installs and 7,642 GitHub stars. Remotify MCP has 65/100 (Great) with 4 views, 0 installs and 3 GitHub stars.