Q402 MCP vs MATLAB MCP Server
A side-by-side look at the Q402 MCP and MATLAB 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 MATLAB MCP Server for code execution. 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 MATLAB MCP Server when
- You need dedicated capabilities in the Code Execution domain.
- Its auth model fits you: No auth required.
- You want tools like
script_path, code, project_path.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Code Execution | Code Execution |
| Quality signal | 59/100 · Good | 55/100 · Good |
| Install command | Confirmed | Not confirmed yet |
| Transport | Local subprocess (stdio) | — |
| Auth | Not declared | No auth required |
| Pricing | Not declared | Not declared |
| 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 | None listed |
| Verified owner | Community listing | Community listing |
| GitHub stars | 0 | 1,712 |
| Directory activity | 1 views 0 installs 0 upvotes | 0 views 0 installs 0 upvotes |
| Tools | 48 | 3 |
| Full listing | View Q402 MCP | View MATLAB 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
MATLAB MCP Server tools 3
script_pathcodeproject_path
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"
}
}
}
}
MATLAB MCP Server
No confirmed install command for MATLAB MCP Server yet — follow the setup steps linked from its listing page rather than a guessed package name.
Frequently asked questions
Q402 MCP is categorized under Code Execution and uses a local stdio subprocess. MATLAB MCP Server belongs to Code Execution and uses an install path we have not confirmed yet. Pick Q402 MCP for code execution work and MATLAB MCP Server for code execution.
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. MATLAB MCP Server has no confirmed install command yet — follow its own setup instructions.
Q402 MCP has no declared pricing — check the project's own site. MATLAB MCP Server has no declared pricing — check the project's own site. 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 q402-mcp and matlab-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. MATLAB MCP Server has 55/100 (Good) with 0 views, 0 installs and 1,712 GitHub stars.