# MCP connector PayBox speaks the **Model Context Protocol**. Add one URL to your agent's connector list, sign in once, and the agent gets scoped, passkey-gated access to your wallets, cards, and secrets. ## The URL ```txt https://api.paybox.sh/mcp ``` It's a **streamable HTTP** MCP endpoint (protocol version `2025-06-18`). ## Steps ::::steps ### Add the URL **Muse**, **Grok Bots**, **Grok Computer**, and other agents on a computer have no connector screen on the machine where the agent runs. Use the [CLI](/sdk-cli) on that machine instead (`npm install -g @paybox-sh/sdk`, then the package `SKILL.md`). Same API, same grants, same passkey approvals. Do not add a custom connector, enter a Client ID, or use a host secrets store there. Chat products built on the same model often have no connector screen either; install the CLI on the machine the agent runs on. At `claude.ai/new#settings/customize-connectors` (Customize → Connectors), or your agent's equivalent, paste the MCP URL above as a custom connector. At `grok.com` it's `grok.com/connectors` → **New Connector** → **Custom** → paste the URL above, then complete the sign-in it opens. That path is **Grok**, not Grok Bots. ### Sign in Your agent opens PayBox in a tab. Sign in (email + passkey) and **approve a scoped grant** on just the credentials you want this agent to use, with an approval mode per credential. ### Stay in control Above-threshold and sensitive operations pause for your passkey. Every operation is an audit event. Revoke the connector from the app's **Clients** screen at any time. :::: ## Signing: in the chat, or in your browser PayBox never holds your wallet key. Anything that spends or signs is confirmed by you in the **PayBox signing window**, which holds your key and signs there and nowhere else. Agents render that window inside the chat. It appears next to the conversation and signs as soon as your key is connected to it — you take no separate action. What differs is *when* it appears. Most agents draw it the moment the tool runs. Grok draws it only after the agent finishes replying, so there's a gap where nothing is on screen yet. That's expected: let the reply finish, the window shows up, you sign, and the agent reports the outcome on its next message. After passkey approval, some connectors only poll [`get_request`](/reference/mcp-tools#get_request) and never replay the first tool result. PayBox attaches the same `ui://paybox/…` resource on those polls (and on [`reopen_signing_window`](/reference/mcp-tools#reopen_signing_window)) so the signing UI can still appear. Your agent is told which applies to it, so you don't have to work it out. ## How it works The MCP endpoint is the agent's whole interface to PayBox. Adding the URL drives an **[OAuth 2.1 + PKCE](/connect/oauth)** flow under the hood: the client registers dynamically, you consent to a scoped grant, and the client receives an access token it presents as `Authorization: Bearer …` on every call. From there the agent calls the **[MCP tools](/reference/mcp-tools)** — `list_credentials`, `request_payment`, `claim_payment_credentials`, `request_wallet_sign`, `request_secret`, `request_swap`, `get_portfolio`, `verify_solana_balance`, `get_buy_link`, the x402 tools (`discover_services`, `pay_x402`, `use_service`), `request_account_change`, `get_request`, and `list_requests` — plus [`discover_plugins`](/reference/mcp-tools#plugin-tools), `get_contract`, and `use_plugin` for **[plugin tools](/reference/mcp-tools#plugin-tools)** the user has enabled (they also appear on MCP `tools/list`). All the same approval, policy, and audit rules apply, and wallet signing happens in an in-chat **[signing window](/concepts/requests#the-signing-window)** so the key never leaves MoonX MPC. :::tip New to the flow? **[Request lifecycle](/concepts/requests)** explains the submit → approve → poll pattern every tool follows. ::: ## A Claude Code request is refused before it runs If Claude Code refuses a swap with language about being unauthorized for financial operations, run `claude --debug-file ` to capture a log. Then inspect it for the `tools/call` for `request_swap`. That call is the evidence boundary. * No `tools/call` means the host declined before Paybox could evaluate the request. Check Claude Code custom instructions, skills, and `/permissions` for rules that prohibit financial operations. Then use Claude Chat with the same connected Paybox account as the safe workaround. * A `request_swap` response means Paybox received the call. Keep the exact response, including an error response without a `request_id`. A parked request includes a `request_id` that you can use with `get_request`. Check that `list_credentials` shows the intended wallet and grant before reconnecting or changing authorization. Do not change a wallet grant or approval mode to address a refusal that occurs before the tool call. Those controls only apply after Paybox receives a request.