SoapBox Faith

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

Annotations already declare readOnlyHint=true and destructiveHint=false, ensuring safety. The description adds that ORA is a study aid and not a counselor, but does not elaborate on any behavioral aspects like rate limits or AI nature. It provides adequate context beyond annotations.

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

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

The description is three sentences, each adding value: purpose, nature, and usage guidance. No redundant information. Every sentence earns its place.

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

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

Given no output schema, the description adequately explains what is returned (grounded answer with citations). For a simple single-parameter tool, this is complete and covers the expected behavior.

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

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

Only one parameter 'question' with schema covering it fully (100%). The description adds extra guidance on the type of questions to ask (explanatory/study), which goes beyond the schema's basic description. This provides semantic enrichment for proper usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool is a Scripture study aid for Bible or faith questions, specifies the output (grounded answer with KJV citations), and distinguishes from sibling tool get_verse by advising when to use each. The verb 'Ask ORA' combined with the resource 'Scripture study aid' makes the purpose very specific.

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

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

Explicitly says to use for explanatory/study questions and not for personal crises or pastoral/medical needs, providing guidance to consult a trusted pastor or professional. Also directly contrasts with get_verse, giving a clear alternative.

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

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

Beyond annotations (readOnlyHint, destructiveHint), the description adds that no authentication key is required, specifies the current content scope, and lists return fields, providing useful behavioral context.

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

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

The description is only two sentences, front-loaded with the main purpose, and every sentence adds value without unnecessary words.

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

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

The description covers the tool's purpose, filters, auth requirement, and return structure. It is fairly complete for a browse tool, though it could mention ordering or total count.

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

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

Schema coverage is 100% with each parameter described; the description only repeats 'Optional church_id and text filter' without adding new meaning, so baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool browses purchasable faith-content products on SoapBox, specifies current (sermons) and upcoming items, lists return fields, and distinguishes from purchase_sermon by suggesting follow-up action.

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

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

The description provides clear usage context (optional filters, no key required) and suggests a follow-up tool (purchase_sermon), but does not explicitly mention when not to use or alternatives among siblings like search_sermons.

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

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

Annotations already mark it as readOnlyHint=true and destructiveHint=false. The description adds value by explaining the specific outputs (prayer count and answered status) and the consent_token requirement, enhancing transparency beyond annotations.

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

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

Two concise sentences, front-loaded with the core action, no extraneous information.

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

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

Given no output schema, the description adequately hints at return values (count and answered status) and specifies the required consent_token. For a read-only tool with two parameters, this is nearly complete.

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

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

Schema coverage is 100% with both parameters described. The description does not add significant meaning beyond the schema, as it only reiterates the consent_token requirement in a general context. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks prayer count and answered status for a previously submitted request, using a specific verb+resource and distinguishing it from siblings like submit_prayer_request.

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

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

Explicitly mentions the requirement for the same user's consent_token and that it only returns that user's own prayers, providing clear context. It does not explicitly discuss alternatives, but given the sibling tools, this is sufficient.

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

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

Annotations already mark readOnlyHint=true, destructiveHint=false, openWorldHint=true. Description adds behavioral context: data is from a public directory, no personal contact info, and includes community ID for deep-linking. This goes beyond annotations by clarifying the nature of the data and its limitations.

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

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

Description is a single, well-structured sentence that front-loads the tool's purpose and then lists details. It is concise with no redundant or filler content, earning its place.

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

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

For a simple search tool with no output schema, the description adequately explains what the tool returns and its public data scope. It covers the main behavior without needing to detail edge cases, given the low complexity.

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

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

Input schema has 100% coverage with descriptions for all 5 parameters (lat, lng, limit, denomination, radius_miles). Description reiterates these but adds no new semantic details beyond the schema. Thus, baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Find churches near a location from SoapBox's public church directory' with specific verb+resource. It enumerates returned fields (name, denomination, city/state/country, website, distance, community id), making it distinct from sibling tools that handle prayers, sermons, or financial transactions.

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

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

Description provides clear context: use for finding churches by lat/lng with optional radius and denomination filter. However, it does not explicitly state when not to use this tool or suggest alternatives from the sibling list, leaving some ambiguity for an AI agent.

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

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

Annotations already indicate read-only and non-destructive behavior. The description adds detail on the returned information (balance in cents, tier, daily rate limit), providing value beyond annotations.

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

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

Two sentences, no wasted words. First sentence explains what the tool does, second provides supplementary context on top-ups. Front-loaded and efficient.

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

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

Given no parameters and no output schema, the description covers the tool's purpose and relevant context (top-up alternatives). It mentions the three key pieces of returned data, which is sufficient for a simple check tool.

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

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

No parameters exist (schema coverage 100%), so the description does not need to add parameter info. Baseline score of 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: check marketplace credits, tier, and daily rate limit. It specifies the resource (credits, tier, rate limit) and distinguishes from sibling purchase tools.

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

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

The description implicitly advises using this tool before purchasing to check balance, and mentions alternatives for top-ups. It does not explicitly state when not to use, but the context is clear.

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

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

Discloses that it returns only declared profile, not private prayers or journal. Annotations already mark readOnlyHint=true, but description adds consent and scope details. No contradictions.

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

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

Two concise sentences with front-loaded purpose. Every sentence adds value. No fluff.

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

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

Given single parameter and no output schema, description explains output fields and what is excluded. Consent mechanism fully covered. Complete for a read tool.

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

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

Schema coverage is 100% with a description for consent_token. Description does not significantly add beyond schema; it reiterates scope and binding. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool reads a user's 'faith context' for personalization. The verb 'Read' and resource 'faith context' are specific. It distinguishes from siblings by its unique purpose.

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

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

Explicitly says to use it to tailor tone, tradition, and language. Mentions the consent requirement and scope. Without explicit when-not, but context is clear enough.

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

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

Annotations already indicate readOnly, openWorld=false, and non-destructive. The description adds that no key is required, explains the exclusion of daily readings due to licensing, and clarifies default behavior (today). This provides useful context beyond annotations.

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

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

The description is two sentences with no filler. The first sentence states the core functionality, and the second adds usage context and limitations. It is front-loaded and efficient.

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

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

Given no output schema, the description usefully lists what data is returned (season, color, year, feast). It also mentions what is not included (daily readings). For a simple tool with one optional parameter, this is reasonably complete.

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

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

Schema coverage is 100%, so the description of the single parameter 'date' is already covered by the schema's description. The description redundantly mentions 'defaults to today' but adds no new semantic meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the verb 'Get' and the resource 'Western (Revised Common Lectionary / Roman) liturgical season, liturgical color, RCL year, and any major feast for a date'. It distinguishes from siblings like get_verse or get_sermon by focusing on liturgical data.

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

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

The description states 'Useful for date-aware, season-appropriate faith content', providing context for when to use it. However, it does not explicitly mention when not to use it or suggest alternative tools among the listed siblings.

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

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

Description adds behavioral context beyond annotations: not-found for non-opted-in sermons, paid vs free transcript handling. Annotations already indicate read-only and non-destructive; description enriches with specific scenarios.

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

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

Four sentences, each earning its place: purpose, opt-in constraint, paid scenario, free scenario. Front-loaded with primary purpose. No redundancy.

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

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

For a tool with 2 parameters, no output schema, and no nested objects, the description covers all edge cases (not-found, paid vs free) and directs to sibling tool when needed. No gaps.

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

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

Schema coverage is 100% so baseline 3. Description adds value by explaining that sermon_id comes from search_sermons and that include_transcript defaults true. Also explains the conditional behavior of transcript inclusion based on payment status.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the action ('fetch') and resource ('full metadata and transcript for ONE sermon'), distinguishes from sibling 'search_sermons' which returns multiple. Verb+resource pattern is explicit.

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

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

Explicitly tells when to use (by sermon_id from search_sermons), when transcript is withheld (paid not purchased), and what alternative to use (purchase_sermon). Also mentions opt-in constraint.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds the 'public-domain KJV' context, which is useful but does not disclose other behaviors like version handling or error responses.

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

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

Single 12-word sentence, fully front-loaded with key information. No wasted words.

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

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

For a simple lookup tool with clear schema and annotations, the description is nearly complete. It specifies the Bible version and public domain status. Minor omissions: no mention of return format or error cases.

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

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

Schema description coverage is low (33%), yet the tool description only reiterates 'book, chapter, and verse' without adding parameter-level details. Does not compensate for missing parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the verb 'look up', the resource 'Bible verse', and specifies constraints: public-domain KJV, by book, chapter, verse. It effectively distinguishes from siblings like verify_scripture or get_lectionary.

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

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

No guidance on when to use this tool versus alternatives. Does not mention prerequisites, when not to use, or refer to sibling tools for different purposes.

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

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

The description fully discloses behavioral traits: gift is passthrough (no cut), rejected if over caps, safe to retry with idempotency_key, and amounts in cents. This complements the annotations (idempotentHint=true) and adds depth beyond them.

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

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

The description is five sentences with no redundancy. The first sentence states the core purpose, then flows to requirements, financial details, constraints, and best practice (idempotency). Each sentence adds value.

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

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

The description covers authorization, caps, currency, idempotency, and passthrough nature. It lacks explicit mention of the return value (e.g., confirmation or error) but the schema has no output schema, so this is acceptable. The tool is well-documented for an agent to invoke correctly.

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

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

Despite 100% schema coverage, the description adds critical meaning: it explains the consent_token's required scope and binding, notes the community_id should come from find_churches, clarifies that idempotency_key prevents double-charging, and emphasizes amount is in cents. This goes well beyond the schema's basic descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a one-time donation to a church on behalf of a user. It specifies the action (donate), the target (church via SoapBox community), and the delegation aspect. This distinguishes it from other payment-related tools like pay_with_x402.

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

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

The description explains the tool is used for making a donation within pre-authorized caps, requires a consent token with giving:write scope and a saved card, and that it is rejected if caps are exceeded. It doesn't explicitly list when not to use, but the context is clear. It implies alternatives like find_churches for getting the community ID.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds behavioral context by listing the fields returned (lemma, transliteration, gloss, definition), which is beyond the annotations. No contradictions.

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

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

The description is a single, front-loaded sentence with no unnecessary words. Every part is essential.

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

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

For a simple lookup tool with one parameter and no output schema, the description adequately covers the return values and is complete for the complexity level.

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

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

Schema coverage is 100% with a clear description for strongs_number. The description adds no extra meaning beyond the schema's example; baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Look up'), the resource ('Strong's Greek/Hebrew lexicon entry'), and the returned fields (lemma, transliteration, gloss, definition). It distinguishes from sibling tools like get_verse or search_sermons.

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

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

The description implies usage context (when a Strong's lexicon entry is needed) but provides no explicit guidance on when to use or avoid this tool, nor does it mention alternatives.

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

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

The description goes well beyond annotations by detailing the two-step protocol, idempotency per tx hash, acceptance of gasless EIP-3009 payments, the revenue split (church keeps 70%), and the return of the transcript. It adds significant behavioral context not captured in annotations.

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

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

The description is well-structured, front-loading the purpose and then detailing the two-step process. While comprehensive, it is slightly verbose; a few sentences could be trimmed without losing meaning.

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

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

Given the tool's complexity (3 parameters, no output schema), the description fully covers the two-step protocol, parameter usage, idempotency, alternative payment methods, and even the revenue split. It leaves no critical gaps for an agent to misuse the tool.

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

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

Schema coverage is 100% and each parameter has a description. The description adds value by explaining the overall protocol and sequencing (step 1 vs step 2), which integrates the parameters into a coherent workflow. This surpasses the baseline of 3 for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: paying for a sermon or bundle per-call in USDC on Base using the x402 protocol. It distinguishes itself from siblings by emphasizing the agent-native nature, requiring no SoapBox account or credits, which differentiates it from purchase_bundle and purchase_sermon.

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

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

The description provides clear context on when to use the tool (agent-native, no account needed) and the two-step process. However, it lacks explicit exclusion of alternatives or direct comparison to purchase_sermon/purchase_bundle, which would strengthen guidance.

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

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

Discloses idempotency (matches annotation), financial split (70/30), that it's a content sale not donation, and grants access to all sermons. Adds value beyond annotations.

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

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

Concise and well-structured with each sentence adding distinct info. Slight wordiness in alternative payment part, but overall efficient.

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

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

Covers main aspects: action, scope, comparison, idempotency, source of id, alternative. Lacks explicit return value info but acceptable given no output schema.

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

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

Schema coverage is 100% and already describes bundle_id as product_id from browse_catalog. Description adds minimal extra, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it buys a bundle (sermon series) using prepaid credits, grants access to all sermons, and distinguishes from purchase_sermon by mentioning bundle vs individual sermon and same terms.

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

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

Explicitly tells when to use (buying a bundle) and provides alternative (pay_with_x402 if no credits). Also directs to find bundles via browse_catalog. No ambiguity.

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

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

The description fully explains behavioral traits: it is a content sale (not donation) with fee breakdown (70/30), idempotency, and post-purchase effect (get_sermon returns transcript). Annotations already declare idempotentHint=true and destructiveHint=false; the description adds valuable context 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.

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

The description is well-structured with a clear opening action followed by important details (fees, post-purchase, idempotency, error handling, alternative). It is somewhat verbose but every sentence adds value, earning a high score for structure over strict conciseness.

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

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

Given the tool's complexity (payment, fee structure, idempotency, alternative payment), the description covers all critical aspects: purchase mechanics, outcome, error handling, and fallback option. No output schema exists, but the description mentions get_sermon provides the result, completing the context.

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

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

The sole parameter (sermon_id) has a schema description stating it comes from search_sermons results, which matches the description's hint. With 100% schema coverage, the description adds minimal new meaning beyond the schema, justifying a baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Buy permanent access to a paid sermon using your prepaid marketplace credits.' It specifies the action (buy), resource (sermon), and payment method (credits), distinguishing it from siblings like pay_with_x402 (alternative payment) and get_sermon (retrieval after purchase).

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

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

The description provides explicit when-to-use and when-not-to-use guidance: suggests checking get_credit_balance if insufficient credits, and directs to pay_with_x402 as an alternative for users without keys/credits. It also notes idempotency to avoid double-charge concerns.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that the tool is impartial and requires no key, which provides some behavioral context beyond the annotations but not extensively.

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

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

Three sentences efficiently convey the tool's core function, output, and nature. Every sentence adds value with no redundancy or filler.

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

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

The description adequately explains the return values and parameter purposes. Since there is no output schema, the description covers the main outputs. Minor gaps exist (e.g., no rating scale details), but overall it is complete for a simple tool.

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

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

With 100% schema description coverage, the schema already documents both parameters. The description does not add additional meaning, examples, or format details beyond what is in the schema, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description specifies the verb 'assess' and the resource 'statement alignment with a named Christian tradition's historic doctrinal positions', listing example traditions. It also clearly states what is returned (alignment rating, score, summary, doctrinal loci), fully distinguishing it from sibling tools like verify_scripture or get_faith_context.

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

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

The description provides clear context for use (analytical, not proselytizing) and implies appropriate scenarios. However, it does not explicitly list when not to use or suggest alternatives, though the unique purpose makes such guidance less critical.

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

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

Beyond the annotations (readOnlyHint, destructiveHint), the description reveals behavioral traits: it only searches consented, published sermons; returns ranked transcript excerpts with specific metadata; and enables citing exact moments via start-time. No contradictions with annotations.

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

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

The description is concise (4 sentences) and front-loaded with the primary action and key constraint. It could be slightly more compact, but it efficiently conveys essential information without redundancy.

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

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

Given the complexity (3 parameters, no output schema) and sibling context, the description is complete. It covers the tool's purpose, source constraints, return format, and use case. No output schema is needed because the description explains what is returned.

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

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

The input schema has 100% parameter description coverage, so the baseline is 3. The description does not add new information beyond the schema's parameter descriptions; it mentions 'query' indirectly but no extra semantics for 'church_id' or 'match_count'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs semantic search on consented sermons, returning specific fields (title, church, speaker, scripture reference, start-time). It distinguishes itself from siblings like 'get_sermon' (retrieve specific sermon) and 'find_churches' (search churches) by focusing on sermonic content.

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

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

The description explicitly says 'Use this to find what churches are actually preaching on a topic,' providing clear context for when to use the tool. However, it does not mention when to avoid this tool or suggest alternatives, which would earn a 5.

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

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

Annotations provide no hints (all false), so the description carries full burden. It discloses the authentication requirement, the act of posting on behalf of a user (implying state change), and the return of a prayer_id. No contradictions.

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

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

Two sentences with no redundancy. First sentence states purpose and key constraint; second sentence clarifies authentication and return value. Front-loaded and efficient.

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

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

Given the tool's low complexity (3 parameters, no output schema), the description is complete: covers input requirements, return value, and references a sibling tool for further action. Missing error handling details but not essential for basic usage.

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

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

Schema covers all 3 parameters (100%). The description adds value by explaining the consent_token requirement in detail (scope prayer:write) and the implied purpose of each parameter (e.g., content as the prayer text).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool posts a prayer request on behalf of a user to the prayer wall, using a consent token. It distinguishes itself from siblings by specifying the on-behalf-of action and referencing check_prayer_status for follow-up.

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

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

The description provides clear context on when to use—requires a valid consent_token with prayer:write scope. It mentions an alternative (check_prayer_status) for status, but does not explicitly state when not to use this tool versus other sibling tools.

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

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

Annotations declare idempotentHint=true and destructiveHint=false. The description adds that results are cached (explaining idempotency) and notes the real cost and API key requirement, which are beyond annotation info. No contradictions.

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

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

Three sentences, front-loaded with main purpose, minimal waste. Could combine first two sentences but overall efficient.

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

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

Given no output schema, the description covers return format (playable audio URL), caching, cost, and required auth. It could mention the character limit from schema, but otherwise complete for a TTS tool with good annotations.

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

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

Schema coverage is 100%, so the description adds minimal value. It gives examples for language (en-US, es-ES) and mentions optional voice/gender, but these are already clear from parameter types and descriptions. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool generates spoken audio for religious texts in 50+ languages and returns a playable URL. It uses specific verbs (Generate, get back) and resources (spoken-audio, audio URL), distinguishing it from sibling tools like get_verse or submit_prayer_request.

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

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

The description provides clear context: pass BCP-47 language, optional voice/gender, and notes caching and API key requirement due to cost. However, it does not explicitly state when not to use this tool or mention the 2000 character limit (present in schema).

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

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

Describes all key outputs and anti-hallucination purpose, consistent with readOnlyHint annotation. No contradictions.

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

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

Two concise sentences covering purpose, returns, and usage. No unnecessary words.

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

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

With no output schema, description adequately covers return values and context. Annotations confirm safe read operation.

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

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

Adds meaning beyond schema: explains quote is the text to verify, reference is optional claimed citation, and the tool checks attribution when provided. Schema coverage is 100%, but description enriches understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool verifies whether a quote is real Scripture and cited correctly, with specific outputs like KJV reference, confidence score, and attribution check. It differentiates from siblings like get_verse.

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

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

Explicitly advises use before presenting any Bible quote to avoid misquotes, providing clear when-to-use context. Does not specify when not to use or alternatives, but context is sufficient.

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