MCP server

Sprintcheckout runs a remote MCP server so your coding agent — Claude Code, Cursor, VS Code or any MCP client — can do the things you would otherwise do by hand in the dashboard: read your payment settings, list paid orders, pull a receipt, create a payment link, mint an API key. You authorize it once in the browser with your Sprintcheckout Google account, tick the scopes you want to grant, and you can revoke it at any time from Dashboard → Developers.

Two different machines, two different docs. A coding agent integrates and configures your account — that is this page. A buying agent pays you over x402 and needs no MCP at all; see x402 payment acceptance.


Endpoint	`https://mcp.sprintcheckout.com/mcp`
Transport	Streamable HTTP, `POST` only (a `GET` returns `405`)
Protocol versions	`2026-07-28` and `2025-11-25`
Authorization	OAuth 2.1 authorization code + PKCE (`S256`), browser sign-in with Google
Client registration	Client ID Metadata Documents — no dynamic client registration, and none needed

Install

The server needs no API key and no local process — it is a URL. Every client below authorizes in your browser the first time you use a tool.

Claude Code
Cursor
VS Code
Any MCP client

claude mcp add --transport http sprintcheckout https://mcp.sprintcheckout.com/mcp

Then run /mcp and choose to authenticate. Claude Code opens the consent page in your browser.To share the server with a repo instead, commit an .mcp.json at its root:

.mcp.json

{
  "mcpServers": {
    "sprintcheckout": {
      "type": "http",
      "url": "https://mcp.sprintcheckout.com/mcp"
    }
  }
}

One click — Add Sprintcheckout to CursorIf the link does not open, paste this into your browser’s address bar:

Cursor deeplink

cursor://anysphere.cursor-deeplink/mcp/install?name=sprintcheckout&config=eyJ1cmwiOiJodHRwczovL21jcC5zcHJpbnRjaGVja291dC5jb20vbWNwIn0=

The config value is base64 of {"url":"https://mcp.sprintcheckout.com/mcp"}. Or edit ~/.cursor/mcp.json (global) or .cursor/mcp.json (per project) by hand:

.cursor/mcp.json

{
  "mcpServers": {
    "sprintcheckout": {
      "url": "https://mcp.sprintcheckout.com/mcp"
    }
  }
}

One click — Add Sprintcheckout to VS CodeOr from a terminal:

code --add-mcp '{"name":"sprintcheckout","type":"http","url":"https://mcp.sprintcheckout.com/mcp"}'

Or commit .vscode/mcp.json to the workspace:

.vscode/mcp.json

{
  "servers": {
    "sprintcheckout": {
      "type": "http",
      "url": "https://mcp.sprintcheckout.com/mcp"
    }
  }
}

Point the client at https://mcp.sprintcheckout.com/mcp as a streamable HTTP server. It discovers everything else on its own:

curl -i -X POST https://mcp.sprintcheckout.com/mcp \
  --header 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

401 Unauthorized

HTTP/2 401
WWW-Authenticate: Bearer resource_metadata="https://mcp.sprintcheckout.com/.well-known/oauth-protected-resource", scope="settings:read orders:read"

The client follows resource_metadata to the protected-resource document, then to the authorization server metadata, and runs the code + PKCE flow. See Discovery documents.

Tools

tools/list returns every tool no matter which scopes you granted, and each description names the scope it needs. That is deliberate: a coding agent can only ask you for a scope it can see.

Tool	Scope	What it does
`get_payment_settings`	`settings:read`	Business details, configured chains and the tokens accepted on each. Never returns your payout wallet address — only whether one is set.
`list_orders`	`orders:read`	Paid orders, newest first, paged with `page` and `size`.
`get_receipt`	`orders:read`	A public receipt by `publicOrderId` (with or without the `TX-` prefix).
`list_api_keys`	`keys:read`	API keys masked — `…` plus the last four characters — and a count. Never cleartext.
`create_payment_session`	`sessions:write`	Creates a real payment link on your live account.
`create_api_key`	`keys:write`	Mints one API key and returns it once. It can never be read again.

There is also one resource, sprintcheckout://quickstart (requires settings:read): a short markdown quickstart rendered from your live account state — the chains and tokens you actually accept, whether a payout address is configured, and the API base path.

`create_payment_session`

Beyond amount, currency and orderType it takes:

editable + minAmount — a buyer-chosen amount with a floor. minAmount on a fixed-amount session is refused, not ignored.
chains — narrow one session to specific chains and tokens, validated against what your account accepts, and optionally naming a publicAddress that this one payment should go to.

Arguments

{
  "amount": 10.00,
  "currency": "USD",
  "orderType": "TRANSIENT",
  "chains": [
    { "name": "base", "tokens": ["USDC"], "publicAddress": "0xAf1D…dA32" }
  ]
}

Unknown arguments are refused by name, never silently ignored. Calling a tool with an argument it does not take does nothing and returns an error naming what it refused and what the tool accepts. Nothing you asked for is quietly dropped.

Scopes

Signing in grants the two read scopes. Everything else is opt-in, and the consent screen shows each one in plain language with read and elevated clearly separated.

Scope	Granted	What it allows
`settings:read`	On first authorization	Read payment settings and the quickstart resource.
`orders:read`	On first authorization	Read paid orders and public receipts.
`sessions:write`	Opt-in	Create payment links on your live account, including links that name their own destination address.
`keys:read`	Opt-in	List API keys, masked.
`keys:write`	Opt-in	Mint new API keys.

Step-up: how a coding agent asks for more

Calling a tool you did not grant returns 403 naming exactly the scope it needs — all of them in a single challenge, never one at a time:

403 Forbidden

HTTP/2 403
WWW-Authenticate: Bearer error="insufficient_scope", scope="keys:write", resource_metadata="https://mcp.sprintcheckout.com/.well-known/oauth-protected-resource"

Your client then re-runs the authorization asking for that scope, and you approve or decline it in the browser.

You can also grant more than the coding agent asked for. The consent screen lists every grantable scope; the ones the client requested are pre-ticked, the rest are unticked and yours to add. An elevated scope is never pre-ticked for you.

What a coding agent cannot do

The payout wallet address on your account cannot be changed over MCP. There is no tool for it, no scope for it, and no checkbox on the consent screen that could grant one. The API refuses the change even if it is attempted directly. Changing it is dashboard-only, by you, signed in.

There is a real exception you should understand before granting sessions:write: a payment link created with create_payment_session can name a destination address for that one payment, and x402 pays the address the link advertises. It cannot touch the address on your account, and it cannot redirect any other payment — but it can direct the payment it creates. Grant sessions:write only to a coding agent you would trust to take a payment on your behalf. Beyond that:

API keys are never readable. create_api_key returns a key once; list_api_keys masks every value, including the one just minted. Store it immediately or it is lost.
Minting is capped twice — 5 keys per 24 hours per authorization, and 25 keys on the account.
get_payment_settings contains no wallet address anywhere, only a configured/not-configured boolean per chain.
Every tool call is audited, including refused ones. Arguments are recorded as a SHA-256 digest, never in the clear.
Tool calls are rate-limited to 300 per hour per authorization.

Managing and revoking access

Open Dashboard → Developers → Authorized coding agents. Every authorization is listed with the client’s name, its domain, the scopes you granted, the labels of any API keys it created, when you authorized it and when it was last used. Revoking takes effect immediately. The next request that coding agent makes is refused — the server re-checks your grant on every single call, so a token already in its hands stops working the moment you revoke, not when it expires. To use the server again, it has to be authorized again from your editor.

Discovery documents

Everything a client needs is published; you should never have to configure any of it by hand.

Document	URL
Protected resource metadata (RFC 9728)	`https://mcp.sprintcheckout.com/.well-known/oauth-protected-resource` — also served at `/.well-known/oauth-protected-resource/mcp`
Authorization server metadata (RFC 8414)	`https://mcp.sprintcheckout.com/.well-known/oauth-authorization-server`
Signing keys	`https://mcp.sprintcheckout.com/.well-known/jwks.json`

.well-known/oauth-protected-resource

{
  "resource": "https://mcp.sprintcheckout.com/mcp",
  "authorization_servers": ["https://mcp.sprintcheckout.com"],
  "scopes_supported": ["settings:read", "orders:read"],
  "bearer_methods_supported": ["header"],
  "resource_documentation": "https://docs.sprintcheckout.com/mcp-server"
}

Access tokens are bound to this server and worthless anywhere else. Their audience is https://mcp.sprintcheckout.com/mcp; presenting one to the regular Sprintcheckout API at api.sprintcheckout.com returns 401. Access tokens are short-lived and refreshed automatically by your client, with refresh-token rotation.

There is no dynamic client registration endpoint, on purpose. DCR is deprecated as of MCP spec 2026-07-28; this server supports Client ID Metadata Documents instead, which every current client above uses. A client that can only do DCR cannot connect.

Get Started

Products

Features

Install

Tools

`create_payment_session`

Scopes

Step-up: how a coding agent asks for more

What a coding agent cannot do

Managing and revoking access

Discovery documents

​Install

​Tools

​create_payment_session

​Scopes

​Step-up: how a coding agent asks for more

​What a coding agent cannot do

​Managing and revoking access

​Discovery documents

Install

Tools

`create_payment_session`

Scopes

Step-up: how a coding agent asks for more

What a coding agent cannot do

Managing and revoking access

Discovery documents