Skip to main content
Glama
Sign In

SoapBox Faith

by io.github.alansafahi
OverviewDiscussionsAdmin

pay_with_x402

Idempotent

Pay for a paid sermon or bundle per-call in USDC on Base using the x402 protocol. This is the only TOOL here that buys SoapBox faith content: the prepaid marketplace-credit tools were retired on 2026-07-15 and their endpoints now answer HTTP 410. (A person can instead buy on the item's web_url in a browser.) No SoapBox account or API key is required — the payment IS the credential (https://github.com/coinbase/x402). SoapBox is the Merchant of Record: the church keeps 70% of net and SoapBox takes 30%. This is a content SALE, never a donation — donations go 100% to the church via give_to_church. Works for a single sermon (sermon_id) or a whole series (bundle_id). Two-step, exactly per spec: (1) call with just the sermon_id (or bundle_id) and NO payment to get back the HTTP-402 payment requirements — the USDC amount, asset, network ('base'), and SoapBox's payTo receive address. (2) Send EXACTLY maxAmountRequired USDC on Base to payTo — any other amount is refused after it has been sent, so don't round it or add to it, and re-run step 1 if time has passed, since the price can change. Sign the 402's onchainPayment.message (your tx hash in lower case, and the item) with the wallet that paid, then call again with x_payment set to base64 of {"txHash":"0x...","signature":"0x..."} — SoapBox checks the on-chain transfer came from the signing wallet, records the sale (church keeps 70%), and returns the transcript. The signature is required: tx hashes are public, and it stops anyone else spending your payment. Idempotent per tx hash. Gasless EIP-3009 'exact' payments via an x402 facilitator are also accepted in the same x_payment field.

Input Schema

NameRequiredDescriptionDefault
bundle_idNoThe bundle to pay for. Provide exactly one of sermon_id or bundle_id.
sermon_idNoThe sermon to pay for. Provide exactly one of sermon_id or bundle_id.
x_paymentNoStep 2 only: a base64-encoded JSON x402 payment payload (e.g. base64 of {"txHash":"0x...","signature":"0x..."} for an on-chain Base USDC transfer, signed by the paying wallet as the 402's onchainPayment says, or an EIP-3009 authorization for a facilitator). Omit entirely on step 1 to receive the HTTP-402 payment requirements.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / x_payment / description
      Previous value: -"Step 2 only: a base64-encoded JSON x402 payment payload (e.g. base64 of {\"txHash\":\"0x...\"} for an on-chain Base USDC transfer, or an EIP-3009 authorization for a facilitator). Omit entirely on step 1 to receive the HTTP-402 payment requirements."New value: +"Step 2 only: a base64-encoded JSON x402 payment payload (e.g. base64 of {\"txHash\":\"0x...\",\"signature\":\"0x...\"} for an on-chain Base USDC transfer, signed by the paying wallet as the 402's onchainPayment says, or an EIP-3009 authorization for a facilitator). Omit entirely on step 1 to receive the HTTP-402 payment requirements."
    • changedInput schema / properties / x_payment / examples
      Previous value: -[
-  "eyJ0eEhhc2giOiIweGFiYzEyMy4uLiJ9"
-]New value: +[
+  "eyJ0eEhhc2giOiIweGFiYzEyMy4uLiIsInNpZ25hdHVyZSI6IjB4ZGVmNDU2Li4uIn0="
+]
  2. Changed8 schema fields changed
    • changedInput schema / properties / bundle_id / description
      Previous value: -"The bundle to pay for (omit if paying for a sermon)."New value: +"The bundle to pay for. Provide exactly one of sermon_id or bundle_id."
    • addedInput schema / properties / bundle_id / examples
      Added value: +[
+  "a1b2c3d4-1111-2222-3333-444455556666"
+]
    • addedInput schema / properties / bundle_id / format
      Added value: +"uuid"
    • changedInput schema / properties / sermon_id / description
      Previous value: -"The sermon to pay for (omit if paying for a bundle)."New value: +"The sermon to pay for. Provide exactly one of sermon_id or bundle_id."
    • addedInput schema / properties / sermon_id / examples
      Added value: +[
+  "ffffbeb3-41ee-482a-9c04-a592995ab821"
+]
    • addedInput schema / properties / sermon_id / format
      Added value: +"uuid"
    • changedInput schema / properties / x_payment / description
      Previous value: -"Step 2 only: base64-encoded JSON x402 payment payload (e.g. base64 of {\"txHash\":\"0x...\"} for an on-chain Base USDC transfer, or an EIP-3009 authorization for a facilitator). Omit on step 1 to receive the 402 requirements."New value: +"Step 2 only: a base64-encoded JSON x402 payment payload (e.g. base64 of {\"txHash\":\"0x...\"} for an on-chain Base USDC transfer, or an EIP-3009 authorization for a facilitator). Omit entirely on step 1 to receive the HTTP-402 payment requirements."
    • addedInput schema / properties / x_payment / examples
      Added value: +[
+  "eyJ0eEhhc2giOiIweGFiYzEyMy4uLiJ9"
+]
  3. Added

TDQS

A4.9/5.0
Behavior5/5

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

Even though annotations already indicate readOnlyHint=false, openWorldHint=true, idempotentHint=true, and destructiveHint=false, the description adds substantial behavioral context beyond those hints: the payment-as-credential model, no account/API key required, merchant-of-record fee split, exact-amount enforcement, signature requirement and rationale, idempotency per tx hash, and acceptance of EIP-3009 facilitator payments. It fully discloses the payment flow and consequences of incorrect amounts.

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?

The description is long but every sentence earns its place given the protocol's complexity. It is front-loaded with purpose and key differentiators, then procedurally explains the two steps. It loses one point for being a dense single paragraph that could be structured more explicitly (e.g., numbered steps), but it is not verbose or padded.

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

Completeness5/5

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

Given the tool's complexity, the description is complete: it describes the full two-step workflow, what step 1 returns (HTTP-402 payment requirements), what to send, how to sign, what the server checks, and that the return is a transcript. With no output schema, it covers the return value sufficiently. Annotations cover idempotency and side effects, so nothing essential is missing.

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

Parameters5/5

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

Though schema description coverage is 100%, the description adds crucial meaning to the parameters: it explains sermon_id vs bundle_id mutual exclusivity, the step-1 vs step-2 usage of x_payment, the exact payload shape (base64 of {"txHash":...,"signature":...}), and that EIP-3009 authorizations are also accepted. This goes well beyond the schema's basic field descriptions and directly aids correct invocation.

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?

The description states a specific verb+resource: 'Pay for a paid sermon or bundle per-call in USDC on Base using the x402 protocol.' It also distinguishes from siblings by noting it is the only tool that buys SoapBox faith content, and contrasts with give_to_church (sale vs donation). This leaves no ambiguity about what the tool does or how it differs from alternatives.

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

Usage Guidelines5/5

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

The description explicitly says when to use this tool versus alternatives: it is the only way to buy faith content, mentions retired prepaid-credit tools and the browser fallback, and differentiates from donations. It also provides a clear two-step usage procedure with exact guidance on when to omit x_payment (step 1) and when to include it (step 2), including warnings about exact amounts and re-running step 1 if time passes.

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

All SoapBox Faith toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources