Skip to main content
Glama
Sign In

SoapBox Faith

by io.github.alansafahi
OverviewDiscussionsAdmin

submit_prayer_request

Post a prayer request to SoapBox's prayer wall ON BEHALF OF A USER, so their community can pray for it. Requires the user's consent_token (which they generate in the SoapBox app and which must include the 'prayer:write' scope) — an API key alone is not enough to act for a user. Returns the new prayer_id; use check_prayer_status to see how many are praying.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "consent_token": "<consent_token>",
      "content": "<content>"
    },
    "name": "submit_prayer_request"
  }
}

Input Schema

NameRequiredDescriptionDefault
contentYesThe prayer request text, in the user's own words. At most 500 characters, the same limit as the app.
is_privateNoIf true, keep it private to the user; if false, post it on their church's prayer wall so its members can pray.
community_idNoPublic requests only: which church's prayer wall to post on. Needed only when the user belongs to more than one church; with one church it is chosen for you. A public request from a user with no church is refused (keep it private instead), and the error lists the choices when there are several.
consent_tokenYesOpaque SoapBox consent token with the 'prayer:write' scope, generated by the user in the SoapBox app (Settings › AI Agents). The first agent key to use a token is bound to it; a token no agent uses within 24 hours of being created stops working. An invalid, expired, or wrong-scope token returns an authorization error.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / community_id
      Added value: +{
+  "description": "Public requests only: which church's prayer wall to post on. Needed only when the user belongs to more than one church; with one church it is chosen for you. A public request from a user with no church is refused (keep it private instead), and the error lists the choices when there are several.",
+  "examples": [
+    "b3095717-5cc0-4213-8964-a01a5ee6b250"
+  ],
+  "format": "uuid",
+  "type": "string"
+}
    • changedInput schema / properties / content / description
      Previous value: -"The prayer request text, in the user's own words."New value: +"The prayer request text, in the user's own words. At most 500 characters, the same limit as the app."
    • changedInput schema / properties / content / maxLength
      Previous value: -2000New value: +500
    • changedInput schema / properties / is_private / description
      Previous value: -"If true, keep it private to the user; if false, share it on the community wall so others can pray."New value: +"If true, keep it private to the user; if false, post it on their church's prayer wall so its members can pray."
  2. Changed2 schema fields changed
    • changedInput schema / properties / consent_token / description
      Previous value: -"Opaque SoapBox consent token with the 'prayer:write' scope, generated by the user in the SoapBox app. An invalid, expired, or wrong-scope token returns an authorization error."New value: +"Opaque SoapBox consent token with the 'prayer:write' scope, generated by the user in the SoapBox app (Settings › AI Agents). The first agent key to use a token is bound to it; a token no agent uses within 24 hours of being created stops working. An invalid, expired, or wrong-scope token returns an authorization error."
    • changedInput schema / properties / consent_token / examples
      Previous value: -[
-  "sbxpr_9f3a2b7c4d5e6f7a…"
-]New value: +[
+  "sbxc_9f3a2b7c4d5e6f7a…"
+]
  3. Changed9 schema fields changed
    • changedInput schema / properties / consent_token / description
      Previous value: -"The user's SoapBox consent token (scope prayer:write)."New value: +"Opaque SoapBox consent token with the 'prayer:write' scope, generated by the user in the SoapBox app. An invalid, expired, or wrong-scope token returns an authorization error."
    • addedInput schema / properties / consent_token / examples
      Added value: +[
+  "sbxpr_9f3a2b7c4d5e6f7a…"
+]
    • addedInput schema / properties / consent_token / minLength
      Added value: +16
    • changedInput schema / properties / content / description
      Previous value: -"The prayer request text."New value: +"The prayer request text, in the user's own words."
    • addedInput schema / properties / content / examples
      Added value: +[
+  "Please pray for my mother's surgery on Friday."
+]
    • addedInput schema / properties / content / maxLength
      Added value: +2000
    • addedInput schema / properties / content / minLength
      Added value: +1
    • addedInput schema / properties / is_private / default
      Added value: +false
    • changedInput schema / properties / is_private / description
      Previous value: -"If true, keep it private to the user (default false = shared so others can pray)."New value: +"If true, keep it private to the user; if false, share it on the community wall so others can pray."
  4. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already supply the safety profile (readOnly false, destructive false, idempotent false); the description adds high-value behavior beyond them: token binding to the first agent, 24-hour expiry for unused tokens, and authorization-error responses. It also states the return value (prayer_id), compensating for the absent output schema.

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?

Three tight sentences with the core action and the critical auth requirement front-loaded, followed by the return value and a next-step pointer. Every sentence carries information.

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?

Despite no output schema, the description names the returned prayer_id and points to the sibling for reporting. Authorization, expiry, and error behavior are all covered, so an agent has everything needed to invoke it correctly.

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

Parameters3/5

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

Schema coverage is 100%, so all four parameters are already documented in detail. The description only reiterates the consent_token scope requirement and adds no syntax or format detail beyond the schema, so the baseline 3 is appropriate.

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 ('Post a prayer request to SoapBox's prayer wall'), plus a crucial scope qualifier ('ON BEHALF OF A USER'). An agent can distinguish this write/action tool from sibling read helpers like check_prayer_status without opening the schema.

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 clear preconditions (must have a consent_token with 'prayer:write' scope; API key alone insufficient) and routes to check_prayer_status for downstream status. It does not explicitly contrast with the sibling compose_prayer_request (drafting) tool, so the when-to-use-vs-alternative is not fully closed.

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