BlockVectra: multi Chain RPC & Data API vs Signer MCP
A side-by-side look at the BlockVectra: multi Chain RPC & Data API and Signer MCP MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose BlockVectra: multi Chain RPC & Data API for finance & fintech work as a local process; choose Signer MCP for finance & fintech as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose BlockVectra: multi Chain RPC & Data API when
- You need dedicated capabilities in the Finance & Fintech domain.
- You prefer a local stdio subprocess transport.
- You want tools like
read_doc, search_docs, list_chains.
Choose Signer MCP when
- You need dedicated capabilities in the Finance & Fintech domain.
- You prefer a local stdio subprocess transport.
- Its auth model fits you: API key required.
- You have the keys it needs:
SIGNER_GATEWAY_URL, SIGNER_API_TOKEN, SIGNER_FETCH_TIMEOUT_MS. - You want tools like
get_verified_price, list_venues, get_attestation.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Finance & Fintech | Finance & Fintech |
| Quality signal | 59/100 · Good | 65/100 · Great |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Local subprocess (stdio) |
| Auth | Not declared | API key required |
| Pricing | Not declared | Paid service |
| Required env vars | None listed | SIGNER_GATEWAY_URLSIGNER_API_TOKENSIGNER_FETCH_TIMEOUT_MS |
| Verified owner | Community listing | Community listing |
| GitHub stars | 0 | 2 |
| Directory activity | 9 views 0 installs 0 upvotes | 5 views 0 installs 0 upvotes |
| Tools | 15 | 7 |
| Full listing | View BlockVectra: multi Chain RPC & Data API | View Signer MCP |
Tools & capabilities
BlockVectra: multi Chain RPC & Data API tools 15
read_docRead the raw Markdown content of a documentation page from /md/{lang}/{path}.md. Path must be an internal relative path (e.g. 'quickstart', 'guides/ai-agents', 'api/json-rpc', 'chains').search_docsFind documentation by topic or task keywords when the page path is unknown. Searches page titles, navigation titles, relative paths, and page summaries, returning titles, relative paths, and summaries. Read a result with read_doc using its path and the same lang; use read_doc directly for a known path or list_docs to browse the documentation catalog. Omit lang for English; limit is 1-20 (default 5). If no results match, try broader keywords or browse list_docs. Available without an API key.list_chainsFetch supported blockchain networks and static parameters from `GET /v1/chains`. `methods.allow` and `methods.deny` support wildcard patterns where `deny` takes precedence over `allow`. `state_window_blocks` indicates the historical state window in blocks for state queries (null when full history is available); `max_logs_block_range` limits `eth_getLogs`: the range is inclusive, so `toBlock - fromBlock + 1` must not exceed it, otherwise the call fails with `logs_range_too_large`. `public` describes the keyless endpoint: `public.url` serves only the methods in `public.methods`, and `public.history_blocks` is how far back a block reference may reach on that endpoint (it does not add methods). Pass `chain` (a slug such as `base_mainnet`) to return only that chain.get_statusLive operational status and network health from `GET /v1/status`. Confirm chain `status` is 'ok' before calling methods; see `list_chains` for static chain capabilities and method policies. For Data API, `data_status` can be 'ok', 'syncing' (queryable and billed normally, but indexing is lagging behind latest block time), or 'unavailable'.get_pricingLive prices and plan limits from `GET /v1/plans`. Use before estimating cost or when asked about free credits, rate limits or per-method prices. Units: 1 billing unit = `pricing.cu_per_unit` CU; 1 USD buys `pricing.units_per_usd` units. `method_weights` includes JSON-RPC and Data API CU per call, `push.log` / `push.native_transfer` / `push.token_transfer` per delivered data event, `push.history` per successful history request and `push.address_day` per billable address-day; resolve a method by exact match, then the longest prefix rule ending in `*`, then the `*` row (JSON-RPC only; Data API and push operations have no default). `free.*` values are in billing units; `key_defaults` are per-key CU/s and burst CU. `promo.ends_at` is a sign-up coverage cutoff, not the end of the offer. For a single method's chain support and documentation use get_method_info instead; for projecting cycle costs use estimate_usage instead.estimate_usageCalculate projected daily and billing cycle Compute Units (CU) and USD costs for planned call volumes across one or more methods, factoring in method weights and free credit allowances from /v1/plans. Available without an API key. Estimates the API key count for planned traffic under key_defaults. Use this tool for volume budget calculations and capacity planning. For looking up raw system pricing tables, use get_pricing instead. For checking whether a single method is supported on a specific chain, use get_method_info instead. Accepts 'lines' array of {method, calls_per_day} or single 'method' and 'calls_per_day'.how_to_get_api_keyGet instructions and endpoints for obtaining a BlockVectra API key via preferred programmatic SIWE sign-up or browser handoff, plus authentication header and URL formats for JSON-RPC and Data API.get_method_infoInspect a single method's chain-by-chain availability, Compute Unit (CU) weight, price per million calls, and documentation link. Check JSON-RPC method policy and Data API dataset coverage separately. JSON-RPC follows methods.allow and methods.deny from /v1/chains. Data API coverage follows data_features in GET /v1/status, with data enabled in /v1/chains. Pricing comes from /v1/plans. For the full system-wide pricing schedule and rate card, use get_pricing instead. For calculating projected bills for expected call volumes across methods, use estimate_usage instead.explain_errorLookup error code, reason, or HTTP status in the official error reference catalog. Returns meaning, billing implications (whether the call was billed), retryability, retry delay, recommended agent action, and documentation URL.list_docsList all available documentation pages, relative paths, and titles from the static documentation index, including webhook push subscriptions, signatures, delivery and billing. Available without an API key.rpc_callExecute a read-only JSON-RPC 2.0 method on a specified blockchain network using your BlockVectra API key, or via the keyless public endpoint if available on the chain. Chain slugs look like 'base_mainnet'; take them from list_chains. Without a key the call goes to the keyless endpoint `/v1/{chain}/public` (the chain's `public.url` in list_chains), which only serves the methods listed in that chain's `public.methods`. Write methods (such as 'eth_sendRawTransaction') are not supported in rpc_call; use 'send_raw_transaction' instead. Consult the Ethereum JSON-RPC specification (https://ethereum.org/en/developers/docs/apis/json-rpc/) and the BlockVectra method reference (https://docs.blockvectra.com/en/api/json-rpc/methods/). With a key, set the 'x-api-key' or 'Authorization: Bearer <key>' HTTP header in your MCP client configuration for full access (keys must not be passed in tool parameters or chat). Returns the raw JSON-RPC response from the server.data_api_getQuery the BlockVectra Data API for a specified chain and path using your BlockVectra API key. For endpoint schemas and parameter specifications, see the OpenAPI contract at https://docs.blockvectra.com/openapi/data.yaml. Requires the 'x-api-key' or 'Authorization: Bearer <key>' HTTP header in your MCP client configuration (keys must not be passed in tool parameters or chat). Returns the HTTP status and JSON response body.- +3 more on the listing page
Signer MCP tools 7
get_verified_priceRead a Uniswap V3 token price from The Graph and return it ONLY if four checks pass: the indexer signed the exact bytes that arrived, that signer resolves on chain to an indexer with stake, the reading is a usable price (a verified signature over a GraphQL error or a zero is not a price), and the price's own age is measured apart from the subgraph head's age — a head can be fresh while the price it carries is a year old. On refusal no price is returned and the answer names both the check that stopped it (`stage`) and that check's own reason (`cause`): `price_absent_or_zero`, `graphql_errors` and `price_stale` are three different problems with three different fixes. Costs one cent in USDC on Base per query and needs X402_PRIVATE_KEY set; without that key it refuses `no_payer_key` and spends nothing. Name the token by `token_address` when you can: a ticker is not a key, and this subgraph holds several tokens called WETH. With neither address nor ticker it returns the most recently priced tokens, filtered to those that actually carry a price. Runs OUTSIDE the enclave.list_venuesList the venues this Signer can sign trades for. Returns the venue id, asset class (perp / spot / margin), and auth scheme (hmac / eip712 / ed25519). Read-only static manifest — does NOT need the Signer gateway to be reachable. Call this first to discover what's signable.get_attestationFetch the Signer enclave's AWS Nitro attestation document with a FRESH NONCE and verify it locally, with no dependencies and no trust in this tool's own summary. Five named checks are returned and any of them can fail: the document decodes as a COSE_Sign1 (document_readable), the nonce inside it is the one just sent (nonce_echoed), its root certificate is the pinned AWS Nitro root (root_pinned), the certificate chain leads to that root (chain_verified), and the hardware signature covers these exact bytes (signature_verified). PCR0/PCR1/PCR2 are read out of the SIGNED bytes, not from a field beside them. WHAT THIS DOES NOT ESTABLISH: that PCR0 corresponds to the published source — rebuild the image from the public clone and compare, or query the on-chain PCR0 registry; and nothing about any past signature, since an attestation speaks about the code that answered this request. If any check is false, treat the document as no evidence rather than weak evidence.get_accountReturn equity, free margin, and open positions for a venue. Read-only (does not sign anything that mutates state). Use BEFORE place_order to confirm the account has margin. Requires SIGNER_API_TOKEN.place_orderPlace a single order on the named venue. Accepts canonical symbol (BTC / BTCUSDT) and qty in BASE ASSET; translates both to the venue's native format (okx sizes in contracts) and echoes the translation in the result — always check `translation.sent` to see what actually hit the exchange. The Signer enclave signs the venue-native payload using a key that has never been exported. Policy enforced server-side: orders that exceed per-asset caps are rejected by the enclave before signing. Returns the venue's order_id on success. Side effect: real or testnet trade depending on venue env.place_hedgePlace a 2-leg MARKET hedge ATOMICALLY: both legs are signed inside the enclave (if either leg fails policy, NOTHING executes), then the gateway fires both venue calls in parallel server-side — minimal leg gap, works even when a venue geo-blocks your residential IP. Accepts canonical symbol (BTC) + qty in BASE ASSET per leg (contract venues converted, translation echoed per leg). Result status: executed (both venue receipts accepted) | partial (ONE leg live — naked position, repair via legs[].outcome) | unknown (a receipt was lost — that leg MAY be live: reconcile with get_account BEFORE any retry, never blind-retry) | failed (both rejected, safe to retry). Market orders only in v1. Side effect: real or testnet trades.cancel_orderCancel an outstanding order by its venue order_id. Signed inside the enclave just like place_order. Returns the cancellation receipt from the venue. Idempotent: cancelling a non-existent / already-filled order returns ok=false with a reason from the venue.
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.
BlockVectra: multi Chain RPC & Data API
{
"mcpServers": {
"blockvectra-multi-chain-rpc-data-api": {
"command": "npx",
"args": [
"--yes",
"@blockvectra/mcp@0.1.0"
]
}
}
}
Signer MCP
{
"mcpServers": {
"namixai-signer-mcp": {
"command": "npx",
"args": [
"-y",
"@usenami/signer-mcp"
],
"env": {
"SIGNER_GATEWAY_URL": "YOUR_SIGNER_GATEWAY_URL_HERE",
"SIGNER_API_TOKEN": "YOUR_SIGNER_API_TOKEN_HERE",
"SIGNER_FETCH_TIMEOUT_MS": "YOUR_SIGNER_FETCH_TIMEOUT_MS_HERE"
}
}
}
}
Frequently asked questions
BlockVectra: multi Chain RPC & Data API is categorized under Finance & Fintech and uses a local stdio subprocess. Signer MCP belongs to Finance & Fintech and uses a local stdio subprocess. Pick BlockVectra: multi Chain RPC & Data API for finance & fintech work and Signer MCP for finance & fintech.
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.
BlockVectra: multi Chain RPC & Data API has no declared pricing — check the project's own site. Signer MCP is listed as a paid service. 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 blockvectra-multi-chain-rpc-data-api and namixai-signer-mcp as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, BlockVectra: multi Chain RPC & Data API has a quality signal of 59/100 (Good) with 9 views, 0 installs and 0 GitHub stars. Signer MCP has 65/100 (Great) with 5 views, 0 installs and 2 GitHub stars.