Rokha

Buy access to a paid item

product_checkout

Requires a JWT or an rk_ key. Buy product_id for YOURSELF. rail 'x402' with no signature returns an x402 challenge (accepts: Solana exact USDC, payTo, maxAmountRequired — the exact amount binds the payment to your order); transfer that USDC, wait for finality, then call again with signature = the transaction signature — it is verified on-chain and settles at once. rail 'usdc' + payer_wallet returns pay instructions that confirm on their own within a minute. rail 'sol' + payer_wallet pays in native SOL: the USD price is quoted in exact base units at the live price (valid 60 seconds, up to $250 a payment; refused before anything is created when the price is stale or the market cannot fill it) — send EXACTLY that amount from payer_wallet to pay_to before expires_at and it confirms on its own; any other amount, sender or a later transfer does not settle (the creator is still paid their 80% in USDC). rail 'card' returns a Stripe URL for a human. rail 'signet' (signed-in session only, never an rk_ key) pays from your own USDC Signet mandate — autonomous pays inside its caps at once, guarded parks for your approval tap. Then run the item normally; purchases_mine shows what you hold.

Input Schema

Name	Required	Description
`rail`	Yes	x402, usdc, sol or rokha for an agent (no browser); card returns a Stripe URL for a human; signet pays from your own USDC mandate.
`ref_code`	No	Optional: the handle of whoever referred you — they earn 5% out of Rokha's share, never the creator's.
`signature`	No	x402 rail, second call: the transaction signature of your USDC payment.
`product_id`	Yes	The product's id (product_get).
`payer_wallet`	No	The wallet you will pay from (usdc, sol and rokha rails).

Output Schema

Name	Required	Description
`pay`	No
`mode`	No
`pay_to`	No
`accepts`	No
`product`	No	{id, kind, ref, title, model, price_cents, price, runs_per_pack, active, checkout_url}
`reference`	No
`expires_at`	No
`no_refunds`	No
`checkout_url`	No
`no_refunds_note`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 4, 2026

addedOutput schema / description

Added value: +"The open order on the rail you chose; `mode` names it. usdc / x402 / sol / rokha: reference, pay_to, pay {asset, chain, address, note} and the exact amount (amount_usdc, or quote + the base units) to send before expires_at; x402 with no signature also carries accepts; card: a Stripe checkout_url; x402 with a signature: the settled purchase."

addedOutput schema / properties

Added value: +{
+  "accepts": {
+    "items": {
+      "type": "object"
+    },
+    "type": "array"
+  },
+  "checkout_url": {
+    "type": "string"
+  },
+  "expires_at": {
+    "type": "string"
+  },
+  "mode": {
+    "type": "string"
+  },
+  "no_refunds": {
+    "type": "boolean"
+  },
+  "no_refunds_note": {
+    "type": "string"
+  },
+  "pay": {
+    "type": "object"
+  },
+  "pay_to": {
+    "type": "string"
+  },
+  "product": {
+    "description": "{id, kind, ref, title, model, price_cents, price, runs_per_pack, active, checkout_url}",
+    "type": "object"
+  },
+  "reference": {
+    "type": "string"
+  }
+}

Changed1 schema field changedNov 2, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}

Changed4 schema fields changedOct 29, 2026

addedInput schema / properties / payer_wallet / description

Added value: +"The wallet you will pay from (usdc, sol and rokha rails)."

addedInput schema / properties / product_id / description
```
Added value: +"The product's id (product_get)."
```

addedInput schema / properties / rail / description

Added value: +"x402, usdc, sol or rokha for an agent (no browser); card returns a Stripe URL for a human; signet pays from your own USDC mandate."

addedInput schema / properties / signature / description

Added value: +"x402 rail, second call: the transaction signature of your USDC payment."

Changed1 schema field changedOct 16, 2026

changedInput schema / properties / rail / enum

Previous value: -[
-  "x402",
-  "usdc",
-  "sol",
-  "card",
-  "signet",
-  "fuel"
-]New value: +[
+  "x402",
+  "usdc",
+  "sol",
+  "rokha",
+  "card",
+  "signet"
+]

Changed1 schema field changedOct 16, 2026

addedInput schema / properties / ref_code

Added value: +{
+  "description": "Optional: the handle of whoever referred you — they earn 5% out of Rokha's share, never the creator's.",
+  "type": "string"
+}

Changed1 schema field changedOct 12, 2026

changedInput schema / properties / rail / enum

Previous value: -[
-  "x402",
-  "usdc",
-  "card",
-  "signet",
-  "fuel"
-]New value: +[
+  "x402",
+  "usdc",
+  "sol",
+  "card",
+  "signet",
+  "fuel"
+]

AddedOct 2, 2026

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With destructiveHint=false the annotations say little about a money-moving call, and the description fills that gap thoroughly: auth via JWT or rk_ key, on-chain verification and immediate settlement for x402, self-confirming transfers for usdc/sol, 60-second price validity, a $250 per-payment cap, refusal before anything is created on stale or unfillable prices, and the creator's 80% USDC cut. It also discloses the costly edge cases — wrong amount, wrong sender or a late transfer will not settle — which is exactly the behavior an agent cannot infer elsewhere.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the auth requirement and the core purchase action, and each clause carries distinct operational fact rather than filler. Structure is weaker than the content: one long em-dash-and-semicolon paragraph mixing rail mechanics, pricing rules and settlement caveats is hard to scan under load.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Return values needn't be explained because an output schema exists, and the description covers auth, per-rail mechanics, timing and failure modes comprehensively. The remaining hole is the undocumented 'rokha' rail and the unmentioned ref_code, which the schema documents but the description never situates in the flow.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, and the description genuinely adds sequencing semantics: signature is only meaningful on the x402 second call, payer_wallet only applies to usdc/sol, and rail values map to distinct flows. The gap is that the enum's 'rokha' value is never explained in the description even though it is grouped with the agent rails in the schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Buy product_id for YOURSELF') and immediately frames the tool as a payment-rail selector, which no sibling covers. It also names the follow-up tool (purchases_mine) that answers the adjacent question, so an agent can place it precisely amid product_get, subscribe and purchases_mine.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives per-rail selection conditions in unusual detail: x402 requires the two-call challenge/signature loop, 'usdc' and 'sol' require payer_wallet, 'card' is for a human via Stripe URL, 'signet' is session-only and never an rk_ key. What's missing is an explicit exclusion — nothing says what to do when the item is free or already owned, or that product_get should precede this call.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Rokha tools Inspect

Try in Browser

Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.