Skip to main content
Glama

SoapBox Faith

by io.github.alansafahi

search_sermons

Read-only

Semantically search real sermons on SoapBox that pastors have explicitly opted in to share with AI agents. Returns ranked transcript excerpts with the sermon title, church, speaker, scripture reference, and a start-time (seconds) so you can cite the exact moment. Use this to find what churches are actually preaching on a topic. Only consented, published sermons are searchable.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesA topic, phrase, or question to semantically search sermon transcripts for.
church_idNoOptional SoapBox community id to scope the search to a single church.
match_countNoMaximum number of ranked excerpts to return.

TDQS

A4.5/5.0
Behavior5/5

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

Discloses that only consented, published sermons are searchable and describes the return format (ranked excerpts with title, church, speaker, scripture reference, start-time). This goes beyond the readOnlyHint annotation, adding material context about data provenance and output structure without 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?

Four sentences with each serving a distinct purpose: core function, return fields, usage recommendation, and consent constraint. No redundant or filler content; information is front-loaded with the verb and resource.

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?

No output schema is provided, so the description compensates by detailing exact return fields and the start-time for citation. It also covers the data source scope and consent. This is complete for a search tool, leaving no major informational gaps.

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?

The input schema already provides full descriptions for all three parameters (query, church_id, match_count) with examples and constraints. The description's mention of 'semantic search' adds no new parameter-level meaning beyond what the schema states, so the baseline of 3 applies.

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 'semantically search real sermons on SoapBox' with a specific resource (opted-in sermon transcripts) and output (ranked excerpts with metadata). It differentiates from siblings like get_sermon (retrieving a specific sermon) and find_churches (searching churches) by focusing on topical sermon search.

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?

Explicitly states the use case: 'Use this to find what churches are actually preaching on a topic.' It also mentions the consent constraint. However, it does not explicitly say when not to use it or name alternative tools, so it falls short of a 5.

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
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