BizVerify vs Signer MCP
A side-by-side look at the BizVerify 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 BizVerify for finance & fintech work over a hosted endpoint; 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 BizVerify when
- You need dedicated capabilities in the Finance & Fintech domain.
- You prefer a remote HTTP/SSE transport.
- Its auth model fits you: No auth required.
- You have the keys it needs:
BIZVERIFY_API_KEY, BIZVERIFY_MCP_URL. - You want tools like
get_config, list_jurisdictions, verify_business.
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 | 66/100 · Great | 64/100 · Good |
| Install command | Confirmed | Confirmed |
| Transport | Remote HTTP/SSE | Local subprocess (stdio) |
| Auth | No auth required | API key required |
| Pricing | Not declared | Paid service |
| Required env vars | BIZVERIFY_API_KEYBIZVERIFY_MCP_URL | SIGNER_GATEWAY_URLSIGNER_API_TOKENSIGNER_FETCH_TIMEOUT_MS |
| Verified owner | Community listing | Community listing |
| GitHub stars | 0 | 2 |
| Directory activity | 0 views 0 installs 0 upvotes | 5 views 0 installs 0 upvotes |
| Tools | 9 | 7 |
| Full listing | View BizVerify | View Signer MCP |
Tools & capabilities
BizVerify tools 9
get_configReturns BizVerify's public configuration as readable text: active US and international jurisdictions, per-operation credit costs, the free-tier allowance, credit packages with pricing, feature flags, and documentation/legal links. Free and requires no authentication. Call this first to discover what jurisdictions are supported and what each operation costs before verifying.list_jurisdictionsLists every registered jurisdiction with its code, active/inactive status, and supported capabilities — search, entity lookup, quick verification, and deep verification. Free and requires no authentication. Use it to confirm a state or country is supported and which verification tiers it offers before calling verify_business or search_entities.verify_businessConfirm a specific, named business in one jurisdiction — the PRIMARY tool whenever the user wants to verify, check, confirm, or look up a company's existence, status, good standing, or details (e.g. "verify Acme LLC in Delaware", "is Acme registered in FL?", "I need to verify a company in Delaware"). If the user has verification intent but has not given the exact company name, ASK them for the name and use THIS tool — do NOT fall back to search_entities. Two tiers: quick (1 credit) returns existence + status + good-standing. Deep (15 credits, or 25 with force_refresh) adds entity type, formation date, registered agent, officers, principal address, and filing history. Deep is available in a subset of jurisdictions; requesting deep where unavailable returns a quick result with a reason. Requires authentication. A completed verification deducts credits whether or not the business is found — a confirmed no-match is a result. Calls that cannot produce an answer (source unavailable or timed out) are refunded.search_entitiesDiscover candidate businesses when the exact entity is UNKNOWN — a listing/discovery tool, NOT a verification tool. Use only when the user wants to browse or list multiple companies matching a partial or fuzzy name, or does not yet know which specific entity they mean. If the user can name one specific company they want to confirm or check, use verify_business instead (ask them for the name first if needed). Costs 2 credits per jurisdiction searched and requires authentication.check_job_statusPoll a long-running (async) verification job created by verify_business. Returns the full verification result once complete, a failure reason if it failed, or a "still processing" status to poll again. Free — no credits charged — but requires authentication. Pass the job_id from the verify_business async response.get_entityFetch a previously verified business entity from BizVerify's cache by its ID — returns name, jurisdiction, status, type, good-standing, formation date, registered agent, and the number of snapshots on record. Free and read-only; does NOT fetch a fresh live result (use verify_business with force_refresh for live data). Requires authentication. Pass an entity_id returned by a prior verify_business or search_entities call.get_entity_historyReturns the chronological verification snapshots recorded for an entity — each with a timestamp, name, and status — newest first, with pagination. Costs 5 credits and requires authentication. Use it to see how a company's status or details have changed over time.get_accountReturns your BizVerify account summary: email and verification status, plan, current credit balance, member-since date, and your active and revoked API keys. Free and read-only; requires authentication. Use it to check your remaining credit balance before running paid verifications.purchase_creditsStarts a credit purchase: creates a Stripe checkout session for the chosen package and returns a payment URL to present to the user. Does NOT charge immediately and does NOT add credits until the user completes payment — credits are then added automatically. Requires authentication. Packages: credits_100, credits_500, credits_2000, credits_10000 (see get_config for current prices).
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.
BizVerify
{
"mcpServers": {
"bizverify-2": {
"url": "https://api.bizverify.co/mcp"
}
}
}
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
BizVerify is categorized under Finance & Fintech and uses a remote HTTP/SSE transport. Signer MCP belongs to Finance & Fintech and uses a local stdio subprocess. Pick BizVerify 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.
BizVerify has no declared pricing — check the project's own site. Auth: no auth required. 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 bizverify-2 and namixai-signer-mcp as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, BizVerify has a quality signal of 66/100 (Great) with 0 views, 0 installs and 0 GitHub stars. Signer MCP has 64/100 (Good) with 5 views, 0 installs and 2 GitHub stars.