Loading ToolBench
MCP server for Neutron - Lightning payments, Bitcoin, USDT, and fiat transactions for AI-powered applications
Neutron-mcp provides well-structured tool definitions with explicit schemas and descriptions for all 16 tools. Naming follows verb_noun convention consistently (get_, create_, list_, delete_). Descriptions are detailed and include practical examples for complex tools like neutron_create_transaction. However, several critical issues limit the score: (1) Parameter descriptions lack validation constraints (ranges, patterns, allowed values). (2) Many optional parameters lack clarity on interdependencies (e.g., sourceAmount vs destAmount in neutron_create_transaction are mutually exclusive but this is buried in prose). (3) No output schemas documented, LLMs cannot predict response structure for downstream chaining. (4) Error handling and recovery guidance completely absent. (5) Security concerns: API credentials injected via environment variables but no mention of rate limiting or secret handling. (6) Tools like neutron_create_transaction combine multiple payment types (Lightning, on-chain, fiat) into one overly complex tool, should be split into neutron_create_lightning_payment, neutron_create_onchain_payment, neutron_create_fiat_payout. Average tool quality across 16 tools reflects these patterns.
Verify your Neutron API credentials. Returns your account ID and confirms access is working.
Confirm a quoted transaction to execute it. Call this after neutron_create_transaction.
Create a Lightning invoice to receive Bitcoin. Returns a BOLT11 payment request and QR code page. Examples: - Receive 10,000 sats: amountSats=10000 - Receive 0.001 BTC: amountBtc=0.001 - With tracking: amountSats=5000, extRefId="order-123"
Create a transaction. Supports all payment types: Lightning send: sourceCcy="BTC", sourceMethod="neutronpay", destCcy="BTC", destMethod="lightning", paymentRequest="lnbc..." Lightning Address: sourceCcy="BTC", sourceMethod="neutronpay", destCcy="BTC", destMethod="lnurl", lnurl="[email protected]", sourceAmount=0.0001 On-chain send: sourceCcy="BTC", sourceMethod="neutronpay", destCcy="BTC", destMethod="on-chain", address="bc1q..." On-chain receive: sourceCcy="BTC", sourceMethod="on-chain", destCcy="BTC", destMethod="neutronpay", destAmount=0.001 USDT send (TRON): sourceCcy="USDT", sourceMethod="neutronpay", destCcy="USDT", destMethod="tron", address="T..." Internal swap: sourceCcy="BTC", sourceMethod="neutronpay", destCcy="USDT", destMethod="neutronpay", sourceAmount=0.001 Fiat payout: sourceCcy="BTC", sourceMethod="neutronpay", destCcy="VND", destMethod="vnd-instant", bankAcctNum="...", institutionCode="...", recipientName="...", countryCode="VN", recipientPhone="+84912345678" IDR payout example: destCcy="IDR", destMethod="idr-instant", countryCode="ID", recipientPhone="+628123456789" (E.164 format — always include + prefix) Amounts are in BTC (not sats). 100 sats = 0.00000100 BTC. Set amount on ONE side only (source OR dest), not both. Returns a quoted transaction — call neutron_confirm_transaction to execute.
Missing output schemas for all tools. LLMs cannot predict response structure, forcing trial-and-error field extraction and preventing efficient tool chaining. All 16 tools lack documented return types.
neutron_create_transaction conflates multiple payment types (Lightning, on-chain, USDT, fiat) into a single overly complex tool with 15+ optional parameters. This violates the single-responsibility principle and creates ambiguous LLM decision paths. Should be split into neutron_create_lightning_payment, neutron_create_onchain_payment, neutron_create_fiat_payout.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Register a webhook to receive transaction state change notifications. Requires an HTTPS callback URL.
Unregister a webhook by ID.
Get account details: display name, status, country, timezone, and sub-accounts.
Get your Bitcoin on-chain deposit address. Static, reusable SegWit (bc1q...) address.
Get supported banks and fiat institutions for a country. Use this to find institutionCode for fiat payouts.
Get current exchange rates for all supported currencies.
Check transaction status and details. Use to track payment progress after confirmation.
Get your USDT deposit address on TRON (TRC-20) or Ethereum (ERC-20).
Get a specific wallet by ID. Shows balance, available balance, and currency.
List all wallets with balances. Shows each currency (BTC, USDT, fiat) with total and available balance.
List transactions with optional filters. Returns recent transactions by default.
List all registered webhooks for your account.
Parameters lack validation constraints. Examples: sourceAmount/destAmount in neutron_create_transaction are documented as mutually exclusive but only in prose; no constraint preventing both from being set. amountSats/amountBtc in neutron_create_lightning_invoice also lack formal mutual exclusion. This forces LLMs to guess and increases failure rates.
No error handling or recovery guidance documented. Tools return errors but do not guide LLMs on next steps. Example: if a transaction fails due to insufficient balance, what should the LLM do? Check wallet? Retry? This pattern is absent across all tools.
No tool annotations for risk levels. Risk metadata (READ_ONLY, WRITE, IRREVERSIBLE, DESTRUCTIVE) exists in the evaluation spec but is not declared in tool definitions via readOnlyHint/destructiveHint/idempotentHint. This prevents LLMs from understanding tool safety profiles.
neutron_list_transactions accepts optional filters (status, method, currency, fromDate, toDate) but lacks pagination result documentation. No 'total' count or 'next_cursor' mentioned, preventing LLMs from knowing if there are more results beyond the limit.
Parameter descriptions contain example values (e.g., 'Wallet ID (e.g. wal_btc_001)', 'address="bc1q..."'). LLMs frequently treat examples as template values and reuse them literally in real calls, causing failures with placeholder data.
No rate limiting guidance documented. An agent in a retry loop or batch operation could exhaust the API quota. Tools should document expected rate limits and backoff strategies.
Irreversible operations (neutron_confirm_transaction, neutron_delete_webhook) lack confirmation or dry-run support. An agent mistake could delete webhooks or execute unintended payments. Should support a 'preview' or 'confirm' pattern.