Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

Rozo Checkout

REMOTE · MCP.ROZO.AI

Pay OpenRouter and Coinbase payment links with USDC, USDT, ETH, BNB, POL, SOL or BTC Lightning.

Available components

+2 this week 82 Trust /100

Last scanned (19 hours ago)

Scores higher than 85% of remote servers

Reachable. Last reached 4 Nov 2026.

Category Crypto and Web3

Trust breakdown (7 categories)

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →

Endpoint Security74
Transport & Reachability100
Schema Quality & AI Usability62
  • AI-judged instruction clarity (excellent).Pass
  • Context-footprint check failed: tool/resource definitions use about 2906 tokens (~290/item across 10 items; 10 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
  • Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management97
  • Stability observed for 29 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
  • 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
  • 100% of tool parameters carry a description.Pass
Tool Safety100
  • No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
  • We read all 10 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
  • An AI judge read all 11 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
  • Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Changelog

Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.

  • 4 Nov 26 −1
    • Stability: pass → 0.97 functional
  • 3 Nov 26 +1
    • Stability: 0.97 → pass security
  • 1 Nov 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 90 to 93. That category is still filling its 30-day observation window: 27 days of observed history at the previous scan, 28 at this one. The score rises as the window fills, whether or not the server changes.

  • 30 Oct 26 0
    • Tool “payment_status” rewrote its description, which is the text the model reads security
    • Tool “quote_invoice” rewrote its description, which is the text the model reads security
    • Tool “supported_coins” rewrote its description, which is the text the model reads security
    • “create_deposit_order” reworded the description of “url” cosmetic
    • “quote_invoice” reworded the description of “url” cosmetic
    • Tool “quote_invoice” changed its title: Quote a Coinbase invoice → Quote an AI service invoice cosmetic
  • 29 Oct 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 80 to 83. That category is still filling its 30-day observation window: 24 days of observed history at the previous scan, 25 at this one. The score rises as the window fills, whether or not the server changes.

  • 27 Oct 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 73 to 77. That category is still filling its 30-day observation window: 22 days of observed history at the previous scan, 23 at this one. The score rises as the window fills, whether or not the server changes.

  • 25 Oct 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 67 to 70. That category is still filling its 30-day observation window: 20 days of observed history at the previous scan, 21 at this one. The score rises as the window fills, whether or not the server changes.

  • 23 Oct 26 +1
    • The server rewrote its instructions, which are the text every model session reads security
    • Tool “create_deposit_order” rewrote its description, which is the text the model reads security
    • Tool “supported_coins” rewrote its description, which is the text the model reads security
Diagnostics

Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.

Captured 4 Nov 2026 · Probed https://mcp.rozo.ai/mcp?src=registry

TLS valid

Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .

Subject Issuer Valid from Valid until Key Signature Serial
CN=rozo.ai CN=WE1,O=Google Trust Services,C=US 4 Oct 2026 2 Jan 2027 ECDSA 256 ECDSA-SHA256 7e7db4c84acf9c0d13bb879adc2d4c69
SANs: rozo.ai, mcp.rozo.ai, *.mcp.rozo.ai
CN=WE1,O=Google Trust Services,C=US (CA) CN=GTS Root R4,O=Google Trust Services LLC,C=US 13 Dec 2023 20 Feb 2029 ECDSA 256 ECDSA-SHA384 7ff31977972c224a76155d13b6d685e3
CN=GTS Root R4,O=Google Trust Services LLC,C=US (CA) CN=GlobalSign Root CA,OU=Root CA,O=GlobalSign nv-sa,C=BE 15 Nov 2023 28 Jan 2028 ECDSA 384 SHA256-RSA 7fe530bf331343bedd821610493d8a1b

Background: What to check on a remote MCP endpoint →

DNSSEC insecure

Validation of mcp.rozo.ai. — Not signed

Zone DS Keys Algorithms Outcome
. trust_anchor 20326, 38696 8, 8 Verified
ai. present 1814, 3799 8, 8 Verified
rozo.ai. absent Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation
Authentication No authorisation required

The endpoint answered without asking for a token. Anyone who knows the URL can reach it.

Result No authorisation required
HTTP status 200

Background: How OAuth 2.1 works in the 2026 MCP spec →

Transports 2 probes
Transport URL Outcome Status Location
streamable-http https://mcp.rozo.ai/mcp?src=registry Verified 200
http (plaintext) http://mcp.rozo.ai/mcp?src=registry HTTPS enforced 301 https://mcp.rozo.ai/mcp?src=registry
MCP tools · 10 exposed · ~2,682 tokens

The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →

Tool Tokens
create_deposit_order ~454

Creates a one-time deposit order; you pay from your own wallet. Returns the deposit address (or Lightning invoice), the exact amount to send (also in base units with the token decimals), any required memo, the expiry and the rozoPaymentId. This server holds no keys and sends nothing. Send exactly the amount, on exactly that chain and token, before expiresAt. An unfunded order simply expires at no cost. For a native coin the result also carries quoteExpiresAt (the end of the price lock, which expiresAt equals): send the exact coin amount before it. Native coins (ETH on Ethereum, Base, Arbitrum; BNB on BNB Chain; POL on Polygon; SOL on Solana) are exact-out like Lightning: the order states the exact coin amount, priced at the current rate plus an FX spread on top of the service fee, and that price holds only until quoteExpiresAt. Native orders are capped at $3500 per invoice (native ETH on Ethereum needs at least $1), and a native coin is offered only when quote_invoice lists it for that invoice. ZEC on Zcash (Beta) is not available through this server: send a payer holding ZEC to https://checkout.rozo.ai/zec.

NameTypeReqDescription
chainIdstringyesSource chain id from supported_coins: "1" Ethereum, "56" BNB Chain, "137" Polygon, "42161" Arbitrum, "900" Solana, "8453" Base, "1500" Stellar, "lightning".
emailstring–Optional contact email so ROZO can reach the payer if the payment needs attention. Ask the user once if they are present; never required, omit it if they decline.
tokenSymbolstringyesToken you will pay with: USDC, USDT, BTC (Lightning), or the chain native coin ETH (1, 8453, 42161), BNB (56), POL (137), SOL (900).
urlstringyesPayment link: https://payments.coinbase.com/payment-links/pl_... or https://payments.coinbase.com/payment-sessions/paymentSession_...

No output schema declared.

No examples provided.

funding_capabilities ~176

What the keyless ROZO Funding API supports right now: whether stellar_onboarding is on, the source chains and USDC assets, the Stellar USDC output, the usdGas options (XLM amounts) and per-order limits. Read-only, creates nothing. Fees come from the quote (fees and totals): never assume a fee. The receiving Stellar address signs ONE transaction (only when it is new or has no USDC trustline). The one-time deposit address is the same on Base, Ethereum, Arbitrum and Polygon; USDC or USDT is accepted 1:1. Follow deposit.amountPolicy: exact or missing means pay the EXACT deposit amount; any_amount uses the suggested amount and returned min/max bounds. Pay once, before payBefore. This server never holds keys: your own wallet pays and signs.

Input schema present but exposes no named parameters.

No output schema declared.

No examples provided.

payment_status ~62

Check a Rozo order by rozoPaymentId: whether the deposit arrived, bridging/payout progress, and whether the OpenRouter or other AI service invoice settled. Read-only.

NameTypeReqDescription
rozoPaymentIdstringyesOrder UUID returned by create_deposit_order.

No output schema declared.

No examples provided.

quote_invoice ~182

Answers what a specific OpenRouter top-up or other AI service invoice charges, whether it can still be paid through Rozo Checkout, and which coins can pay it. Takes the payment link URL and returns the merchant, invoice amount, callerPays (the USD amount the invoice charges), the link expiry, payability and supportedSources: the coins THIS invoice can be paid with. The exact amount to send in a given coin, including the service fee, bridge and network fees, or the FX spread on a native coin, comes from create_deposit_order. Offer a native coin (ETH, BNB, POL, SOL) only when it appears in supportedSources. Creates nothing and moves no funds.

NameTypeReqDescription
urlstringyesPayment link: https://payments.coinbase.com/payment-links/pl_... or https://payments.coinbase.com/payment-sessions/paymentSession_...

No output schema declared.

No examples provided.

stellar_wallet_create_order ~341

Turn an approved quote into a payable order. Returns fundingId (keep it private: it is the only handle to the order), the one-time deposit address, the suggested amount and amountPolicy with minAcceptedAmount/maxPricedAmount when any_amount, payBefore and the accepted chains and tokens. orderId is your own reference: the server derives the upstream order id and Idempotency-Key from quoteId plus orderId, so it only has to be unique among your own orders. Retrying with the same quoteId and orderId returns the same order instead of a second one. Creates an order but moves no funds; an unpaid order expires at no cost. Fees come from the quote (fees and totals): never assume a fee. The receiving Stellar address signs ONE transaction (only when it is new or has no USDC trustline). The one-time deposit address is the same on Base, Ethereum, Arbitrum and Polygon; USDC or USDT is accepted 1:1. Follow deposit.amountPolicy: exact or missing means pay the EXACT deposit amount; any_amount uses the suggested amount and returned min/max bounds. Pay once, before payBefore. This server never holds keys: your own wallet pays and signs.

NameTypeReqDescription
orderIdstringyesYour own order reference, 8 to 128 chars of A-Z a-z 0-9 _ . : -, unique among your orders (for example agent-order-0001). Reuse it with the same quoteId to retry safely.
planDigeststringyesplanDigest from the same quote.
quoteIdstringyesquoteId from stellar_wallet_quote.

No output schema declared.

No examples provided.

stellar_wallet_get_signing_request ~580

When an order shows sign_stellar_onboarding, build the one transaction the receiving address must sign (creates the account if needed, adds the USDC trustline, claims the USDC, delivers XLM). Returns signingRequestId, the unsigned XDR, networkPassphrase, a readable operations list and expiresAt (at most 5 minutes). Sign it with the receiver wallet YOU control (Stellar SDK, Freighter, any wallet); do not modify it. Check the operations first, and decode the XDR locally to confirm it matches them exactly. The transaction source must NOT be your address (it is a ROZO channel account, so ROZO pays the network fee). Allowed, nothing else: ROZO-sourced beginSponsoringFutureReserves and createAccount for your address; from your address, changeTrust for USDC (issuer GA5ZSEJYB37JRC5AVCIA5MOP4RHTM335X2KGX3IHOJAPP5RE34K4KZVN), endSponsoringFutureReserves, claimClaimableBalance, and at most one payment: the sponsor fee in USDC to ROZO claim custody GBLTI2TTQXUAYNKGCQ63YA55KTFEAOQJ3DPBPELNPWCJVE76ADWMXUAE; and a ROZO-sourced XLM payment to your address. Any other operation type or source (setOptions, extra payments): refuse. Amounts: the claimed USDC (gross) equals the current stable leg minimumAmount (order.legs, after repricing) plus the sponsor fee; the sponsor fee is fixed at quote time (0.0000001 USDC with a paid usdGas tier, the quoted stellar_sponsor_fee with usdGas "0", no fee payment if the address needed no onboarding); the XLM payment equals the native (XLM) leg minimumAmount. The XDR shows only the claimable balance id; its amount is in the operations list and on Horizon /claimable_balances/{id}. The hash of the locally decoded transaction (tx.hash() as hex) must equal the txHash of this signing request. Every ROZO-sourced operation and the transaction source must be one of funding_capabilities rozoAccounts (reserveSponsor, xlmPayer, transactionSources). Do not echo fundingId into logs. Expired, or submit failed: just call this tool again; it supersedes the old requ…

NameTypeReqDescription
fundingIdstringyesfundingId of the order.
walletAddressstringyesThe order's receiving Stellar PUBLIC address (G...).

No output schema declared.

No examples provided.

stellar_wallet_order_status ~91

Read a funding order by fundingId: status, pendingActions (sign_stellar_onboarding means the receiver must sign), the deposit, and each leg (USDC, XLM) with its own status, delivered amount and tx hash. Read-only. Poll about every 15 seconds; completed only when every leg is confirmed.

NameTypeReqDescription
fundingIdstringyesfundingId from stellar_wallet_create_order.

No output schema declared.

No examples provided.

stellar_wallet_quote ~385

Price sending USDC/USDT from Base, Ethereum, Arbitrum or Polygon to USDC on a Stellar address. If the address is new or has no USDC trustline, the same plan opens the account, adds the trustline and (with usdGas) gives XLM, in one transaction the address signs once. Returns quoteId and planDigest (needed by stellar_wallet_create_order), the USDC and XLM amounts the receiver gets, every fee line and totals, and whether a signature will be needed. Valid about 10 minutes. Read-only: no deposit address, nothing reserved. usdGas: "0" no XLM, "0.5" or "1" buys XLM (see funding_capabilities for amounts); omitted = the server default. Fees come from the quote (fees and totals): never assume a fee. The receiving Stellar address signs ONE transaction (only when it is new or has no USDC trustline). The one-time deposit address is the same on Base, Ethereum, Arbitrum and Polygon; USDC or USDT is accepted 1:1. Follow deposit.amountPolicy: exact or missing means pay the EXACT deposit amount; any_amount uses the suggested amount and returned min/max bounds. Pay once, before payBefore. This server never holds keys: your own wallet pays and signs.

NameTypeReqDescription
amountUsdstringyesAmount you will send, as a decimal string in USD, e.g. "10" or "10.50". Limits come from funding_capabilities (1 to 1000 today).
receiverAddressstringyesStellar PUBLIC address (G...) that receives the USDC. Never a secret key.
sourceChainstringyesChain you will pay from.
usdGasstring–USD of XLM for fees. Omit to use the server default.

No output schema declared.

No examples provided.

stellar_wallet_submit_signed ~157

Submit the XDR your own wallet signed for a signing request. This is the claim: the account, trustline, USDC and XLM land in that one transaction. Submitting the same signed XDR again is safe (idempotent). Accepts only the signed transaction envelope, never a secret key. "submitted" is not delivery: poll stellar_wallet_order_status until completed. If it answers template_expired or failed, call stellar_wallet_get_signing_request again and sign the new XDR.

NameTypeReqDescription
signedXdrstringyesSigned transaction envelope, base64, as returned by your wallet. NOT a secret key.
signingRequestIdstringyessigningRequestId from stellar_wallet_get_signing_request.

No output schema declared.

No examples provided.

supported_coins ~254

Answers which cryptocurrencies and chains can pay an OpenRouter credit top-up or another AI service invoice through Rozo Checkout: USDC and USDT on Ethereum, BNB Chain, Polygon, Arbitrum and Solana; USDC on Base and Stellar; native ETH (Ethereum, Base, Arbitrum), BNB, POL and SOL; BTC over Lightning. Returns each chain id, token symbol and token decimals. Static list, needs no payment link and makes no network call; quote_invoice reports which of these a specific invoice accepts. Native coins (ETH on Ethereum, Base, Arbitrum; BNB on BNB Chain; POL on Polygon; SOL on Solana) are exact-out like Lightning: the order states the exact coin amount, priced at the current rate plus an FX spread on top of the service fee, and that price holds only until quoteExpiresAt. Native orders are capped at $3500 per invoice (native ETH on Ethereum needs at least $1), and a native coin is offered only when quote_invoice lists it for that invoice. ZEC on Zcash (Beta) is not available through this server: send a payer holding ZEC to https://checkout.rozo.ai/zec.

Input schema present but exposes no named parameters.

No output schema declared.

No examples provided.

Install

How do I install the Rozo Checkout MCP server?

Rozo Checkout is a hosted endpoint at https://mcp.rozo.ai/mcp?src=registry, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

remote · mcp.rozo.ai

# add to Claude Code
claude mcp add --transport http rozoai-checkout 'https://mcp.rozo.ai/mcp?src=registry'
Common questions

What is the Rozo Checkout MCP server?

Rozo Checkout is an MCP server listed in the public MCP registry as io.github.RozoAI/checkout. Pay OpenRouter and Coinbase payment links with USDC, USDT, ETH, BNB, POL, SOL or BTC Lightning. This page covers its hosted endpoint (https://mcp.rozo.ai/mcp?src=registry).

Is the Rozo Checkout MCP server safe to use?

Rozo Checkout scores 82 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

What tools does the Rozo Checkout MCP server expose?

Rozo Checkout exposes 10 tools: supported_coins, quote_invoice, create_deposit_order, payment_status, funding_capabilities, and 5 more. Their descriptions and schemas cost roughly 2,682 tokens of context every time the server is loaded.

Does the Rozo Checkout MCP server require authentication?

No. We connected to Rozo Checkout without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.

Is the Rozo Checkout MCP server still maintained?

Rozo Checkout is still listed as active in the MCP registry. We last reached this channel on 4 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.