Shinjuku Shielded

What Shinjuku Shielded does

Shinjuku Shielded MCP server gives an MCP client access to a local Solana wallet and a shielded USDC balance. The wallet remains on the user's machine, while the agent can request account status, move USDC into the shielded balance, pay supported x402 sellers, and send funds back to a public Solana address.

Payment tools cover public x402 discovery, unpaid previews, and URL fetching with payment when a seller returns a 402 response. The server supports shielded-exact offers and standard Solana exact offers routed through Shinjuku. It can also return image responses as MCP image blocks and save the image file.

How it works

The server starts in setup mode when no wallet exists. shinjuku_setup asks the MCP client to confirm wallet creation and displays the configured caps. After setup, the same server switches to wallet tools. Clients that cannot present the confirmation can run npx -y shinjuku-shielded setup in a terminal.

Funds first sit as plain USDC on the wallet's Solana key. wallet_shield moves them into the shielded balance; the wallet key does not need SOL because the facilitator's relayer pays the network fee. A shield operation can take minutes, so the client should repeat the same request_id to check progress rather than start another deposit.

For payments, x402_discover searches public listings such as Coinbase x402 Bazaar, PayAI, and Dexter. x402_preview reports the seller price, scheme, and cap check without paying. x402_pay then fetches the URL and pays only when required. Reusing a request_id resumes the existing operation and prevents duplicate payment.

The Shinjuku Shielded MCP server records caps during setup. Calls may lower those limits but cannot raise them. wallet_unshield requires confirmation for destinations that were not configured in advance, and it refuses the wallet's own address to avoid linking deposits and exits.

Setup and configuration

Run the MCP command with npx -y shinjuku-shielded mcp in an MCP client configuration. Setup creates the local wallet, a private passphrase file, and checked proof tools without asking the user to provide a secret. The server uses a relay for reads by default; a user-provided RPC takes precedence.

Optional command-line modes control wallet operations. --tor hides the user's IP from the payment service, --proof-tools enables shielding, and --exit-proof-tools with --profile enables unshielding. --no-shield disables shielding. The provided material does not specify required environment variables.

Tools and capabilities

• wallet_status reports whether setup is complete and gives the next action.
• wallet_balance reports spendable and unshielded USDC, including shielded funds, refunds in flight, and older set-aside value.
• wallet_receipts lists recent paid hosts, amounts, transactions, and times without exposing full URLs.
• wallet_cancel closes an unfinished payment and returns its reserved balance.
• wallet_unshield sends shielded USDC to a public Solana address after the required confirmation.

If a payment succeeds but the seller does not return an answer, the payment remains recorded as paid. If a standard exact seller rejects the payment, the price and fee return automatically within about two minutes.

Limitations and notes

The first discovery request takes about 15 seconds. A single payment can use one account and up to three notes; if no account covers the amount, the wallet must be merged with shinjuku-wallet merge before trying again. Standard exact payments require the configured maximum to cover both the seller price and Shinjuku's fee.

The server does not pay when a URL does not return a 402 response. Shielding and unshielding are asynchronous or confirmation-gated operations, and disabled wallet tools return an error explaining what must be enabled. Older confidential V0b vault amounts are no longer supported, although older pocketed value can be returned to the shielded balance by the wallet.