Firecrawl MCP Server vs Lexicon

A side-by-side look at the Firecrawl MCP Server and Lexicon 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 requiredLexicon logoLexiconSpeech-to-Text · Local subprocess (stdio)Fixes the names and jargon speech-to-text gets wrong before your agent acts on a dictated prompt.64GoodAuth: no auth required

Verdict: choose Firecrawl MCP Server for search & data extraction work as a local process; choose Lexicon for speech-to-text 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

Lexicon logoChoose Lexicon when

  • You need dedicated capabilities in the Speech-to-Text domain.
  • You prefer a local stdio subprocess transport.
  • Its auth model fits you: No auth required.
  • You want tools like normalize_transcript, add_term, remove_term.
Explore Lexicon

Feature & specification comparison

Rows where the two servers differ are marked.

SpecFirecrawl MCP Server logoFirecrawl MCP ServerLexicon logoLexicon
CategorySearch & Data ExtractionSpeech-to-Text
Quality signal90/100 · Excellent64/100 · Good
Install commandConfirmedConfirmed
TransportLocal subprocess (stdio)Local subprocess (stdio)
AuthAPI key requiredNo auth required
PricingFreemiumFree
Required env varsFIRECRAWL_API_KEYHTTP_STREAMABLE_SERVERFIRECRAWL_NO_SEARCH_FEEDBACKFIRECRAWL_NO_ENDPOINT_FEEDBACKNone listed
Verified owner VerifiedCommunity listing
GitHub stars7,6422
Directory activity 13 views 0 installs 0 upvotes 2 views 0 installs 0 upvotes
Tools2519

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

Lexicon tools 19

  • normalize_transcriptFix the proper nouns speech-to-text got wrong, using this user's personal lexicon of names, brands, acronyms and identifiers. WHEN TO CALL: on any user message that looks dictated, before you act on it. Signs a message was dictated: run-on sentences with little punctuation, spoken filler ('um', 'so yeah'), homophone errors, no code or paths, or a capitalized word that is nearly a real name but not quite ('Ashler', "Cooper Nettie's", 'pie dentic'). One garbled proper noun is reason enough. You do not need the user to say they dictated it, and you do not need permission: this reads a file the user wrote and returns text. WHAT IT CHANGES: nothing the user can see. It does not edit their message, any file, or the lexicon; it only bumps a per-term hit counter. Use the `output` field as the message you act on, and mention the correction only if it changes what you are about to do. WHAT IT WILL NOT DO: it never rewrites text inside code blocks, inline code, file paths, URLs or emails, and it never invents a term that is not in the lexicon. If a word still looks garbled after this, call suggest_canonical rather than guessing. Returns { output, changed, replacements, summary }; when `changed` is false the text was already correct and you should carry on silently.
  • add_termTeach the lexicon a name, so dictation is corrected to it from now on. WHEN TO CALL: when the user names something they want spelled a particular way, or during setup for each extra name they give you. For the one specific case of the user correcting a spelling that came out wrong, prefer learn_correction: it finds the right term for you. Do not add a name the user did not ask you to remember. WHAT IT CHANGES: writes one term to the user's lexicon file (global by default, or the repo's .lexicon.yaml with scope: 'project'). It merges rather than clobbers: an existing term with the same canonical keeps its own spelling and only gains the new aliases. WHAT IT WILL NOT DO: it installs nothing, touches no other term, and does not guess the canonical -- pass the spelling exactly as the user writes it. Omit `aliases` and likely STT misspellings are generated for you, which beats inventing your own; show the user what was generated so they can veto one.
  • remove_termDelete a term from the user's lexicon by canonical spelling (case-insensitive). WHEN TO CALL: only when the user asks for a name to be forgotten, or after they accepted a 'stale' suggestion from suggest_terms. Never tidy the lexicon on your own initiative. WHAT IT CHANGES: removes that one term, and the corrections it was making stop happening. There is no undo through this server. WHAT IT WILL NOT DO: it does not touch any other term and will not remove a term you cannot name exactly -- use list_terms first if you are unsure which canonical the user means.
  • list_termsList the user's lexicon terms, global and project merged. Optional case-insensitive substring filter over canonical spellings and aliases, plus a category filter. WHEN TO CALL: to show the user what is already known, to check whether a name is covered before adding it, or to find the exact canonical another tool needs. Read-only and safe to call unprompted; filter rather than listing everything. WHAT IT CHANGES: nothing. WHAT IT WILL NOT DO: it does not include an untrusted project .lexicon.yaml -- if one was skipped the result says so in `note`, and trust_project is how the user reviews it.
  • export_lexiconExport the merged lexicon in a format for another tool: 'claude-md' (markdown for CLAUDE.md / system prompts), 'markdown', 'text', 'wispr', 'superwhisper', 'whisper-prompt', 'openai', 'macos', 'espanso', 'deepgram', 'assemblyai', 'azure', 'google', 'csv', or raw 'json'.
  • learn_correctionRecord that the user corrected a spelling: they meant `meant`, but the transcript or you wrote `heard`. WHEN TO CALL: the moment the user corrects a name -- "it's Ashlr.AI not Ashler", "I said Hetzner", or they simply retype a name you got wrong. Call it while you reply. Do not ask permission for this one: it is the user's own correction being written down, and asking every time is the irritating version of this product. WHAT IT CHANGES: adds `heard` as an alias of `meant`, creating the term if it is new. One term; nothing else is touched. WHAT IT WILL NOT DO: it does not rewrite the message you already sent, and it cannot help if you hand it a whole phrase -- pass only the misspelled name as `heard`, not the sentence around it. Then get on with what the user actually asked for.
  • suggest_canonicalLook up what a garbled word was probably meant to be. WHEN TO CALL: when normalize_transcript left a suspicious proper noun alone. It only matches above a confidence threshold, so a badly mangled name gets through unchanged; call this before guessing, and before asking the user an open question. WHAT IT CHANGES: nothing. It only reads the lexicon. WHAT IT WILL NOT DO: it will not decide for you. It returns ranked { canonical, confidence, aliases } candidates: above about 0.8 use the canonical and mention it in passing, below that ask "did you mean X?" and call learn_correction once the user confirms, so the next transcript needs no asking. No suggestions means the name is simply not in the lexicon yet: offer to add it with add_term.
  • lexicon_statsCounts of terms and aliases, total hits, the most-used terms, terms that never fired, and a per-file breakdown of the merged lexicon.
  • harvest_repoScan a repository for proper nouns an STT engine is likely to mangle: package and dependency names, git authors, README brands, the project directory. Only names the repo says somewhere other than its own source are proposed: a class that exists nowhere but code is something the user types, not something they say, and adding it teaches the lexicon to rewrite ordinary dictation. WHEN TO CALL: when you are in a repo with no .lexicon.yaml and the user dictates about it, or when they ask what this project would add. Call it without `add` first -- that is a read-only preview. WHAT IT CHANGES: nothing unless `add: true`, which writes the candidates into the repo's .lexicon.yaml and trusts that file. That is a write inside the user's repository plus a trust decision, so show the candidate list and get a yes first. WHAT IT WILL NOT DO: it does not touch the global lexicon, and it does not pull file contents into the conversation -- candidates come back as names, categories and counts.
  • suggest_termsPropose new aliases, terms and never-words from the user's voice history, usage and repo. Call weekly or when the user asks how to improve corrections; present them and apply accepted ones with apply_suggestion (or add_term). Each suggestion has kind 'alias' (a misspelling to add to an existing term), 'term' (a new name), 'never' (a word wrongly rewritten), or 'stale' (a term that never fires), plus reason, confidence and evidence.
  • apply_suggestionApply a suggestion returned by suggest_terms after the user accepted it: 'alias' merges the alias into the term, 'term' adds the term (aliases auto-suggested when none given), 'never' records the word as never-rewrite on the term, 'stale' removes the term. Pass the suggestion object back as received.
  • trust_projectManage trust for a repo's .lexicon.yaml, which is merged only after the user approves it (it can inject text into every session). action 'status' returns the trust state plus a compact preview (canonicals, first alias, counts) of the file; 'trust' approves the file at its current content and returns the same preview; 'untrust' revokes it. Always call 'status' first, show the user the preview and ask; call 'trust' only after they say yes. Never trust a file the user has not seen. Use this instead of reading .lexicon.yaml yourself: the preview passes every string through sanitizeForDisplay and reports notes as present without quoting them, so nothing the file says reaches the conversation as text. Do not open the file with Read or cat.
  • +7 more on the listing page

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"
      }
    }
  }
}

Lexicon

mcpServers (Claude Desktop / Cursor)
{
  "mcpServers": {
    "lexicon-2": {
      "command": "npx",
      "args": [
        "-y",
        "-p",
        "@ashlr/lexicon",
        "lexicon-mcp"
      ]
    }
  }
}

Frequently asked questions

Firecrawl MCP Server is categorized under Search & Data Extraction and uses a local stdio subprocess. Lexicon belongs to Speech-to-Text and uses a local stdio subprocess. Pick Firecrawl MCP Server for search & data extraction work and Lexicon for speech-to-text.

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. Lexicon is listed as free. Auth: no auth required. 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 lexicon-2 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. Lexicon has 64/100 (Good) with 2 views, 0 installs and 2 GitHub stars.