SoapBox Faith

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 USDC on Base to that payTo, then call again with x_payment set to a base64-encoded JSON payload carrying your broadcast Base tx hash ({"txHash":"0x..."}) — SoapBox verifies the on-chain transfer, records the sale (church keeps 70%), and returns the transcript. 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

Name	Required	Description
`bundle_id`	No	The bundle to pay for. Provide exactly one of sermon_id or bundle_id.
`sermon_id`	No	The sermon to pay for. Provide exactly one of sermon_id or bundle_id.
`x_payment`	No	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.

TDQS

A5/5.0

Behavior5/5

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

Beyond annotations (non-read-only, idempotent, open-world), the description reveals critical behaviors: the two-step flow, the need to first receive HTTP-402 requirements, the on-chain verification, revenue split (church keeps 70%), idempotency per tx hash, and gasless EIP-3009 option. This adds substantial context beyond annotations with no contradiction.

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?

The description is well-structured with numbered steps, front-loaded purpose, and every sentence carries essential information—payment mechanics, verification, revenue share, idempotency, and gasless alternative. No unnecessary fluff.

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 (two-step payment, reversible? no output schema), the description is exceptionally complete: covers the exact request/response flow, both payment methods, expected behavior, idempotency, and business outcome. An agent has all necessary context to invoke it correctly.

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?

Schema coverage is 100%, but the description enriches each parameter's meaning: it explains 'x_payment' is only for step 2 and its base64 JSON payload format, clarifies the exclusivity of sermon_id vs bundle_id, and instructs to omit x_payment on step 1. This goes far beyond the schema descriptions.

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 the tool's function: 'Pay for a paid sermon or bundle per-call in USDC on Base using the x402 protocol.' It names the specific verb (pay), resource (sermon or bundle), payment method (USDC on Base), and differentiates from siblings by emphasizing the agent-native, no-account-per-call approach.

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 explains when to use this tool—'per-call' with 'no SoapBox account, API key, or prepaid credits required'—contrasting with account-based alternatives. It also provides a detailed two-step usage protocol, so an agent knows exactly how to invoke it in sequence versus alternatives.

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

All SoapBox Faith tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0

Disambiguation5/5

Every tool targets a distinct action and resource: ask_ora is for Q&A, get_verse for exact verse lookup, verify_scripture for quote checking, lookup_strongs for lexicon entries, and so on. Any potential overlap (e.g., ask_ora vs get_verse) is explicitly addressed in the descriptions.

Naming Consistency5/5

All tool names consistently use a verb_noun or verb_prep_noun pattern (e.g., get_verse, search_sermons, submit_prayer_request, pay_with_x402). No mixing of casing or verb styles is present.

Tool Count3/5

At 19 tools, the set feels heavy. While each tool has a distinct purpose, the breadth spans scripture, sermons, prayers, giving, churches, user context, and audio synthesis. Some functions could be consolidated (e.g., purchase_sermon and purchase_bundle into a single purchase action) or split into separate services.

Completeness4/5

Core workflows are well-covered: discovery, purchase, prayer submission/status, giving, church lookup, and Bible study. However, there are minor gaps such as no way to update or delete prayer requests, no list of previously purchased items, and no general user profile beyond faith context. These are workable but prevent full lifecycle management.

Resources

Need Help?