Skip to main content
Glama

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 — the AGENT-NATIVE rail, no SoapBox account, API key, or prepaid credits required (https://github.com/coinbase/x402). 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. 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

TableJSON 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.7/5.0
Behavior5/5

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

The description goes far beyond the annotations, detailing the two-step 402 flow, the requirement to send exactly maxAmountRequired, refusal of other amounts, the mandatory signature, idempotency per tx hash, and accepted EIP-3009 gasless payments. This is rich, accurate behavioral disclosure with no contradiction against the annotations.

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

Conciseness5/5

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

Although long, the description is well structured and every sentence earns its place. The core purpose is front-loaded, followed by a numbered two-step flow, clear payment constraints, and the reason the signature is required. The length is justified by the complexity of the protocol.

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?

For a complex payment tool with no output schema, the description is remarkably complete: it covers the full call sequence, exact payment amount and network, recipient address, signing requirements, idempotency, and an alternative payment path. An agent has enough information to invoke both steps correctly.

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, but the description adds meaningful protocol-level meaning: exactly one of sermon_id or bundle_id is required, x_payment must be omitted on step 1, and step 2 requires a base64 payload containing a signed tx hash as described. This goes beyond the schema's property descriptions without being redundant.

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 clearly states a specific action and resource: paying for a sermon or bundle per-call in USDC on Base using x402. It differentiates this rail from SoapBox's account/credit-based flow by explicitly saying no account, API key, or prepaid credits are required.

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?

The description makes the appropriate context clear: agent-native per-call payments without SoapBox credentials, with a precise two-step protocol. It does not explicitly name sibling alternatives like purchase_sermon or purchase_bundle and state when to choose them instead, so it stops short of full when-not-to-use guidance.

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