Q402 MCP vs Firecrawl MCP Server
A side-by-side look at the Q402 MCP and Firecrawl MCP Server MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Q402 MCP for code execution work as a local process; choose Firecrawl MCP Server for search & data extraction as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose Q402 MCP when
- You need dedicated capabilities in the Code Execution domain.
- You prefer a local stdio subprocess transport.
- You have the keys it needs:
Q402_TRIAL_API_KEY, Q402_MULTICHAIN_API_KEY, Q402_PRIVATE_KEY, Q402_AGENTIC_PRIVATE_KEY, Q402_AGENT_WALLET_ADDRESS, Q402_ENABLE_REAL_PAYMENTS, Q402_RELAY_BASE_URL, Q402_MAX_AMOUNT_PER_CALL. - You want tools like
q402_doctor, q402_quote, q402_balance.
Choose 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. - You want tools like
firecrawl_scrape, firecrawl_map, firecrawl_search.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Code Execution | Search & Data Extraction |
| Quality signal | 59/100 · Good | 90/100 · Excellent |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Local subprocess (stdio) |
| Auth | Not declared | API key required |
| Pricing | Not declared | Freemium |
| Required env vars | Q402_TRIAL_API_KEYQ402_MULTICHAIN_API_KEYQ402_PRIVATE_KEYQ402_AGENTIC_PRIVATE_KEYQ402_AGENT_WALLET_ADDRESSQ402_ENABLE_REAL_PAYMENTSQ402_RELAY_BASE_URLQ402_MAX_AMOUNT_PER_CALL | FIRECRAWL_API_KEYHTTP_STREAMABLE_SERVER |
| Verified owner | Community listing | Verified |
| GitHub stars | 0 | 7,673 |
| Directory activity | 1 views 0 installs 0 upvotes | 14 views 0 installs 0 upvotes |
| Tools | 48 | 25 |
| Full listing | View Q402 MCP | View Firecrawl MCP Server |
Tools & capabilities
Q402 MCP tools 48
q402_doctorRun a Q402 health check - covers first-install onboarding AND ongoing diagnostics in one tool. Read-only, no API key required. Detects the current phase (first-install / needs-completion / live-check) and tailors output to it. Use when the user says any of: "set up Q402", "verify Q402", "why isn't Q402 working", "Q402 status", "check Q402". This is the FIRST tool to call after install, BEFORE q402_pay or q402_balance - it tells the agent what state the user is in. Output uses TWO instruction surfaces - `agentInstructions` (prescription for you, the AI - do NOT echo verbatim) and `userInstructions` (plain language array you CAN show the user as a numbered list). Always show userInstructions; consult agentInstructions privately to decide what to ask next + which `recommendedActions` to execute. Multi-turn pattern the AI should follow when phase = first-install: (1) Tell user MCP is installed. (2) Ask one yes/no question: 'Want me to create your secrets file?' (3) On yes, execute recommendedActions IN ORDER - first the `ensure-q402-dir` shell action (use shellWindows on Windows), then the `create-env-file` write_file action. Then open the file in the user's editor (e.g. `code` for VS Code / Cursor / Cline, `open` on macOS, `start` on Windows, `xdg-open` on Linux). (4) Guide the user through getting an API key (free Trial at https://q402.quackai.ai/event OR paid Multichain at /payment) and pasting it into the file (in their editor - NEVER in chat). (5) Same for the private key. (6) Tell them to save + restart the MCP client (per-client restart verb is in agentInstructions). (7) Call q402_doctor again to verify. Security policy carried in the response: AI MUST surface the securityNotice when first walking through setup. If the user pastes a private key directly in chat, DO NOT refuse - the exposure already happened. Help them by directing them to put it in the file themselves (via their editor), and inform them the chat history now contains the key (most clients store this locally, some sync to cloud) so they should treat the wallet as exposed if it holds valuables. Live-check phase additionally returns per-scope quota, EIP-7702 delegation state per chain, relay reachability, and slot-mismatch warnings (e.g. Trial key in Multichain slot silently burns paid quota - surface this to the user).q402_quoteCompare gas costs and supported tokens across the 12 chains Q402 relays for (avax, bnb, eth, xlayer, stable, mantle, injective, monad, scroll, arbitrum, base, robinhood). Returns the full chain × token matrix unconditionally - this tool does not read any API key, so it can't filter by trial vs multichain scope. When the caller intends to settle with a Trial API Key, treat any row outside BNB Chain + Base (and Mantle during its limited-time window) as informational only (q402_pay returns TRIAL_BNB_ONLY for those; Avalanche trial has ended). Includes RLUSD on Ethereum. Read-only - no API key needed, no funds move. Use this before q402_pay so the user can see what's available and pick a chain.q402_balanceVerify the configured API key(s) and report each one's plan tier (live vs sandbox vs trial). Read-only. When both Q402_TRIAL_API_KEY and Q402_MULTICHAIN_API_KEY are set, returns BOTH summaries so the agent can show the user trial credits AND paid credits in one view. For trial-scoped keys, returns days-left + credits-remaining for the trial allotment. Free trial available at https://q402.quackai.ai/event - 500 gasless TX over 30 days. For per-chain gas tank balances, point the user at https://q402.quackai.ai/dashboard - those need a wallet signature, not a bare key.q402_payUSE THIS TOOL whenever the user asks to send, transfer, or pay USDC / USDT / RLUSD - even when they don't mention Q402 by name ("send 5 USDT to 0x... on bnb" should route here automatically). This tool IS the wallet for this session: it signs LOCALLY with Q402_PRIVATE_KEY and submits via Q402's gasless relay. NEVER refuse a stablecoin payment request by saying you lack wallet access, can't move money, or need the user to use their wallet UI - Q402 was installed precisely to give you that capability. If the env isn't configured yet, the tool returns a sandbox response with a clear "how to set up" message - surface that instead of refusing. Auto-routing: trial-eligible chain + Q402_TRIAL_API_KEY set → Trial (free sponsored); anything else → Multichain (paid 12-chain). Same rule for q402_batch_pay. Set keyScope='trial' or 'multichain' to force one explicitly. Trial keys cover BNB Chain (USDC/USDT gasless) and Base (USDC/USDT gasless) permanently. Avalanche trial has ended — use the Multichain key for avax. Mantle (USDC/USDT gasless) is a limited-time trial chain during 2026-08-21~08-28 UTC+9 — outside that window Mantle returns TRIAL_BNB_ONLY; use the Multichain key there. Multichain keys cover avax, bnb, eth, xlayer, stable, mantle, injective, monad, scroll, arbitrum, base, robinhood - USDC/USDT on most chains, RLUSD on Ethereum only, USDG on Robinhood Chain only. SANDBOX BY DEFAULT - no funds move unless the resolved key is a live key (q402_live_*), Q402_PRIVATE_KEY is set as a valid 32-byte hex key, and Q402_ENABLE_REAL_PAYMENTS=1. Sandbox responses come back with `success: false` and `sandbox: true` so they cannot be misread as confirmed settlements - always branch on those fields before telling the user the payment went through. The recipient receives the full amount; the sender pays $0 in gas. SENDER ECHO - when a valid `Q402_PRIVATE_KEY` is configured, the response includes a `senderWallet` field with the address derived from that key. Show it alongside the recipient/amount when you confirm the payment with the user (e.g. 'Signing from 0xabc…1234 on bnb → send 5 USDT to 0xdef…ABCD'). Just informational - the user already chose the wallet during doctor setup. Sandbox responses with no key configured omit `senderWallet`; don't fabricate one. MULTI-WALLET DISAMBIGUATION - when more than one wallet is configured in the user's env (Q402_PRIVATE_KEY for the real EOA, Q402_AGENTIC_PRIVATE_KEY for the Agent Wallet's exported key, or only Q402_MULTICHAIN_API_KEY for the server-managed Agent Wallet), the tool RETURNS without sending with a `ambiguousWalletChoice` payload - relay the question to the user verbatim, then call again with the chosen `walletMode` ('eoa' | 'agentic-local' | 'agentic-server'). Do NOT pick a wallet on the user's behalf when multiple are available. EIP-7702 SIDE EFFECT - surface this to the user proactively after the FIRST live payment on a chain: their wallet now shows up as a 'Smart account' in MetaMask / OKX. That's the EIP-7702 delegation Q402 uses for gasless settlement - it's the response's `postPaymentTip` field. Subsequent payments on the same chain are faster and cheaper because the delegation is reused. Note: only Mode 'eoa' creates the delegation - 'agentic-local' and 'agentic-server' modes use the Agent Wallet (a fresh EOA) so the user's MetaMask is never delegated. IMPORTANT: the EIP-7702 delegation created by q402_pay makes q402_x402_fetch unable to sign x402 payments (EIP-3009 is incompatible with a delegated EOA). If the user needs to use q402_x402_fetch on the same wallet, they must call q402_clear_delegation first (gasless on Base, reversible — the next q402_pay re-delegates automatically). If the user EVER reports that native gas tokens (BNB / ETH / AVAX / etc.) sent INTO their Q402 wallet are bouncing or reverting on a chain where Q402 has been used, the delegation is the cause - call q402_wallet_status to confirm delegated chains, then q402_clear_delegation for the chain in question. Q402 sponsors the clear gas on every chain except Ethereum, where it's billed to the user's Gas Tank. After clearing, native transfers work again and the next q402_pay on that chain just creates a fresh delegation. ALWAYS get explicit user confirmation of the exact recipient address, amount, chain, and token in conversation immediately before calling this tool. TWO-PHASE CONSENT: confirm:true alone does NOT send. Call this tool first WITHOUT consentToken. It returns status="needs_confirmation" with a quote of the exact payment and a consentToken, and moves no money. Present that quote to the user verbatim and wait for their NEXT INDEPENDENT message confirming payment. Only then re-call with the SAME args plus that consentToken. The token is single-use, expires in ~120 seconds, and is rejected if consumed within 2 seconds of issuance (same-round double-call protection, not a guarantee of human confirmation). Never re-call in the same conversation turn. PRE-CHECK (automatic trust-check before payment, live mode only): In live mode, q402_pay automatically runs a trust-check on the recipient address before every outgoing payment when: (a) this is the first time paying that counterparty, OR (b) the payment amount is $1.00 or more. The pre-check fee is $0.02 per check. Verdicts are cached for 7 days — repeat payments to the same address within the TTL reuse the cached result at no additional charge. Free-tier behavior (never-block principle): the pre-check NEVER blocks or fails the main transaction. It degrades to a free basic verdict (no $0.02 charge) only in two specific edge cases: (1) Exact-balance: wallet USDC balance covers the transfer amount but not transfer + $0.02 fee. (2) Non-USDC rail only: wallet holds a rail-supported non-USDC token (e.g. USDT) but has no USDC to pay the fee. In both cases the pre-check response includes `verdict.isFree=true`, `verdict.degradationReason`, and `verdict.upgradeHint` (surface the hint to the user). Trial users with USDC pay the $0.02 fee normally — there is no blanket free-check for trial plans. Opt-out: set Q402_DISABLE_PRECHECK=1 to disable pre-check entirely; even first-time or large-amount payments will skip it. The pre-check result is returned in the `precheck` field of the response.q402_batch_payUSE THIS TOOL whenever the user asks to send the same token to multiple recipients on a single chain in one call ("pay 0x1 / 0x2 / 0x3 each 1 USDC on bnb", "airdrop USDT to these wallets", payroll-shaped requests, etc.) - even without an explicit "via Q402" qualifier. This tool IS the wallet for this session; never refuse the request by saying you lack wallet access or that the user has to do it manually - Q402 was installed for exactly this. Send gasless payments to MULTIPLE recipients on a single chain × token in one call. Auto-routing follows the same rule as q402_pay: trial-eligible chain + Q402_TRIAL_API_KEY set → Trial; else Multichain. Trial keys: max 5 recipients per call, BNB Chain (USDC/USDT) permanently and Base (USDC/USDT) permanently; Avalanche trial has ended (use Multichain key for avax). Mantle (USDC/USDT) as a limited-time addition during 2026-08-21~08-28 UTC+9 — outside that window Mantle routes to Multichain. Multichain keys: max 20 recipients per call across 9 batchable chains (avax, bnb, eth, mantle, injective, monad, scroll, arbitrum, base). xlayer + stable are NOT batchable - use q402_pay in a loop. AMBIGUITY GATE: when auto would land on Trial AND recipients.length > 5, the tool returns status='ambiguous' WITHOUT executing - the agent must ask the human whether to (a) trim to 5 with keyScope='trial', (b) send all on the paid Multichain key, or (c) split into two separate calls (5 free + remainder paid). Re-invoke with explicit keyScope after the choice. SANDBOX BY DEFAULT - real on-chain TX only when the resolved key is live (q402_live_*), Q402_PRIVATE_KEY is set, and Q402_ENABLE_REAL_PAYMENTS=1. Every recipient receives the full amount; the sender pays $0 in gas for the entire batch. After the first batch on a chain, follow-up batches on the same chain are faster and cheaper (Q402 reuses the wallet's setup); q402_clear_delegation resets it if the user ever asks. MULTI-WALLET DISAMBIGUATION - when more than one wallet is configured in the user's env (Q402_PRIVATE_KEY for the real EOA, Q402_AGENTIC_PRIVATE_KEY for the Agent Wallet's exported key, or only Q402_MULTICHAIN_API_KEY for the server-managed Agent Wallet), the tool RETURNS WITHOUT firing with `status='needs_wallet_choice'` and an `ambiguousWalletChoice` payload - relay the question to the user verbatim, then call again with the chosen `walletMode` ('eoa' | 'agentic-local' | 'agentic-server'). Do NOT pick a wallet on the user's behalf when multiple are available. Server-mediated batches go through /api/wallet/agentic/batch and are paid-only (the trial key cannot batch). ALWAYS get explicit user confirmation of the complete recipient + amount list, chain, and token in conversation immediately before calling this tool - the user must approve the full batch, not the individual rows. TWO-PHASE CONSENT: confirm:true alone does NOT send. Call this tool first WITHOUT consentToken. It returns status="needs_confirmation" with a quote of every recipient + amount and a consentToken, and moves no money. Present the quote to the user and wait for their NEXT INDEPENDENT message confirming the batch. Only then re-call with the SAME args plus the consentToken. The token is single-use, expires in ~120 seconds, and is rejected if consumed within 2 seconds (same-round double-call protection).q402_receiptLook up a Q402 Trust Receipt by its rct_… receiptId and return the settlement record + a locally-verified ECDSA boolean (the tool re-runs the same canonical-JSON + EIP-191 recovery the receipt page does in the browser). Read-only; no API key required. Use after q402_pay to give the user a shareable verified-by-Q402 URL, or to independently verify a receipt id someone shared with you. **receiptId is required**; passing only txHash returns notFound (tx → receiptId lookup is reserved for a future release).q402_wallet_statusReport the EIP-7702 delegation status of your Q402 wallet (the EOA derived from Q402_PRIVATE_KEY) across all 12 Q402-supported chains. Returns per-chain { delegated, impl } and a one-line summary. Read-only - no signing, no on-chain TX, no quota consumption. Pair with q402_clear_delegation when the user wants to reset a specific chain. Requires Q402_PRIVATE_KEY in env (same as q402_pay).q402_agentic_infoRead-only Agent Wallet introspection. Returns the wallet address, per-tx and daily caps, archive state, an aggregate USD balance, AND a per-chain breakdown (`byChain`) of which chains actually hold USDC/USDT across the 12 supported EVM chains - so you can see WHERE funds are before routing a payment. Authenticated by the configured Multichain API key - no private key required. Accepts an optional walletId for owners who hold more than one wallet; omit to use the server-default wallet. Use this whenever the user asks 'what's in my agent wallet?', 'how much do I have on Base / on each chain?', or 'what's the spending limit?'q402_memory_summarySummarize the user's agent treasury activity over a window (24h / 7d / 30d / all): total USD spent, tx count, spend broken down by chain and by source (send / recurring / redstone-trigger / yield / request / batch), the top vendors paid, active scheduled payouts and the next fire time, open vs paid payment requests, open vs disputed escrow, and the observable failures/holds (recurring rules that hit their cap or errored, disputed escrows). Use for 'summarize my treasury', 'why did my balance drop yesterday' (window:24h), or 'what did we spend this week'. Read-only and free: any live API key (Trial or Multichain).q402_vendor_historyVendor payment history. With a `vendor` address: total USD paid, tx count, first/last paid, and the recurring cadence if the vendor is on a schedule (answers 'how much have we paid Alice so far?'). Without `vendor`: a leaderboard of all vendors by total paid, each flagged whether it is paid on a monthly schedule (answers 'which vendors get paid every month?'). Vendors are address-based; a human name only appears if it was saved as a rule label. Read-only and free: any live API key (Trial or Multichain).q402_agent_spend_reportPer-agent spend report: for each of the owner's Agent Wallets, the USD spent and tx count in the window, plus its label and its daily / per-transaction caps. Answers 'what did my Research agent spend this week?' and 'which agent is spending the most?'. Spend is attributed by the wallet that sent each payment, so it is precise for agents that run on their own dedicated Agent Wallet. Read-only and free: any live API key (Trial or Multichain). Also includes outbound x402 payments made via q402_x402_fetch (generic x402 client path), which are not tracked by the relay Trust Receipt system.q402_recurring_listRead the user's active recurring-payment rules on their Agent Wallet. Returns each rule's ruleId, label, frequency (hourly:N / daily / weekly:{day} / monthly:N / monthly:last), recipient + amount, chain, token, status (active / paused / paused-by-archive / fired-cap-exceeded / cancelled), when the next fire is scheduled, how many fires have completed, and the most recent error (if any). Use this when the user asks 'what scheduled payouts do I have?' or before authoring a new rule with q402_recurring_create. Authenticated by the configured Multichain API key - no private key required.- +36 more on the listing page
Firecrawl MCP Server tools 25
firecrawl_scrapeRetrieve 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_mapEnumerate 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_searchSearch 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_crawlStart 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_statusRetrieve 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_extractDeprecated 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_agentStart 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_statusRetrieve 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_interactOpen 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_stopStop the live interact session associated with a `scrapeId` and release its resources. Returns a success confirmation.firecrawl_parseParse 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_createCreate 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
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.
Q402 MCP
{
"mcpServers": {
"q402-mcp": {
"command": "npx",
"args": [
"-y",
"@quackai/q402-mcp"
],
"env": {
"Q402_TRIAL_API_KEY": "YOUR_Q402_TRIAL_API_KEY_HERE",
"Q402_MULTICHAIN_API_KEY": "YOUR_Q402_MULTICHAIN_API_KEY_HERE",
"Q402_PRIVATE_KEY": "YOUR_Q402_PRIVATE_KEY_HERE",
"Q402_AGENTIC_PRIVATE_KEY": "YOUR_Q402_AGENTIC_PRIVATE_KEY_HERE",
"Q402_AGENT_WALLET_ADDRESS": "YOUR_Q402_AGENT_WALLET_ADDRESS_HERE",
"Q402_ENABLE_REAL_PAYMENTS": "YOUR_Q402_ENABLE_REAL_PAYMENTS_HERE",
"Q402_RELAY_BASE_URL": "YOUR_Q402_RELAY_BASE_URL_HERE",
"Q402_MAX_AMOUNT_PER_CALL": "YOUR_Q402_MAX_AMOUNT_PER_CALL_HERE"
}
}
}
}
Firecrawl MCP Server
{
"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"
}
}
}
}
Frequently asked questions
Q402 MCP is categorized under Code Execution and uses a local stdio subprocess. Firecrawl MCP Server belongs to Search & Data Extraction and uses a local stdio subprocess. Pick Q402 MCP for code execution work and Firecrawl MCP Server for search & data extraction.
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.
Q402 MCP has no declared pricing — check the project's own site. Firecrawl MCP Server is listed as freemium — a free tier with paid plans. Auth: api key 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 q402-mcp and firecrawl-firecrawl-mcp-server as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Q402 MCP has a quality signal of 59/100 (Good) with 1 views, 0 installs and 0 GitHub stars. Firecrawl MCP Server has 90/100 (Excellent) with 14 views, 0 installs and 7,673 GitHub stars.