Skip to main content
Glama

Find Scripture for a need, a topic, the words of Jesus, or today

find_scripture_for
Read-onlyIdempotent

PURPOSE: Find the verses that speak to something, read verbatim from the stored text: the hand-picked set for a need or feeling, the house's page on what the Bible says about a topic, what Jesus Himself said about a theme, or the Daily Bread verse every member receives on a date. WHEN TO USE: the person names a feeling, a situation or a topic, or asks for today's verse, without a reference. WHEN NOT: a known reference, exact wording, translations side by side, or checking a quote: read_scripture. A ready-written prayer, a parable, a doctrine or a hard season page: learn_the_faith. Danger to life: get_crisis_help first. MODES (required parameters in brackets): need [subject] matches the person's own words to one of 99 needs ("I am scared about surgery" finds fear) and returns up to limit verses (default 5, max 12), each with a one-line why in the house's words; translation or language read them from another stored Bible. topic [subject] the house's page on one of about 300 topics (shame, money, anger) with its key verses. words_of_jesus [subject] the page on what Jesus said about one theme (love, forgiveness, worry). daily_bread [none] the one verse of a date (date YYYY-MM-DD in the person's own time zone, default today in UTC); translation or language apply. OUTPUT: mode, answered_by, and: need gives need, label, matched, verses [{ref, text, why}], page, pray_with_the_family; topic and words_of_jesus give matched (page path or null), title, url, body (the house's words), verses [{ref, text}], related, and suggestions when nothing matched; daily_bread gives date, ref, text, translation, page. evidence and content_layers keep Scripture apart from the house's words. BEHAVIOR: read only. need and daily_bread read bundled data; topic and words_of_jesus fetch the page from living-bread.org at call time and re-read its verses from the stored KJV. No matching need returns an error listing the needs held; no matching page returns matched null with suggestions. The need text (never a user id) is logged anonymously. Parameters a mode does not use are ignored and named in ignored_params. Access: no sign-in; shared limit of 300 requests a minute per IP.

Input Schema

NameRequiredDescriptionDefault
dateNoFor daily_bread: the calendar day as YYYY-MM-DD in the person's own time zone. Omit for today (UTC).
modeYesWhich kind of answer: need, topic, words_of_jesus, daily_bread. Each mode, and the parameters it needs, is explained in the description.
limitNoFor need: maximum verses, 1 to 12 (default 5).
subjectNoThe need, feeling or topic in the person's own words: "I am anxious", "my mother died", "shame", "forgiveness". Required for need, topic and words_of_jesus.
languageNoThe person's BCP-47 language, e.g. "es", "pt-BR", "sw". Picks the best stored public domain or freely licensed Bible for it; translation wins over it.
translationNoA stored translation id from read_scripture mode translations, e.g. "bsb", "web", "dra", "rv1909", "cuv". Default: the King James Version, or the best stored Bible for language.

Output Schema

NameRequiredDescriptionDefault
okNoAlways true on a successful answer (errors come back as isError, never here).
idsNoUp to 25 ids found in this answer, for follow-up calls.
modeYesThe mode that answered.
licenseNoLicense URL of the returned data (CC BY 4.0 unless stated).
evidenceNoPresent when Scripture was read: translation, canon, corpus version, attribution, and a SHA-256 per passage.
freshnessNoHow current the answer is: kind (scheduled | recently_observed | verified_live | record), retrieved_at, available_now (true only when activity was verified live).
source_urlNoThe first public web page this answer came from or points to.
visibilityNo"public" for shared data, "yours" for the signed-in believer's own data.
answered_byYesThe implementation that answered (the same tool name the signed-in endpoint lists).
attributionNoCredit line for the data: The Living Bread (living-bread.org).
next_actionsNoUp to 4 links the person can open next.
result_stateNo"empty" when nothing matched (count 0, no results); the text then says so plainly.
content_flagsNo["instruction_like_text_removed"] when retrieved text was withheld.
content_layersNoWhich fields are Scripture and which are human interpretation or reflection.
ignored_paramsNoParameters given that this mode does not use.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already establish read-only, idempotent, open-world, non-destructive, but the description adds material behavior they cannot carry: need/daily_bread read bundled data while topic/words_of_jesus fetch living-bread.org at call time and re-read verses from stored KJV; unmatched needs error with a list of held needs; unmatched pages return matched null with suggestions; the need text is logged anonymously; a shared 300 requests/minute per IP limit applies; unused params are ignored and echoed in ignored_params.

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

Conciseness4/5

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

Front-loaded and organized under PURPOSE/WHEN TO USE/WHEN NOT/MODES/OUTPUT/BEHAVIOR headings, so it is scannable despite its length. It is somewhat over-packed, especially the OUTPUT section, which restates return fields that the output schema already covers.

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 four-mode, six-parameter tool with an output schema, everything needed to call it correctly is present: mode selection, per-mode parameter applicability, default and error behavior, and external-fetch semantics. The OUTPUT restatement is redundant given the output schema but not harmful.

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%, so the baseline is 3, but the description goes well beyond it by mapping each parameter to the mode that consumes it (date and limit only for daily_bread/need, subject for need/topic/words_of_jesus) and by explaining semantics the schema cannot: subject matches the person's own words to one of 99 needs, list default 5/max 12, date in the person's time zone defaulting to today UTC, translation winning over language.

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 ('find the verses that speak to something, read verbatim from the stored text') and enumerates the four distinct modes with the entity each one queries. It cleanly separates itself from read_scripture (known reference/lookup) and learn_the_faith (prayers, parables, doctrine), so an agent can route without opening a schema.

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?

Explicit WHEN TO USE (person names a feeling, situation, topic, or asks for today's verse without a reference) and WHEN NOT, naming the alternatives read_scripture, learn_the_faith, and get_crisis_help with the condition that selects each. The danger-to-life triage rule ('get_crisis_help first') is a decisive routing instruction rarely seen.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources