Venice API MCP服务器

@veniceai/mcp-server

Model Context Protocol server for the Venice API - uncensored, private AI for any MCP host (Claude Desktop, Cursor, ChatGPT, LM Studio, Continue, LibreChat, Open WebUI, AnythingLLM, Jan, Le Chat).

Plug Venice's chat, image, video, audio, music, and character models into any agent in 30 seconds, including billing and API-key operations. 45 tools across all modalities, one config block.

Requires Node.js 20 or newer; Node.js 22 or 24 is recommended. CI tests Node.js 20, 22, and 24. The refreshed MCP SDK dependency graph requires Node.js 20 for fresh installs, so upgrade Node.js before installing this version if you previously used Node.js 18.

Quick start

1. Get a key from venice.ai

See the API key guide for step-by-step instructions.

2. Add this to your MCP host config

Claude Desktop (~/Library/Application Support/Claude/claude_desktop_config.json on macOS, %APPDATA%\Claude\claude_desktop_config.json on Windows), Cursor (~/.cursor/mcp.json), LM Studio, etc:

{
  "mcpServers": {
    "venice": {
      "command": "npx",
      "args": ["-y", "@veniceai/mcp-server@0.3.0"],
      "env": { "VENICE_API_KEY": "<your-venice-api-key>" }
    }
  }
}

3. Restart your MCP host

That's it. Type a prompt — your agent now has chat, image, video, music, TTS, ASR, and 39 more Venice tools.

What you get

45 tools spanning every Venice modality plus billing and API-key operations, 3 resources (venice://models, venice://styles, venice://voices) and 3 prompt templates (uncensored research, NSFW creative writing, image style explorer). The voices resource is built live from each TTS model's catalog metadata.

Every tool declares explicit readOnlyHint, destructiveHint, idempotentHint and openWorldHint annotations to help hosts decide when to request approval. Video and music status tools are marked destructive because their optional delete_media_on_completion argument can delete stored media before returning the result. Hints describe a tool's possible behavior; hosts should still enforce their own approval policy.

💬 Chat & embeddings

🎨 Image

🎬 Video

🔊 Audio (TTS / ASR)

🎵 Music

🌐 Web augment

📚 Catalog

🔐 TEE attestation

Both routes are currently live without authentication. They only apply to text models advertising supportsTeeAttestation. These tools expose evidence; they do not verify it, and this server does not encrypt chat. venice_chat rejects enable_e2ee.

Both chat tools retain the upstream completion id and actual model, when present, in structuredContent. Only responses with the upstream X-Venice-TEE: true header also include those values in an additional JSON text block for text-only clients. Pass those values to venice_tee_signature to retrieve the signature for that completion. Ordinary responses keep their existing answer text without an extra metadata block; the first block and tool-call fallbacks are unchanged. The header is an upstream indication, not cryptographic verification.

Media API behavior

• Successful upstream responses have a default 16 MiB limit, including JSON and text without a declared Content-Length. Tool-specific image, video, audio, transcription, billing, and RPC limits take precedence. Oversized responses fail without a partial result; an inference may already have completed and incurred a charge before the limit is reached. There is no environment override for this default.
• venice_embeddings accepts at most 128 texts per call, for both float and base64 output. Larger batches are rejected locally before submission, so the rejected batch incurs no upstream charge. Split larger jobs into separate calls; the server never automatically splits or retries a batch. This conservative limit avoids the observed overflow for a 256-text, 4,096-dimension float response, but is not a byte-size guarantee for every model or response encoding. The 16 MiB guard still applies, and an unusually large response from an accepted batch can still be rejected after processing upstream.
• Upstream API redirects are rejected to keep credentials and request bodies at the configured API origin.
• Image aspect_ratio and resolution values remain free strings because supported values vary by model. Venice validates them. When enhance_prompt is applied, image generate/edit/multi-edit results include the URL-decoded enhanced_prompt returned in x-venice-enhanced-prompt. Image responses are capped at VENICE_MAX_IMAGE_RESPONSE_BYTES (default 32 MiB). Unlike an oversized video, an oversized image result cannot be retried for free, so request fewer variants, a lower resolution, or jpeg/webp output for large batches.
• Current public Seedance models may reject media containing detectable persons outright. Defensive support remains for compatible or legacy needs_consent responses: the tool returns Venice's policy text, affected media roles, and next step. The three consents.seedance flags are legal attestations and must only be set to true after the user explicitly confirms all three statements. Consent is never a content-policy bypass.
• Completed videos may arrive as video/mp4 or as JSON with a download_url. Binary completions are returned as an embedded MCP resource (blob, mimeType: "video/mp4", synthetic venice://video/... URI), streamed into a bounded buffer that defaults to 25 MiB (VENICE_MAX_VIDEO_RESPONSE_BYTES). Oversized binary results remain queued and can be retried with the same queue ID after changing the limit. JSON completions return the download_url as an MCP resource link instead of fetching that URL. Because that link stops working once the stored media is removed, delete_media_on_completion is not applied to download_url results: download the file first, then call venice_video_complete (and optionally send an HTTP DELETE to the link to revoke it). For VPS / Grok Imagine Private models, download_url is returned only on queue; pass that URL into venice_video_status so a COMPLETED retrieve without an inline URL still yields a resource link.
• Music retrieval returns JSON status and timing while processing, then an audio/* body when complete (including MP3, WAV, FLAC, and M4A). Completed tracks are returned as embedded MCP blob resources with a synthetic venice://music/... URI and buffered up to 32 MiB by default (VENICE_MAX_AUDIO_RESPONSE_BYTES). That configurable limit applies only to binary media; successful status JSON uses a separate fixed 1 MiB safety limit. Oversized, empty, or non-audio responses are not deleted, so the same queue ID remains available for cleanup or a retry with a higher limit. JSON completions with a download_url return it as an MCP resource link; as with video, delete_media_on_completion is not applied to them: download the file first, then call venice_music_complete.

⛓️ Crypto

💰 Billing (ADMIN API key only)

Usage-history first pages default to 10 rows. JSON and CSV pages are returned whole, never truncated. A page exceeding 64 KiB returns an error without partial rows or a continuation cursor; restart with the original filters and a smaller page_size (minimum 10), or a narrower timestamp range. Retrying the same cursor cannot reduce the page size encoded in it.

Usage-history continuation calls must send cursor without the original filters. CSV pages return a csv:-prefixed nextCursor so a cursor-only follow-up stays on text/csv. The deprecated /billing/usage route is not wrapped. Billing tools require an ADMIN VENICE_API_KEY and fail locally instead of falling back to SIWX. Inference keys cannot call these endpoints.

🔑 API keys

List, get, and rate-limit logs require an ADMIN VENICE_API_KEY. venice_api_key_rate_limits accepts an INFERENCE or ADMIN key. These tools never forward SIGN-IN-WITH-X. Web3 challenge and mint are not registered here.

💳 x402 wallet helpers

Optional — only needed if you authenticate with a wallet via x402 instead of an API key. See x402 — pay with a wallet.

Configuration

Self-hosting (Streamable HTTP)

/mcp is a credential-backed tool execution endpoint: callers can spend the configured Venice API key or x402 balance. When HTTP mode binds outside loopback, startup fails unless VENICE_MCP_AUTH_TOKEN is set, or VENICE_MCP_ALLOW_UNAUTHENTICATED_HTTP=1 is explicitly set behind a trusted authenticated proxy.

docker run -p 3333:3333 \
  -e VENICE_API_KEY=<your-venice-api-key> \
  -e VENICE_MCP_AUTH_TOKEN=<choose-a-long-random-token> \
  ghcr.io/veniceai/venice-mcp-server:latest
# server at http://localhost:3333/mcp

Clients should send Authorization: Bearer <choose-a-long-random-token> with HTTP MCP requests. HTTP clients should create new sessions without an mcp-session-id header and then reuse the server-issued session ID; unknown or malformed caller-provided session IDs are rejected. For reproducible production installs, pin the npm package version as shown in the examples instead of using an unversioned latest install path.

HTTP requests to /mcp must also use an allowed Host and, when present, an allowed Origin. The defaults support localhost, 127.0.0.1, and [::1] on the listener port. Configure the public authority in VENICE_MCP_ALLOWED_HOSTS when using a reverse proxy or another hostname, and the browser application's origin in VENICE_MCP_ALLOWED_ORIGINS when needed. Each configured list replaces its default list, so include any local entries you still use. Forwarded headers do not grant trust. These checks also apply when bearer authentication is configured; /healthz remains available for health probes. Set a bearer token even for local HTTP when possible.

The Origin allowlist is a request validation rule; it does not enable CORS or handle browser preflight requests. Cross-origin browser clients need a separately configured trusted proxy or server-side MCP connection.

Or run from source — see Development below.

x402 — pay with a wallet, no account required

Skip this section if you're using VENICE_API_KEY. Everything below is optional and only matters if you specifically want to pay with a crypto wallet instead of a Venice account.

Venice supports EVM SIWE or Solana SIWX wallet authentication backed by prepaid USDC credit on Base or Solana mainnet, in addition to the normal API key flow. This lets you use Venice with no email, phone, or KYC — your wallet is the only identity.

Two-line config

{
  "mcpServers": {
    "venice": {
      "command": "npx",
      "args": ["-y", "@veniceai/mcp-server@0.3.0"],
      "env": { "VENICE_SIWX_TOKEN": "<base64 signed SIWX payload>" }
    }
  }
}

The MCP server forwards the existing VENICE_SIWX_TOKEN env format using Venice's preferred SIGN-IN-WITH-X header.

How it works

ONE-TIME SETUP (per wallet)
  Sign an EVM SIWE or Solana SIWX message → produces a SIWX token (base64 JSON)
  Set VENICE_SIWX_TOKEN in this MCP server's env

TOP UP (when balance is low)
  POST /api/v1/x402/top-up  (no payment header)  →  402 + payment requirements
  Choose a Base or Solana USDC option and sign it in your wallet
  POST /api/v1/x402/top-up with PAYMENT-SIGNATURE: <signed>  →  Venice settles
  the payment and credits your prepaid balance

EVERY INFERENCE CALL
  MCP server sends SIGN-IN-WITH-X: <SIWX token>
  Venice → wallet → credit account → debits and runs inference

This MCP server never sees your private key. EVM/Solana SIWX signing and USDC payment signing happen in your wallet — the server forwards only the signed SIWX token. The top-up helper discovers requirements but does not accept or submit payment signatures.

The helper tools venice_x402_balance, venice_x402_top_up_info, and venice_x402_transactions make balance + top-up flow inspectable from inside the agent.

Why prepaid instead of per-call?

• ⚡ Latency — once topped up, calls are sub-100ms (no on-chain settlement per call)
• 🧮 Throughput — Coinbase CDP facilitator settles top-ups in batches
• 🔒 Privacy — wallet ↔ credit account is the only identity link; no email/phone/KYC
• 🪙 DIEM shortcut — wallets linked to a Venice user with DIEM staked consume from staking balance, no USDC needed
• 💸 Min top-up $5 (anti-dust). Minimum balance to inference is $0.10.

Per-call HTTP 402 — not supported

Venice rejects payment headers on inference routes. The preferred PAYMENT-SIGNATURE header is only used when submitting a signed payment to /api/v1/x402/top-up; this MCP server does not submit payments. After an external top-up, Venice debits the wallet's off-chain credit account on inference.

Auth-mode coverage notes

Some Venice endpoints don't accept both auth modes:

Hybrid

Set both VENICE_API_KEY AND VENICE_SIWX_TOKEN — API key wins. SIWX is only used when the key is absent.

Architecture

┌──────────────────────┐        stdio  OR        ┌────────────────────────┐
│  MCP host            │      Streamable HTTP    │  @veniceai/mcp-server  │
│  (Claude / Cursor /  ├────────────────────────▶│  - 45 tools            │
│   ChatGPT / etc.)    │                         │  - 3 resources         │
└──────────────────────┘                         │  - 3 prompts           │
                                                 │  - header forwarder    │
                                                 └────────────┬───────────┘
                                                              │ HTTPS
                                                              │   Authorization: Bearer ***
                                                              │   OR
                                                              │   SIGN-IN-WITH-X: <SIWX>
                                                              ▼
                                                 ┌────────────────────────┐
                                                 │  Venice API            │
                                                 │  api.venice.ai         │
                                                 └────────────────────────┘

Tool reference (endpoints + auth modes)

Development

npm install
npm run build             # generate dist/ locally
npm test                  # build, then run the full test suite
npm run test:unit         # unit tests only
npm run test:integration  # build, then spawn dist/cli.js + a mock Venice over real stdio JSON-RPC
npm start                 # stdio mode
npm run start:http        # http mode on :3333

dist/ is generated by npm run build and is intentionally ignored by git rather than committed. Published npm packages include dist/. Direct source publication runs prepublishOnly; the release workflow builds and tests once, then publishes the resulting package archive without running package lifecycle scripts again.

Releases

Commit matching versions in package.json and package-lock.json before creating the release tag. The release tag must be the package's exact semantic version, optionally prefixed with v. Build metadata such as +build.5 is rejected because npm can normalize it away. The workflow builds the tagged commit and fails if the tag, package version, or lockfile version disagree; it never bumps the version or pushes a follow-up commit.

Build and publication run in separate jobs using Node.js 24 and npm 11.5.1 or newer. Release packing uses the same npm minimum as trusted publishing. This also excludes npm 10, which can run prepare despite --ignore-scripts. The build job has read-only repository permissions, tests the package, and uploads its archive. The publish job verifies the archive's checksum and publishes that exact archive using npm trusted publishing. Already-published versions are skipped. A failed build or version check requires fixing the release inputs before publication.

Test layout

test/
├── config.test.ts             # env parsing, defaults, header precedence
├── format.test.ts             # 402 formatter cases
├── venice-client.test.ts      # HTTP client + real mock Venice
├── tools.test.ts              # tool registry (45 tools) + endpoint/method/body mappings
├── integration.test.ts        # end-to-end JSON-RPC over stdio against a mock Venice
└── helpers/
    ├── stub-client.ts         # in-process VeniceClient stub
    └── mock-venice-server.ts  # real http.Server fake of Venice for integration tests

The integration suite spawns the compiled CLI and speaks JSON-RPC on its stdin/stdout, exercising initialize → tools/list → tools/call → resources/list → resources/read against a real HTTP mock Venice in three auth scenarios (API key only, SIWX only, no auth).

Security regression tests exercise HTTP Host/Origin validation, pre-parser authentication and transport cleanup using local fixtures and synthetic credentials.

End-to-end with live Venice + Base EVM harness

test/e2e/ currently exercises the EVM rail against the real Venice API and real Base mainnet—not a mock. Venice and the MCP x402 helpers support both Base and Solana, but this harness generates a throwaway EVM wallet and signs SIWE + EIP-3009 payloads with viem. The wallet is persisted at .e2e-wallet.json (chmod 600, gitignored—never commit).

Each harness mode passes its intended credentials explicitly: wallet-mode children clear any inherited API key, and API-key children clear any inherited SIWX token. This keeps the two authentication runs independent even when the parent environment contains both credentials.

# Comprehensive — all 45 tools × both auth modes, side-by-side report (mint is always skipped)
env VENICE_API_KEY=<your-venice-api-key> npm run test:e2e:all-tools

FAQ

Do I have to deal with crypto? No. The simple path is VENICE_API_KEY + a normal Venice account. x402 is an option for users who want a wallet-only flow.

Where does the wallet's private key live? Not in this server. You sign the EVM SIWE or Solana SIWX message and any USDC top-up payment in your own wallet. The server only sees signed payloads and never accepts a private key.

Minimum top-up? $5 USD (anti-dust). Minimum balance to call inference is $0.10. Default suggested top-up is $10.

Privacy guarantees? No email, phone, or KYC is required on the SIWX path. venice_tee_attestation and venice_tee_signature return hardware evidence for the caller to verify. This server does not encrypt chat.

DIEM staking? If your wallet is linked to a Venice user with DIEM staked, calls consume from the staking balance instead of USDC credits — no top-up needed.

Getting 402 errors even though I have an API key? The most common cause is that VENICE_API_KEY isn't being forwarded to the MCP server process. Most MCP hosts (Claude Desktop, Cursor, Codex, etc.) only pass environment variables that are explicitly listed in the "env" block of your MCP config — system-level env vars are not automatically inherited. Make sure your config looks like this:

{
  "mcpServers": {
    "venice": {
      "command": "npx",
      "args": ["-y", "@veniceai/mcp-server@0.3.0"],
      "env": { "VENICE_API_KEY": "<your-venice-api-key>" }
    }
  }
}

If the key is missing or blank, the server falls back to x402 mode and returns a 402 payment challenge.

Disclaimer

Community-maintained. Provided as-is, with no warranty or SLA from Venice AI. Use at your own risk.

License

MIT