Study Bible MCP Server
Study Bible MCP Server turns Claude into a Bible study assistant with original-language texts, scholarly lexicons, commentary, cross-references, and biblical genealogy/geography graphs.
Verse lookup (
lookup_verse): retrieve any verse, range, or chapter with BSB English, original Greek/Hebrew, word-by-word Strong's analysis, optional morphology, and genre-specific interpretation guidanceOriginal-language word studies (
word_study,search_lexicon,search_by_strongs): deep LSJ/BDB/Abbott-Smith definitions, transliteration, etymology, synonyms, and every verse where a word appearsWord usage discovery (
search_by_strongs): find all passages containing a given Greek/Hebrew termGrammar parsing (
parse_morphology): explain Greek (Robinson) and Hebrew morphology codes likeV-AAI-3SCross-references (
get_cross_references): scripture-interprets-scripture links by verse (CH, TSK, Gage, Burnett, tiered by strength) or by six curated theological themesScholarly commentary (
get_study_notes,get_bible_dictionary,get_key_terms): Aquifer/Tyndale study notes, translation notes, 500+ dictionary articles, and 200+ key theological term definitionsAncient Near East cultural background (
get_ane_context): structured context across 12 dimensions and 9 historical periodsTheological scholarship (
get_theology_context): attributed summaries from Heiser, Bradley, Burnett, Owen, Stott, and LennoxBiblical people and names (
lookup_name,people_in_passage,graph_enriched_search): identities, variant names, roles, and everyone/place/event in a passageGenealogy and relationships (
explore_genealogy,find_connection): multi-generational family trees and shortest relationship paths, with Mermaid diagramsPeople, places, and timelines (
explore_person_events,explore_place): chronological life events and full location historiesSemantic search (
find_similar_passages): vector-embedding discovery of thematically similar passages, with hermeneutical warningsStructural parallels (
get_torah_weave): Moshe Kline's Woven Torah horizontal/vertical partner cells for any Torah passageTextual criticism (
get_textual_variant): MT vs LXX/DSS readings, manuscript witnesses, and NT-quotation alignment for contested verses
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Study Bible MCP ServerWhat does the Greek word 'agape' mean in 1 Corinthians 13?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Study Bible MCP Server
A Bible study assistant for Claude that provides full scholarly lexicons (LSJ Greek, BDB Hebrew, Abbott-Smith NT Greek), morphologically-tagged biblical texts, cross-references, Theographic genealogy graphs, Aquifer Open Study Notes, a Bible dictionary, key theological terms, Ancient Near East cultural context, and hermeneutical methodology based on Fee & Stuart's "How to Read the Bible for All Its Worth".
Quick Start
Claude Desktop
Open Settings → Connectors
Click Add Custom Connector
Paste:
https://studybible-mcp.fly.dev/mcp/Restart Claude Desktop
That's it. No signup, no API keys, no downloads.
Claude Code
claude mcp add --transport http study-bible https://studybible-mcp.fly.dev/mcp/ChatGPT (Developer Mode)
Open Settings → Developer Mode → enable it
Go to Actions → Add MCP Server
Enter URL:
https://studybible-mcp.fly.dev/mcp/
Cursor / Windsurf / Cline
Add to your MCP configuration (usually .cursor/mcp.json, .windsurf/mcp.json, or Cline settings):
{
"mcpServers": {
"study-bible": {
"command": "npx",
"args": ["-y", "mcp-remote", "https://studybible-mcp.fly.dev/mcp/"]
}
}
}Install via pip / uvx (local stdio)
pip install studybible-mcp
studybible-mcp --transport stdioOr run directly without installing:
uvx studybible-mcp --transport stdioManual Config (Alternative)
If you prefer editing config files directly:
{
"mcpServers": {
"study-bible": {
"command": "npx",
"args": ["-y", "mcp-remote", "https://studybible-mcp.fly.dev/mcp/"]
}
}
}Config file locations:
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.jsonLinux:
~/.config/Claude/claude_desktop_config.json
Transports
Endpoint | Transport | Status |
| Streamable HTTP (stateless; | Recommended |
| Legacy HTTP+SSE | Deprecated: still served for existing connectors, but will be removed. Re-add the connector with the |
| stdio (local) | Supported |
Related MCP server: learners-mcp
How It Works
Architecture Overview
┌─────────────────────┐ ┌──────────────────────────────────────────┐
│ Claude Desktop │ │ Study Bible MCP Server │
│ or Claude Code │ │ (Fly.io) │
│ │ │ │
│ ┌───────────────┐ │ MCP │ ┌─────────────┐ ┌───────────────────┐ │
│ │ User asks a │──┼─────┼─▶│ MCP Server │─▶│ SQLite DB (600+MB)│ │
│ │ Bible question│ │ │ │ (Python) │ │ │ │
│ └───────────────┘ │ │ └─────────────┘ │ • Lexicons (LSJ, │ │
│ │ │ │ │ BDB, Abbott- │ │
│ ┌───────────────┐ │ │ ▼ │ Smith, Strong's) │ │
│ │ Claude uses │◀─┼─────┼── Tool Results │ • Tagged NT + OT │ │
│ │ study tools to│ │ │ │ • Names + ACAI │ │
│ │ answer │ │ │ │ • Morphology │ │
│ └───────────────┘ │ │ │ • Study Notes │ │
│ │ │ │ • Bible Dictionary │ │
│ │ │ │ • Key Terms │ │
│ │ │ │ • ANE Context │ │
│ │ │ │ • Embeddings │ │
│ │ │ └───────────────────┘ │
└─────────────────────┘ └──────────────────────────────────────────┘When you ask Claude a Bible question:
Claude analyses your question and decides which tools to use
Claude calls the appropriate MCP tools (e.g.,
lookup_verse,word_study,get_study_notes)The server queries the pre-built SQLite database
Results are returned to Claude
Claude synthesises the data into a helpful response
See ARCHITECTURE.md for a full Mermaid flowchart of the available tools and how the agent chains them together.
The Database
The server includes a pre-built SQLite database (~600MB) containing:
Table | Rows | Content |
| 19,391 | Greek (Full LSJ + Abbott-Smith NT) and Hebrew (Full BDB) word definitions with Strong's numbers |
| 31,280 | Every verse of the Bible with morphology tags |
| 31,086 | Berean Standard Bible text, the English the verse tools show |
| 5,290 | Verses grouped by ancient section markers |
| 4,299 | Biblical people, places, and things |
| 2,768 | Grammatical parsing code definitions |
| 22 | Core theological theme cross-references |
| 102,673 | Study notes, dictionary articles, translation notes, key terms |
| 6,019 | Rich entity annotations (people, places, groups, key terms) |
| 87 | Ancient Near East cultural context entries across 12 dimensions |
| 314 | Maps ANE entries to biblical books and chapter ranges |
| 86 | Moshe Kline's Torah Weave literary units (dataset version 1.1) |
| 1,019 | Their cells and subdivisions, with Hebrew-numbered verse ranges |
| 31,280 | OpenAI embeddings for semantic search |
| 5,190 | OpenAI embeddings for passage similarity |
You can download the pre-built database directly: study_bible.db (~750MB)
The database includes CC BY-NC 4.0 material (the ETCBC Dead Sea Scrolls
transcription and the Metsudah Chumash English), for non-commercial use only,
and CC BY-SA 4.0 material (Perseus Josephus, First1KGreek Philo, Latin
Wikisource 4 Ezra), which must be shared alike. The download response repeats
this in an X-Data-License-Notice header.
Available Tools
Core Text & Language
1. lookup_verse
Retrieve a verse, verse range, or whole chapter with its original language text and word-by-word analysis.
When Claude uses it: User asks about a specific verse or passage, wants to see the Greek or Hebrew text, or asks about specific words in a passage.
Accepted references: a verse (John 3:16), a range within a chapter (Luke 19:1-3; an en dash also works), a cross-chapter range (Luke 19:45-20:2), or whole chapters (Psalm 23, Psalm 23-24). Single-chapter books (Obadiah, Philemon, 2 John, 3 John, Jude) may be cited by verse alone, as is conventional: Jude 3 means Jude 1:3 and a bare Jude means the whole book. This applies to every tool's reference argument. Verses are matched by English chapter/verse numbering, so Old Testament verses whose Hebrew numbering differs (e.g. Psalm 40:6, stored as Psa.40.6(40.7)) are found, and an English verse stored as several source rows returns all of them. A Psalm superscription, which is verse 1 in the Hebrew, is headed as such (Psa.82 superscription (Hebrew Psa.82.1)). A passage returns at most 50 verses; longer requests (e.g. Psalm 119) open with a note naming the reference that continues the passage. Unknown books, missing chapters or verses, and reversed ranges get a message saying what exists.
What it returns: English text from the Berean Standard Bible (labelled (BSB) once per response; STEPBible's word-by-word gloss, marked [gloss], stands in for the few verses the BSB lacks, such as Psalm superscriptions and Matthew 17:21), original Greek/Hebrew text, word-by-word breakdown with Strong's numbers, optional morphological parsing, and genre-specific interpretation guidance. Notes about cross-references, Torah Weave partners, and NT/OT LXX quotations appear once per lookup; for a passage they name a verse to pass to those single-verse tools.
Example:
User: "Look up Romans 8:28 with the Greek"
Claude calls: lookup_verse(reference="Romans 8:28", include_original=true)
Returns:
- Verse text in English
- Greek: πάντα συνεργεῖ εἰς ἀγαθόν...
- Word analysis: συνεργεῖ (G4903) = "works together" [V-PAI-3S]
- Genre guidance: "Epistles - What problem was being addressed?"compare_biblical_versions
Compare the Masoretic Text and Septuagint with explicit per-verse provenance.
Covers Old Testament and Septuagint books only. Rows that share a canonical
(MT/English) reference appear under one header, while each row keeps its own
edition reference, so Hebrew/Greek Psalm numbering and other mapped
versification shifts stay visible. Psalm 82:6, for example, shows MT Psa.82.6
and LXX Psa.81.6; Psalm 40:6 shows MT Psa.40.7 (Hebrew numbering) and LXX
Psa.39.7.
compare_biblical_versions(
reference="Psalm 24:1", # also "Psalm 82:1-8", "Psalm 81:6-82:1", "Psalm 82"
versions=["MT", "LXX"],
numbering="canonical", # or "lxx" to read the reference in Greek numbering
include_original=true,
include_morphology=false
)Each edition row names its version, edition, and edition reference (plus the
versification mapping whenever it is not identity), then its original text and
English. Licences, source URLs, translation labels, the verse-mapping credit, and
the Brenton caveat are listed once in a closing Sources block rather than on
every row. A call returns at most 10 verses; a longer range or chapter is cut
there with a note naming the verse to continue from.
MT comes from the STEPBible TAHOT verses already in the database (Westminster Leningrad Codex). Its English is STEPBible word glosses (interlinear, not a translation).
LXX covers all 59 books of the Rahlfs source edition. Brenton's English is shown only for the recension Brenton translated (Theodotion for Daniel, Susanna and Bel; Vaticanus B for Joshua and Judges); Old Greek and Alexandrinus rows say the translation is not available for that edition.
Brenton's English is not a translation of the Rahlfs text. Brenton (1844) translated his own Greek edition, based chiefly on Codex Vaticanus, and his English sometimes departs even from that Greek. Every row with his English carries a note saying so. Each such verse is also compared with Brenton's own Greek after spelling noise is removed: accents, breathings, case, punctuation, elision, movable nu, itacism (ει/ι), doubled consonants, nasal assimilation, crasis, Hellenistic spellings (λήμψομαι/λήψομαι), word division (ἀνὰ μέσον/ἀναμέσον), name spellings, and one-letter keying errors in Brenton's digital text. Where his Greek still adds, lacks, substitutes, or reorders words, the row shows a warning, a difference summary, and Brenton's Greek as the text his English translates. Deuteronomy 32:43, for example, reports "word order differs (υἱοὶ ἄγγελοι)", and Psalm 40:6 reports "Brenton's Greek reads σῶμα for ὠτία". Differing verse divisions do not count as differences. 8,914 of the 23,684 rows with Brenton's own English (38%) are flagged. Unflagged rows can still differ, because a Greek-to-Greek comparison cannot see where his English departs from his own Greek.
Most Apocrypha English is the KJV, not Brenton's translation. For 1 Esdras, 1–2 Maccabees, Baruch, Bel, Judith, the Letter of Jeremiah, Sirach, Susanna, Tobit, Wisdom, and Daniel 3:24–90 (the Prayer of Azariah and Song of the Three), Brenton's edition prints the KJV (Authorized Version) Apocrypha, lightly adapted by Brenton (verse-by-verse similarity to the KJV is 92–100%, against 24–49% for his own Hebrew-canon translations). The KJV was translated from other Greek texts, so it can contain words neither the Rahlfs nor Brenton's Greek has: Sirach 17:17 adds "in the division of the nations of the whole earth". These 4,630 rows label the English "KJV Apocrypha", are named in the Sources block with one closing note, and are not compared with Brenton's Greek. Greek Esther and 3–4 Maccabees are Brenton's own translation.
Apocrypha rows are marked. Rows outside the 66-book Protestant canon (the Septuagint-only books, the Greek additions to Esther, Daniel 3:24–90, Psalm 151, and Odes 7–8, 12 and 14) end their header with "(Apocrypha)", and the closing block adds one line saying they are not in the Protestant canon (cf. Westminster Confession 1.3). Other Septuagint pluses in canonical books (3 Kingdoms 2:35a–o, Proverbs 9:12a–c, ...) are textual variants and are not marked.
LXX-only verses (pluses such as the Prayer of Azariah, Psalm 151, and the Septuagint-only books) have no canonical MT position, so they never appear as the counterpart of a different MT verse. Request them with
numbering="lxx"; a canonical lookup notes when such verses sit at the same Greek-numbered position. Septuagint-only books (Tobit, Sirach, ...) always use Greek numbering.
New Testament references, unparseable references, and references with no
matching verses each return a specific message. A database without the
Septuagint table tells you to run python scripts/upgrade_database.py.
search_ancient_sources
Search licensed primary-source corpora for Jewish history. corpus is any
registered corpus key or all; the registry (src/study_bible_mcp/corpora/)
currently holds josephus: 2,304 Whiston sections from Jewish Antiquities,
The Jewish War, Life, and Against Apion. Each section is paired with
every Niese Greek section it spans and referenced as a Niese span plus
Whiston's numbering, e.g. Antiquities 15.317–322 (Whiston 15.9.3). targum
holds Targum Onkelos on the five books of the Torah: 5,846 Aramaic verse
passages with the CC BY-NC Metsudah English, an English of the Hebrew in which
Onkelos's own renderings are marked ⟨…⟩ (see Targums), each
linked to the verse it translates. qumran
holds 44 Hebrew manuscript columns with numbered lines, no English translation
included: the Damascus Document (CD 1:1–21, Genizah MS A columns 1–16
and MS B columns 19–20), the Community Rule (1QS), the Rule of the
Congregation (1QSa) and Pesher Habakkuk (1QpHab), all from the ETCBC/dss
transcription; 32 curated links name the Habakkuk verses each 1QpHab lemma
quotes. philo holds the 31 Greek treatises of Philo of Alexandria
(Cohn–Wendland, via First1KGreek), one passage per Cohn–Wendland section with
the same section of Yonge's English (7,901 passages; 58 sections of Spec. 1–2
that Yonge's text lacks are Greek only). pseudepigrapha holds 1 Enoch in
R. H. Charles's English, one passage per Charles verse, and 4 Ezra (2 Esdras
3–14) in the KJV with the Clementine Latin, one passage per verse (1,679
passages); both works are non-canonical and are labelled as attributed to
Enoch or Ezra. The
rabbinic corpus holds the Mishnah from Sefaria (63 tractates, one passage per
mishnah). Each result gives its citation and, on the line below, its
canon-and-date tag (e.g. *Not Scripture · Jewish pseudepigraphon (Parables, c. 50 BC–AD 117, debated) · tier A/B · Charles 1912*), then up to 1,500
characters of English around the first match and a shorter original-language
excerpt (match-centred when the query is in the original's script; a passage
without English shows its original instead), any editorial ⚠ notes, and its
typed biblical links. A closing Caveats block prints each corpus's caveat
and the date tiers present once, and a Sources block lists the edition,
translation, license (non-commercial licences marked and linked), and pinned
source once. Up to 4 passages are returned by default, within a
12,000-character budget (see Ancient sources).
search_ancient_sources(
query="John Baptist",
corpus="josephus",
biblical_reference="Mark 6:20",
period="second_temple",
limit=4
)Only the passage text is searched, so a word that appears only in a work
title (Jewish, War, Life) does not match every passage of that work.
English search is stemmed (build matches building); Greek, Hebrew, and
Aramaic search ignores accents, breathings, vowel points, cantillation, and case
(βαπτισμω matches βαπτισμῷ), and editorial signs printed inside a word
(יעבורו matches the corrected י{{א}}<<ע>>בורו); Qumran text in [ ] is a
modern reconstruction and is never matched. Passages containing every query word come
first; when none do, passages matching any word are returned with an explicit
note. Only when the exact search finds nothing is a Hebrew or Aramaic word
retried with one or two attached prefix letters (ו ב ה ל מ כ ש) stripped from
the indexed words, keeping at least three letters (הון then finds ובהון);
those results are marked (prefix match), because a root letter can look like
a prefix (קדש finds מקדש). biblical_reference accepts a chapter, verse,
or range (Luke 21, Luke 21:5, Luke 21:5-6, Jude 6) and filters to
editorial links: curated links (33 for Josephus, 2 for the rabbinic corpus),
each checked against the linked passage text, links from
corpora/editorial_notes.json, and one "Translation of" link per targum
verse, derived from its verse key (biblical_reference="Deuteronomy 32:8"
with corpus="targum" finds Onkelos on that verse). Each link is typed —
Aligned, Echo, Shared tradition, Contrast, or Translation of — and
printed as e.g. - Shared tradition: Mark 6:17–29 — Related account: death of John the Baptist. Period tags,
biblical links, and editorial chapter headings (Whiston's, for Josephus) are
labelled editorial metadata; they are not presented as claims made by the
ancient author. Empty results say whether the corpus is missing, the reference
is unsupported, the reference has no curated link, or nothing matched.
lookup_ancient_source
Read an ancient-source passage by its citation. A citation is a work name or
abbreviation plus a locator in that work's numbering; an author prefix is
optional. For Josephus: Antiquities/Ant./A.J., War/B.J./J.W., and
Against Apion/C. Ap. take Niese book.section; Life/Vita takes a
section.
For Targum Onkelos, Targum Onkelos/Onkelos/Tg. Onq. precedes a Torah
book (Genesis/Gen, Exodus/Exod, Leviticus/Lev, Numbers/Num,
Deuteronomy/Deut) and chapter:verse; the prefix is optional, so a bare
Genesis 1:1 also finds Onkelos. Onkelos is cited by English verse numbers,
like the rest of the server; where Sefaria's Hebrew (MT) numbering differs,
the heading and link show it: Targum Onkelos Exodus 8:5 (MT 8:1), and the
Peniel verse is Onkelos Genesis 32:30 (MT 32:31). Sefaria joins the four
short commandments into one verse, served as Exodus 20:13–16 and
Deuteronomy 5:17–20. For Qumran: CD/Damascus Document/Zadokite Fragments, 1QS/
Community Rule, 1QSa/1Q28a/Rule of the Congregation, and
1QpHab/Pesher Habakkuk take column:line, with Arabic or Roman column
numbers (CD 6:11, CD VI 11, 1QpHab VII 1-5); a line citation shows the
cited lines ±2 from the column that contains them, and a column citation
(CD 6) the whole column, with the line numbers in the text.
For Philo, SBL short titles, Latin titles, and English titles
(Opif./De Opificio Mundi/On the Creation of the World, Legat./Leg. Gai., Her./Heres, ...) take a Cohn–Wendland section; the multi-book works
Leg. 1–3, Somn. 1–2, Mos. 1–2, and Spec. 1–4 take book.section; a
book number the work lacks (Leg. 31, likewise Ant. 21.1) is rejected
rather than read as a book.
1 Enoch/1 En. and 4 Ezra/2 Esdras/4 Esdras take chapter:verse.
4 Ezra 3–14 is 2 Esdras 3–14 with the same chapter numbers, so 2 Esdras 11:1
and 4 Ezra 11:1 are the same passage; 2 Esdras 1–2 and 15–16 (5 and 6 Ezra)
are not included. 4 Ezra is cited in modern (Bensly) numbering: the KJV and
Clementine Latin lack the "missing fragment" 7:36–105, so their 7:36–70 is
4 Ezra 7:106–140, shown as e.g. 4 Ezra 7:106 (KJV 2 Esdras 7:36). A 4 Ezra
citation outside the served text says what is missing and why.
For the Mishnah, a tractate takes chapter:mishnah, with an optional
Mishnah/m. prefix (Mishnah Shekalim 1:1, m. Shek. 1:1). Tractate names
follow Sefaria (Menachot, Pesachim) with SBL abbreviations and common
spellings as aliases (Menahot, Men., Pesah., B. Bat.); apostrophes are
ignored, so Ta'anit 2:1 is Taanit 2:1.
lookup_ancient_source(citation="Ant. 15.320") # inside Antiquities 15.317–322
lookup_ancient_source(citation="Josephus, War 6.316")
lookup_ancient_source(citation="Antiquities 18.116-121", include_original=False)
lookup_ancient_source(citation="Tg. Onq. Deut 32:8")
lookup_ancient_source(citation="Onkelos Genesis 1:1-3")
lookup_ancient_source(citation="CD 6:11") # inside CD 6:1–21 (CD-A)
lookup_ancient_source(citation="1QpHab 7:4")
lookup_ancient_source(citation="Philo, Legat. 299")
lookup_ancient_source(citation="Leg. 1.31")
lookup_ancient_source(citation="1 Enoch 89:73")
lookup_ancient_source(citation="2 Esdras 11:1") # = 4 Ezra 11:1
lookup_ancient_source(citation="m. Shek. 1:3")A locator inside a longer passage returns the passage containing it; a range
returns the overlapping passages in citation order, 4 by default (limit up
to 10), with a note when more exist. Each passage shows its citation,
canon-and-date tag, up to 1,500 characters of English and 600 of the original
(full_text=true lifts these caps), editorial ⚠ notes, and typed biblical
links; caveats and sources are printed once at the end, and the response
stops at about 12,000 characters, naming the citation to continue from. If
registered works share a title, a collection prefix (such as Mishnah) or the
locator grammar itself selects one.
Unknown works get a short summary of the citable works (and a close match,
e.g. Did you mean Antiquities?), ambiguous citations list the candidates,
unreadable or missing locators name the expected grammar with an example from
the same work, a locator outside the imported text names the imported range,
the nearest passages, and any gap note covering it, and a database without
the corpus (or with ancient-source tables from before the current schema) is
told to run python scripts/upgrade_database.py.
2. word_study
Deep dive into a Greek or Hebrew word's meaning, usage, and etymology. Greek entries include both the full Liddell-Scott-Jones (LSJ) definition for classical breadth and the Abbott-Smith definition for NT-specific insight (with LXX/Hebrew equivalents, synonym discussions, and NT occurrence counts). Hebrew entries include the full Brown-Driver-Briggs (BDB) definition.
When Claude uses it: User asks about the meaning of a Greek/Hebrew word, wants to understand different translations of a term, or asks about theological concepts (love, faith, grace).
What it returns: Original word in Greek/Hebrew script, transliteration, Strong's number, brief definition, full LSJ or BDB scholarly definition, Abbott-Smith NT-focused definition (Greek words), LXX/Hebrew cross-references, synonym discussions, NT occurrence count, etymology, usage count, semantic range, related words, example passages.
Example:
User: "What does 'agape' mean in Greek?"
Claude calls: word_study(strongs="G26")
Returns:
- ἀγάπη (agapē, G26)
- Brief Definition: "love, goodwill, benevolence"
- Full LSJ Definition: [scholarly entry with classical and biblical usage]
- Abbott-Smith Definition: [NT-focused entry with sense hierarchy]
- LXX / Hebrew Equivalents: H0160 אַהֲבָה
- Synonyms: SYN.: φιλία — love which chooses its object...
- NT Usage: Occurs 116 times in the New Testament
- Related words: ἀγαπάω (to love), ἀγαπητός (beloved)3. search_lexicon
Search across Greek and Hebrew lexicons by English meaning.
When Claude uses it: User wants to find the Greek/Hebrew word for an English concept, asks "How do you say X in Greek?", or is exploring related words.
Example:
User: "What are the Greek words for 'love'?"
Claude calls: search_lexicon(query="love", language="greek")
Returns:
- G26 ἀγάπη - divine, unconditional love
- G5368 φιλέω - brotherly, affectionate love
- G2309 θέλω - desire, wish4. get_cross_references
Find passages related to a verse or theological theme.
When Claude uses it: User asks "What other passages talk about X?", wants to see Scripture interpreting Scripture, or is studying a theological theme.
Built-in themes: salvation_by_grace, deity_of_christ, atonement, resurrection, holy_spirit, justification.
Example:
User: "What passages support salvation by grace alone?"
Claude calls: get_cross_references(theme="salvation_by_grace")
Returns:
- Genesis 15:6 - Abraham believed, credited as righteousness
- Romans 3:21-26 - Righteousness through faith in Christ
- Ephesians 2:8-9 - Saved by grace through faith
- Titus 3:5-7 - Not by works of righteousness5. lookup_name
Get information about biblical people, places, and things, enriched with ACAI entity annotations (variant names, roles, reference counts, speech attributions).
When Claude uses it: User asks "Who was X?", wants to know about a place's significance, or asks about relationships between biblical figures.
What it returns: Original Hebrew/Greek form, type (person, place, thing), description, key references, relationships (father, mother, children), ACAI annotations (variant names, roles, verse reference count, attributed speeches).
Example:
User: "Who was Abraham?"
Claude calls: lookup_name(name="Abraham")
Returns:
- Type: Person
- Original: אַבְרָהָם
- Description, key references, family relationships
- ACAI: Also known as "Abram", referenced in 275 verses, 52 attributed speeches6. parse_morphology
Explain Greek or Hebrew grammatical parsing codes.
When Claude uses it: User asks what a morphology code means or wants to understand verb tense, mood, voice.
Example:
User: "What does V-AAI-3S mean?"
Claude calls: parse_morphology(code="V-AAI-3S", language="greek")
Returns:
- Part of Speech: Verb
- Tense: Aorist, Voice: Active, Mood: Indicative
- Person: 3rd, Number: Singular7. search_by_strongs
Find all verses containing a specific Strong's number.
When Claude uses it: User wants to see how a word is used throughout Scripture or is doing a comprehensive word study.
Example:
User: "Show me all the places where 'hesed' (H2617) appears"
Claude calls: search_by_strongs(strongs="H2617", limit=20)
Returns:
- H2617 חֶסֶד (hesed) - "lovingkindness, steadfast love"
- Genesis 24:12, Exodus 34:6, Psalm 23:6, Psalm 136...Scholarly Commentary
8. get_study_notes
Get scholarly study notes and translation notes for a Bible verse or chapter.
When Claude uses it: User wants commentary on a specific verse, help explaining a difficult passage, or translation and cultural background notes.
What it returns: Combined commentary from three sources: Aquifer Open Study Notes (66 books of concise verse-level scholarly commentary), unfoldingWord Translation Notes (translator-focused linguistic insights), and SIL Translator Notes (additional translation and cultural context).
Example:
User: "What do the study notes say about John 3:16?"
Claude calls: get_study_notes(reference="John 3:16")
Returns:
- Aquifer Open Study Notes: [verse commentary]
- Translation Notes (UW): [linguistic insights]
- Translation Notes (SIL): [cultural context]9. get_bible_dictionary
Look up a topic in the Tyndale Bible Dictionary.
When Claude uses it: User needs background information on a biblical topic, historical or cultural context, or a detailed article about a person, place, or concept.
What it returns: The dictionary article from a collection of 500+ topical articles covering biblical people, places, theological concepts, cultural practices, historical background, and archaeological findings. A long article comes about 4,000 characters at a time, ending with the offset to continue from and the headings of the sections still to come (section="The Sinai Covenant" reads one section). When no article is titled exactly as the topic, it returns at most four: titles containing the topic first (Gilboa gives Mount Gilboa), then articles that mention it.
Example:
User: "Tell me about the Pharisees"
Claude calls: get_bible_dictionary(topic="Pharisees")
Returns: Full Tyndale Bible Dictionary article with historical background,
beliefs, practices, and NT context.10. get_key_terms
Look up a key theological term in the FIA Key Terms database.
When Claude uses it: User wants a precise definition of a theological term, or needs to understand how a concept is used across Scripture.
What it returns: Definition from a collection of 200+ carefully defined theological and biblical terms with biblical usage, cross-references, and translation guidance.
Example:
User: "Define the term atonement"
Claude calls: get_key_terms(term="atonement")
Returns: FIA Key Terms definition with biblical usage, cross-references,
and translation guidance.Graph Knowledge (Theographic Bible Metadata)
11. explore_genealogy
Trace family relationships (ancestors or descendants, 1 to 40 generations) for a biblical person using the parent links of 2,000 persons.
What it returns: Each ancestor or descendant once, generation by generation, with whose parent or child they are (and curated notes such as Joseph as Jesus' legal father), immediate family (spouse, siblings), and a Mermaid diagram when the tree has at most 40 people. Dictionary articles are left to get_bible_dictionary.
Example:
User: "Show me the family tree of David"
Claude calls: explore_genealogy(person="David", direction="both", generations=5)
Returns: Ancestor chain (Jesse → Obed → Boaz...), descendants,
spouse(s), siblings, Mermaid flowchart diagram.12. explore_person_events
Find all events a biblical person participated in, in chronological order.
What it returns: Each event once, in chronological order, with its approximate date (Theographic chronology), places, and passage. Names resolve as Scripture uses them ('Peter', 'Jacob' the patriarch), and the tool says which namesake it chose.
13. explore_place
Explore the biblical history of a geographic location.
What it returns: Events at the location in chronological order with their passages, people born or who died there, coordinates, Mermaid network diagram.
14. find_connection
Find the family relationship path between two biblical people.
What it returns: The closest relationship path through parent, child, sibling, and partner relationships, preferring lines of descent, summarised and listed compactly, with a Mermaid flowchart for paths of up to 12 steps.
Example:
User: "How are Ruth and Jesus related?"
Claude calls: find_connection(person1="Ruth", person2="Jesus")
Returns: Ruth → child → Obed → child → Jesse → child → David → ... → Jesus15. people_in_passage
Find all people, places, and events mentioned in a Bible passage.
What it returns: All entities mentioned in a chapter or verse according to Theographic Bible Metadata.
Cultural Context
18. get_ane_context
Retrieve Ancient Near East cultural and historical context that illuminates biblical passages. Covers 12 dimensions of ANE life across 9 time periods.
When Claude uses it: User asks about cultural background, customs, practices, or worldview behind a passage; when understanding the original context would prevent modern misreadings.
What it returns: Structured entries with title, summary, detailed explanation, ANE parallels from extra-biblical sources, interpretive significance, key references, and scholarly sources.
Dimensions: Cosmology & Worldview, Religious Practices, Social Structure, Legal & Covenant, Political & Imperial, Economic Life, Literary Conventions, Warfare & Military, Daily Life & Material Culture, Death & Afterlife, Gender & Family, Education & Literacy.
Periods: Patriarchal, Exodus/Conquest, Judges/Early Monarchy, United Monarchy, Divided Monarchy, Assyrian/Babylonian, Persian, Hellenistic, Roman.
Example:
User: "What's the cultural background behind Genesis 15 - the covenant ceremony?"
Claude calls: get_ane_context(reference="Genesis 15:1", dimension="legal_covenant")
Returns:
- Suzerainty Treaty Forms: ANE covenant structure (preamble, stipulations,
witnesses, curses/blessings) parallels Deuteronomy and Genesis 15
- Self-Maledictory Oath: Walking between animal halves = "may I become
like these animals if I break this covenant"
- ANE Parallels: Hittite suzerainty treaties, Mari covenant rituals
- Interpretive Significance: God alone passes through the pieces,
taking the covenant curse entirely upon himselfHybrid Search
16. graph_enriched_search
Combine passage lookup with graph context for the most comprehensive single-query view of a verse.
What it returns: Verse text (English + original), all people/places/events mentioned, family relationships for each person mentioned.
17. find_similar_passages
Discover semantically similar passages across the Bible using vector embeddings.
When Claude uses it: User wants to find thematic connections not captured by explicit cross-references, or asks "What passages are similar to X?"
What it returns: Similar passages ranked by semantic similarity (%), genre warnings, hermeneutical cautions.
Important: Semantic similarity indicates shared vocabulary and concepts, but does NOT establish theological connection. The tool includes warnings to verify genre compatibility, authorial intent, and historical context.
Example:
User: "Find passages similar to Daniel 7:7"
Claude calls: find_similar_passages(reference="Daniel 7:7", limit=5)
Returns:
- Daniel 7:15-28 (70.0% similar) - interpretation of the vision
- Revelation 9:17-21 (61.1% similar) - locusts with lion's teeth
- Daniel 2:29-45 (60.8% similar) - Nebuchadnezzar's statueTheological Scholarship & Structure
get_theology_context
Retrieve attributed theological scholarship by biblical reference, theme, or author.
get_torah_weave
Find structurally paired Torah passages under Moshe Kline's Woven Torah hypothesis.
get_textual_variant
Inspect catalogued MT/LXX/DSS divergences without collapsing sources and conclusions. Each reading lists only the manuscripts that witness it. New Testament quotations appear under NT citation evidence, and material that bears on a text form without witnessing the verse (such as a Qumran scroll attesting a short edition elsewhere in Jeremiah) appears under Indirect evidence. Corpora with no surviving copy are listed in a case-level Not preserved in note. Every witness keeps the dataset's raw support label.
Critical judgments contain only conclusions that carry a source citation.
Uncited dataset summaries appear separately as an Unsourced dataset summary
(not verified against published text-critical scholarship). Theological
interpretations, named-author claims, and NT quotation alignment also stay in
their own sections, and sections with nothing catalogued are omitted. The
dataset's Heiser Literal Translation (HLT) renderings and rationales stay in the
database but are not printed: the HLT is the owner's own unpublished
translation. Verses where the witnesses agree with the MT but the
reading or rendering is contested (for example the divine-council language of
Psalm 82:6) appear as Translation and interpretation notes, never as
variants. A verse can have both: at Job 38:7, Daniel 4:17 and 7:13, and Psalm
29:1 a variant case records where the Greek differs from the MT, and the notes
follow it; Mark 14:62, Matthew 24:30 and 26:64, and Revelation 1:7 reach the
Daniel 7:13 case through NT quotation alignment. lookup_verse mentions when a verse has a catalogued variant case or
interpretation notes. On a database that still has the legacy
variant schema, the tool asks you to run python scripts/upgrade_database.py.
Further Research
list_research_sources
List curated, freely accessible research repositories to consult before a general web search: primary-text libraries (Sefaria, CCEL, Perseus, the Internet Archive), open-access journals (Tyndale Bulletin, Themelios, the Journal of Hebrew Scriptures, HTS), Dead Sea Scrolls and Septuagint resources, and Heiser's own sites. Each entry states its coverage, perspective (Jewish, Catholic, Reformed, evangelical, academic/critical, multi-tradition, single-author) and access or licence terms. Filter by topic (coverage tag or name, matched loosely) and perspective; pass query to get a ready-to-open search link for every source that supports one (STEP Bible's link opens the passage when the query is a Bible reference). With no filter the list starts with a mix: Tyndale Bulletin (evangelical), STEP Bible (reference), Sefaria (Jewish) and Bible Odyssey (academic). The list is a set of places to look, not endorsements.
The catalogue lives in src/study_bible_mcp/research_sources.json. It is a directory of repositories, not a per-passage or per-scholar index.
Checking links. python scripts/check_links.py fetches, over the network, every catalogue URL, every search template filled with a sample query, and (when db/study_bible.db or --db is present) every distinct theology_content.url in the database. It makes about 100 requests to third-party sites, so run it occasionally rather than in CI. Checks run with bounded concurrency and a 20-second timeout; a link that times out is retried once with a 60-second limit, because some hosts are slow rather than dead. Any link answering with status 400 or above, or failing at the network level, is reported as BROKEN with where it came from; one that still times out after the retry is reported as TIMEOUT. Either makes the run exit non-zero. Hosts known to be slow but working are listed in LINK_CHECK_SLOW_HOSTS in the script (currently drmsh.com, which has taken 31-57 seconds to answer): their retry gets a 180-second limit, and a timeout that still persists is reported as SLOW, a warning that does not fail the run. A real error status from those hosts still does. Some sites refuse HEAD requests, so the checker falls back to GET. Some answer every automated client with a bot challenge; only for those, an entry may set "link_check": "skip" with a "link_check_reason", and the checker lists it as skipped rather than checking it. Verify skipped entries by hand when updating last_verified.
How Users Interact
Natural Language Queries
Users don't need to know the tool names. They just ask questions:
User Question | Claude Uses |
"What does John 3:16 say in Greek?" |
|
"What's the Greek word for love?" |
|
"Study the word 'agape'" |
|
"Who was Abraham?" |
|
"What other passages talk about grace?" |
|
"Parse V-AAI-3S" |
|
"Where else does G26 appear?" |
|
"What do the study notes say about Romans 8:28?" |
|
"Look up 'covenant' in the Bible dictionary" |
|
"Define the key term 'atonement'" |
|
"Show me David's family tree" |
|
"What events happened in Moses' life?" |
|
"What's the history of Bethlehem?" |
|
"How are Ruth and Jesus related?" |
|
"Who are the people in Romans 8?" |
|
"Give me everything about Genesis 22:1" |
|
"Find passages similar to Daniel 7" |
|
"What's the cultural context of Genesis 15?" |
|
Example Conversation
User: "I'm studying Romans 5:8. What does Paul mean when he says God 'demonstrates' his love?"
Claude's internal process:
Look up the verse:
lookup_verse(reference="Romans 5:8")Study the key word:
word_study(word="demonstrates")→ finds G4921 συνίστημιGet study notes:
get_study_notes(reference="Romans 5:8")Check cross-references for context
Apply genre guidance (Epistles)
Claude's response:
In Romans 5:8, Paul uses the Greek word συνίστημι (synistēmi, G4921), which means "to stand together, to commend, to demonstrate." This is a present tense verb, indicating ongoing action.
The genre context is important here: Romans is an epistle, and Paul is building an argument. In the immediate context (Romans 5:1-11), he's explaining how we have peace with God through justification by faith. Verse 8 is his proof: God didn't wait for us to become worthy, but demonstrated his love "while we were still sinners."
The word "demonstrates" carries the sense of proving beyond doubt - not just telling us about his love, but showing it through action (Christ's death).
Related passages on God's love demonstrated through Christ: John 3:16, 1 John 4:9-10.
Example Questions
Try asking Claude:
What does John 3:16 say in Greek? Break down the key words.Study the word 'agape' - how is it different from other Greek words for love?What's the context of Romans 8:28? Who is Paul writing to and why?Show me cross-references for Ephesians 2:8-9 on salvation by grace.Who was Melchizedek and why is he significant?Parse the verb morphology in Philippians 2:12 - "work out your salvation"What does the Hebrew word 'hesed' mean? Where is it used?Help me understand Revelation 13 - what are these beasts?What do the study notes say about John 1:1?Look up 'baptism' in the Bible dictionary.Show me David's family tree going back 5 generations.How are Abraham and Jesus connected genealogically?What events happened in the life of Moses?Find passages similar to John 3:16 - what other verses talk about God's love like this?What Old Testament passages connect to Daniel's vision of the Son of Man?What's the Ancient Near East background for the creation account in Genesis 1?Explain the cultural context of covenant-making in Genesis 15.Hermeneutical Framework
This isn't just a reference tool. It's designed to guide users toward sound biblical interpretation.
The Problem It Solves
Common interpretation errors include:
Proof-texting: Using isolated verses to support predetermined conclusions
Allegorizing: Finding hidden meanings not intended by the author
Ignoring genre: Reading poetry as prose or prophecy as history
Ignoring context: Ripping verses from their historical and literary setting
Moralizing: Reducing narratives to "be good like David"
The Fee & Stuart Method
The interpretive framework is based on "How to Read the Bible for All Its Worth" by Gordon Fee and Douglas Stuart - the standard textbook for biblical hermeneutics used in seminaries worldwide.
About the authors:
Gordon Fee (1934-2022): New Testament scholar, professor at Regent College, author of major commentaries on 1 Corinthians, Philippians, and Pauline theology. One of the translators of the NIV and TNIV.
Douglas Stuart: Old Testament scholar, professor at Gordon-Conwell Theological Seminary, author of commentaries on Hosea-Jonah, Exodus, and Old Testament hermeneutics.
Their book (first published 1981, now in its 4th edition) has sold over a million copies and is used as the introductory hermeneutics text at most evangelical seminaries. It teaches readers to interpret Scripture according to its literary genre, historical context, and authorial intent - avoiding both wooden literalism and uncontrolled allegorizing.
The server embeds genre-specific interpretation principles from this methodology:
Core Principles
Exegesis Before Application
First discover what the text meant to its original audience
Then determine what it means for us today
Never jump directly to application
Context is King
Historical context: time, culture, author, audience, occasion
Literary context: genre, surrounding passages, book structure
A text without context is a pretext for a proof text
Genre Determines Method Different biblical literature requires different approaches
Genre-Specific Guidelines
Epistles (Letters)
Key principle: Think contextually - what problem was being addressed?
Read the entire letter to understand the argument flow
Ask: What problem prompted this letter?
Pay attention to logical connectors (therefore, because, so that)
Distinguish between central argument and supporting points
Not every statement is universally prescriptive
Common errors:
Taking verses out of their argumentative context
Ignoring the specific historical situation being addressed
Treating every instruction as a timeless command
Old Testament Narratives
Key principle: Three levels (meta, national, individual); descriptive not prescriptive
Narratives describe what happened, not necessarily what should happen
Three levels: God's universal plan, Israel's story, individual accounts
Characters are not always examples to follow - observe their flaws
The narrator rarely makes direct theological statements
God is the ultimate hero of every narrative
Common errors:
Treating every character's action as a model to follow
Allegorizing details that are simply historical facts
Moralizing: "Be brave like David" without seeing God's work
Gospels
Key principle: Two-level documents (Jesus' original context + evangelist's purpose)
Consider both Jesus' original meaning and the Gospel writer's purpose
Each Gospel has a specific audience and theological emphasis
Account for the already/not-yet tension of the Kingdom
Compare parallel accounts to see each writer's emphasis
Common errors:
Harmonizing too quickly without hearing each Gospel's voice
Ignoring Jesus' audience (Pharisees, disciples, crowds)
Applying teachings directly without considering the cross
Parables
Key principle: Find the main point; don't allegorize every detail
Identify the one or two main points - parables are not allegories
Consider the audience: Who is Jesus speaking to and why?
Look for cultural background that illuminates meaning
The unexpected twist often carries the main message
Common errors:
Allegorizing every detail (the donkey represents X...)
Missing the shock value for the original audience
Creating theological systems from parabolic details
Prophets
Key principle: Covenant enforcement; check if "future" is now past
Prophets were covenant enforcement officers - calling Israel back
Most "predictions" were about events now in our past
The prophetic lawsuit pattern: accusation, judgment, hope
Distinguish near fulfillment from ultimate/eschatological fulfillment
Poetry and metaphor are the normal mode of prophetic speech
Common errors:
Reading all prophecy as about the end times
Literalizing poetic and metaphorical language
Creating detailed end-times timelines from prophetic poetry
Psalms
Key principle: Poetry/prayer; understand the types (lament, thanksgiving, praise)
Psalms are inspired responses to God - poetry, not doctrine
Identify the type: Lament, Thanksgiving, Praise, Royal, Wisdom
Poetry uses metaphor, hyperbole, and parallelism
The emotions are real and God-given - even the difficult ones
Many psalms find their ultimate fulfillment in Christ
Common errors:
Treating poetic expressions as doctrinal statements
Ignoring the emotional dimension
Literalizing metaphorical language
Wisdom Literature
Key principle: General truths, not guarantees; compare with full canon
Proverbs are general truths, not unconditional promises
Wisdom literature wrestles with life's complexity
Job and Ecclesiastes challenge simplistic interpretations
The fear of the Lord is the foundation of all wisdom
Compare individual proverbs with the full biblical witness
Common errors:
Treating Proverbs as unconditional promises
Ignoring the dialogue format in Job (not all speeches are true)
Missing the "under the sun" perspective in Ecclesiastes
Apocalyptic (Revelation)
Key principle: Apocalyptic imagery; already/not yet eschatology
Apocalyptic is a literary genre with its own conventions
Symbols are stock imagery (beasts, numbers) with recognized meanings
The primary message is: God wins, evil is judged, Christ reigns
Read in light of OT prophets and the already/not yet tension
Multiple valid interpretive approaches exist
Common errors:
Literalizing symbolic imagery (666 as a barcode)
Creating detailed chronological timelines
Missing the pastoral purpose: encouragement for suffering believers
The Reasoning Pattern
The server's hermeneutics module guides Claude through this sequence:
IDENTIFY: What biblical text(s) are relevant?
GENRE: What type of literature is this?
CONTEXT: Historical, literary, canonical
CONTENT: What does the text say? (Greek/Hebrew when helpful)
CROSS-REFERENCES: Scripture interprets Scripture
APPLICATION: Timeless principle behind temporal commands
HUMILITY: Acknowledge uncertainty where it exists
Self-Hosting
Want to run your own instance? See docs/SELF_HOST.md.
Options:
Local Python development
Docker deployment
Your own Fly.io instance
Project Structure
studybible-mcp/
├── src/study_bible_mcp/
│ ├── server.py # MCP server (stdio, SSE, and Streamable HTTP)
│ ├── database.py # SQLite queries (async)
│ ├── tools.py # MCP tool definitions and output formatters
│ ├── research_sources.json # Curated open research repositories (list_research_sources)
│ ├── hermeneutics.py # Genre detection & interpretation
│ ├── corpora/ # Ancient-source corpus registry
│ │ ├── __init__.py # CORPORA registry (one line per corpus)
│ │ ├── base.py # Corpus, Work, Collection, BiblicalLink types
│ │ ├── locators.py # Citation locator grammars and sort keys
│ │ ├── citations.py # Citation-to-work resolution
│ │ ├── download.py # Checksum-verified download helpers
│ │ ├── josephus.py # Josephus TEI parser, works, and links
│ │ ├── targum.py # Targum Onkelos Sefaria files, verse keys
│ │ └── rabbinic.py # Mishnah (Sefaria)
│ └── parsers/
│ ├── lexicon.py # TFLSJ, BDB, Abbott-Smith, TBESG, TBESH parsers
│ ├── aquifer.py # BibleAquifer JSON parser
│ ├── acai.py # ACAI entity annotation parser
│ ├── ane_context.py # ANE cultural context parser
│ ├── biblical_versions.py # MT/LXX text, morphology, and versification
│ ├── bsb.py # Berean Standard Bible (bsb.txt) parser and importer
│ ├── ancient_sources.py # Generic corpus importer (passages, FTS, links)
│ ├── tagged_text.py # TAGNT/TAHOT morphology parsers
│ └── proper_names.py # TIPNR name parser
├── scripts/
│ ├── download_stepbible.py # Download base source data (--aquifer flag)
│ ├── download_biblical_versions.py # Download pinned LXX/Brenton sources
│ ├── download_bsb.py # Download the pinned Berean Standard Bible text
│ ├── download_ancient_sources.py # Download every registered ancient corpus
│ ├── build_database.py # Build SQLite database
│ ├── generate_embeddings.py # Generate vector embeddings
│ ├── import_theographic.py # Import Theographic graph data
│ ├── upgrade_database.py # In-place schema/source upgrade of an existing DB
│ ├── smoke_server.py # Full-database smoke suite
│ └── check_links.py # Checks research-source and theology URLs (network)
├── tests/ # Deterministic unit and tool-selection tests
├── prompts/
│ └── system_prompt.md # Full hermeneutical framework for agents
├── docs/
│ ├── SETUP.md # Quick setup guide
│ └── SELF_HOST.md # Self-hosting instructions
├── ARCHITECTURE.md # Mermaid flowchart of the tool-selection paths
├── Dockerfile # Runtime image; database mounted separately
├── fly.toml # Fly.io deployment config
└── pyproject.tomlData Sources
STEPBible - Tyndale House, Cambridge
Biblical text and brief lexicon data come from the STEPBible project (GitHub), developed by scholars at Tyndale House, Cambridge - one of the world's leading centres for biblical research. Licensed CC BY 4.0.
File | Description | Content |
TFLSJ | Full Liddell-Scott-Jones Greek Lexicon | 10,846 Greek words with full scholarly definitions |
Abbott-Smith | Manual Greek Lexicon of the NT (TEI XML) | 5,896 NT-focused entries with LXX cross-refs and synonym discussions |
TBESG | Tyndale Brief Lexicon - Greek (fallback) | 5,600+ Greek words with brief definitions |
TBESH | Tyndale Brief Lexicon - Hebrew (fallback) | 8,600+ Hebrew words with brief definitions |
TAGNT | Translators Amalgamated Greek NT (2 parts) | Every word of the Greek NT with morphology, Strong's numbers, glosses |
TAHOT | Translators Amalgamated Hebrew OT (4 parts) | Every word of the Hebrew OT with morphology, Strong's numbers, glosses |
TIPNR | Translators Proper Names | 4,299 biblical people, places, and things with references |
TEGMC/TEHMC | Morphology Codes | Grammatical parsing code definitions |
Berean Standard Bible
The English verse text shown by lookup_verse, search_by_strongs,
word_study, find_similar_passages and graph_enriched_search is the
Berean Standard Bible, which its publisher has
dedicated to the public domain. scripts/download_bsb.py fetches bsb.txt
from bereanbible.com, which is unversioned, so the file is pinned by SHA-256
(BSB_SHA256 in src/study_bible_mcp/parsers/bsb.py, the edition downloaded
on 2026-10-14); the download and import fail on any other file. The import also
requires the file's own public-domain statement, and moves the Psalm headings
the file prints at the start of verse 1 into verse 0 rows, so a Psalm's
superscription shows its BSB heading and verse 1 is the verse alone. Verses are matched by English
numbering, so split-numbered STEPBible rows (Gen.32.1(32.2)) get their BSB
verse; where the BSB has no such verse the tools show the STEPBible gloss
marked [gloss], and without the table they show the gloss as before.
Septuagint and MT versification
The LXX comparison corpus uses the complete 59-book
OpenScriptorium lxx-morph
Rahlfs morphology dataset, pinned to commit
c91f6b1e8fb3ba37df701e6ae31f675ace71a2b2. Its explicit
verse_pairs.jsonl mapping resolves Psalm numbering, Jeremiah's chapter order,
2 Esdras, and smaller MT/LXX shifts. That mapping is derived in part from
TVTMS (Tyndale Versification
Traditions Mapping System), CC BY 4.0, created by STEPBible.org / Tyndale House
Cambridge. Downloads are checked against the pinned
Git blob hashes. Morphology is CC BY 4.0; the underlying Rahlfs (1935) Greek
text is public domain. Only the LXX rows are stored (about 35 MB including
indexes, with word morphology zlib-compressed); MT rows are read from the
existing TAHOT verses table at query time.
English LXX translations come from the public-domain
Brenton Septuagint at eBible.org,
and Brenton's own public-domain Greek text from
eBible's grcbrent
(data/lxx/brenton-greek). eBible regenerates its unversioned zips, so the
download script verifies the SHA-256 of every extracted USFM book rather than of
the archive, and never deletes or overwrites local files that fail verification.
Brenton's Greek is stored only for the verses where it differs from Rahlfs
(about 5 MB). build_database.py stops with an error if data/lxx is present
but incomplete (any of the 59 morphology books, the mapping, a required Brenton
English or Greek book, or a manifest-listed file is missing or truncated).
Ancient sources
The ancient sources are texts written by about AD 200 that witness the Second Temple world: Josephus, Targum Onkelos, four Qumran texts (CD, 1QS, 1QSa, 1QpHab), Philo, 1 Enoch, 4 Ezra and the Mishnah. Targum Onkelos is the one stated exception: its final form is c. 3rd–5th c. AD, and it is kept for its earlier tradition as the standard Torah targum; its tag gives the final-form date and its caveat states the exception. Sources later than c. AD 200 (Targum Pseudo-Jonathan with Etheridge's English, the Tosefta, the Babylonian Talmud and Leviticus Rabbah) were removed: they are too far from the New Testament to witness its world without an earlier source.
Each corpus is a module in src/study_bible_mcp/corpora/ registered in
CORPORA; its pinned files live in data/ancient_sources/<corpus>/ and
source_manifest.json records every verified file. build_database.py
imports every corpus whose directory exists and fails if a present directory is
incomplete; upgrade_database.py fails unless every registered corpus is
downloaded and complete. All corpora share ancient_source_passages,
whose sort_start/sort_end keys (in each work's citation grammar) back
lookup_ancient_source, and whose original_license, translation_license,
and combined license record provenance per passage. Each import replaces only
its own corpus inside a savepoint after validating every passage and link, and
merges the FTS index so repeated upgrades do not grow it. Indexed originals are
folded for search: Greek accents and breathings and Hebrew/Aramaic vowel points
and cantillation are removed and case is folded, in the index and the query.
Editorial signs inside words ([ ] ⟨ ⟩ < > { } ( ) ^ ¦) and invisible format
characters are deleted rather than treated as word breaks, in the index and the
query; a corpus can also declare search_index_removals, patterns for printed
text that is not part of the reading (Qumran's scribal erasures and vacat),
which are deleted from the index, and search_index_gaps, printed text that
is not evidence (Qumran's [ ] reconstruction), which becomes a word break, so
it is never matched and the surviving letters either side are not joined into
a false word. Every Hebrew-script word is also indexed,
in a separate column searched only as a fallback, without one or two leading
prefix letters, keeping at least three letters. The displayed text keeps
every sign.
Every passage is labelled so that the agent never mistakes it for Scripture:
Tag. Each corpus (or work) declares a
SourceTagin the registry: canon status, kind, composition date, date tier (A: written before or alongside the NT; B: after the NT, to c. AD 200, with Targum Onkelos's later final form the stated exception), edition, and, where the copy is much later than the work, the manuscript date. 1 Enoch is dated book by book. The registry refuses a corpus with an untagged work.Caveat. Each corpus declares a 1–3 sentence caveat, printed once per response that shows it (e.g. Philo: his Logos is not the incarnate Son).
Editorial notes.
src/study_bible_mcp/corpora/editorial_notes.json(committed) holds verse-level notes —emendation,interpolation,reconstruction,contrast,polemic,caution,gap— with contrasting and aligned biblical references, and extra typed links. Each corpus import loads them intoancient_source_notes(one row per passage a citation covers; agapnote sits on the passages either side of its range) and fails if a citation covers no passage or a biblical reference does not parse. A file link to the same passage and range as a module link replaces it. Notes print as⚠ <note> (Contrast: Mark 14:62), once per response. The file holds 46 notes and 40 links, e.g. Charles's emendation at 1 Enoch 71:14, the Christian "Jesus" of 4 Ezra 7:28–29, the restored lemma at 1QpHab 7:17, Philo's Logos at Conf. 146, and Yom Kippur atonement at m. Yoma 8:8–9.Typed links.
ancient_source_biblical_links.relationisaligned,echo,shared_tradition,contrast, ortranslation, printed asAligned: Jude 14–15 — …,Contrast: …and so on. A pseudepigraphon is paired with the Scripture that takes it up (1 Enoch with Gen 6:1–4, Jude 6 and 14–15, 2 Pet 2:4, 1 Pet 3:19–20). Module links takeechowhen their note says the text cites, quotes or expounds the Bible andshared_traditionotherwise, unless they set a relation;create_schemaadds the column to older databases with the same rule, and rebuilds an older search index.
Josephus
The josephus corpus uses all four Josephus works from
PerseusDL canonical-greekLit,
pinned to commit 01b725d835e6e733062ffd79e0efdbae1ba06e5c. The English TEI
has one division per Whiston section, labelled with the Niese section where it
starts; the Greek TEI has one division per Niese section. The importer joins
every Greek section from each English start up to the next (the last section
of a book runs to the book's last Greek section), so no Niese Greek is dropped;
the later Greek book summaries (arg) are excluded. One mislabelled English
division (Whiston 17.13.1, labelled 13) is corrected to Niese 17.339 from the
Greek milestone and text. Editor notes and Whiston's chapter headings are kept
out of the primary-source text and the search index; headings are stored as
editorial metadata. The FTS5 index uses Porter stemming for English and an
accent-folded copy of the Greek. Each TEI file declares CC BY-SA 4.0; downloads
are checked against their pinned Git blob hashes, and the build fails if any of
the eight TEI files is missing.
Biblical links are a small, separate editorial index of direct narrative overlap. Each targets a Niese section, attaches to the passage whose span contains it, and was checked against the passage text; the import fails if a link does not resolve. They do not assert literary dependence or historical agreement, and the Testimonium Flavianum link is marked as of disputed authenticity.
Targums
The targum corpus holds Targum Onkelos on all five books of the Torah, one
work per book (onkelos_genesis … onkelos_deuteronomy, cited as Onkelos Genesis 1:1 or Tg. Onq. Deut 32:8). The 10 version files come from Sefaria's
archived export,
Sefaria/Sefaria-Export-Archive
at commit 3f1013631fdfe452e953a93a2c5f921319e394ed (the last commit holding
the JSON texts), each checked against its pinned Git blob hash and against the
license and versionTitle it declares; merged.json files are never used.
Aramaic: the Torat Emet text of Onkelos (Sefaria versions
Onkelos {Book}), declared Public Domain by Sefaria. One passage per Sefaria verse (5,846). A???digitization mark before Genesis 49:12 is removed.English: the Metsudah Chumash (Metsudah Publications, 2009, Sefaria version
Metsudah Chumash, Metsudah Publications, 2009 [with Onkelos translation], CC BY-NC 4.0). It translates the Hebrew text, so it is not a direct translation of the Aramaic beside it. Metsudah sets Onkelos's own renderings in bold (in Genesis 12–17, italic) brackets; these print as⟨…⟩(3,599 of them), while plain[ ]are Metsudah's own supplements, e.g. Genesis 49:10 "until Shiloh Comes ⟨the Moshiach will come, for his is the kingship⟩". The tag says "Metsudah: English of the Hebrew Torah; ⟨marked⟩ words are Onkelos's renderings", and the licence line readsAramaic text: Public domain; English translation: CC BY-NC 4.0. A verse without Metsudah English is an Aramaic-only passage.
Versification. Sefaria numbers Onkelos by the Hebrew verses; passages,
citations and links use the server's English numbering, with the Hebrew
number in the heading where it differs (Targum Onkelos Exodus 8:5 (MT 8:1)).
A static table in targum.py covers the Torah's 18 differing runs, as in
TAHOT's verses table (Exo.8.5(8.1)): Gen 31:55–32:32, Exod 8:1–32 and
22:1–31, Lev 6:1–30, Num 16:36–17:13 and 29:40–30:16, Deut 12:32–13:18,
22:30–23:25 and 29:1–29. Sefaria's Decalogue follows the upper accents, so
Exodus 20:13–16 and Deuteronomy 5:17–20 are one passage each and later
verses shift by three; Numbers 26:1 also holds MT 25:19. The import fails if
the English keys stop rising.
Each passage has one editorial "Translation of" link to the English verse(s)
it covers, printed with the Hebrew number where it differs (Translation of: Exod 8:5 (MT 8:1)), so biblical_reference finds Onkelos on a verse. The
period tag gives the redaction era (editorial): amoraic.
Qumran
The qumran corpus has one passage per manuscript column, its Hebrew lines
prefixed with their line numbers and cited column:line. No English
translation is included, so every passage is original-only and the tools say
so.
Damascus Document, Community Rule, Rule of the Congregation, Pesher Habakkuk (
CD,1QS,1QSa,1QpHab): the Text-Fabric transcription by Martin G. Abegg Jr., James E. Bowley and Edward M. Cook in ETCBC/dss, release 2.0.1, pinned to commit47ecc1738fad6e67df7d40a3e84d73e4a125e265and licensed CC BY-NC 4.0 (checked in every feature file's header at download and import). CD keeps the conventional page numbers: Genizah MS A columns 1–16 and MS B columns 19–20, shown asCD-A/CD-Balongside, and its tag names the medieval copy served (copy: Cairo Genizah MS A, 10th c. AD). Lines are rendered from the sign-level features with the transcription's brackets:[ ]modern reconstruction,{ }and{{ }}removal by a modern editor or the scribe,< >and<< >>correction by a modern editor or the scribe,^ ^supralinear,( )alternative reading, andvacat(spaced off from the text) for an unwritten space. A circlet above a letter (U+05AF) marks any of its four uncertainty degrees,◦an unidentified sign, and…a missing sign; the morpheme breaks Abegg inserts before suffixes are dropped, and the transcription's׃marks are kept. Search ignores the circlets and indexes the corrected, surviving reading: modern reconstruction in[ ]is never matched (the letters either side ofיג[די]לוare not joined intoיגלו), and letters in{ }and{{ }}and the wordvacatare left out of the index (י{{א}}<<ע>>בורוis found asיעבורו); the displayed text keeps every sign. Other ETCBC scrolls are not imported (1QSb, for example, mixes fragment labels and line gaps).
The 32 biblical links connect a 1QpHab column to each Habakkuk 1–2 verse
(range) whose lemma it quotes. Each was checked against the Masoretic verse,
and the import fails unless the anchor words survive outside the editor's
[ ] on their line. Three say how much of the lemma is restored; 7:14 links
Hab 2:4a only, "(end of 2:4a restored; 2:4b wholly reconstructed)".
R. H. Charles's public-domain English of the Damascus Document ("Fragments of a Zadokite Work", APOT II, 1913) is not used. It is available only as OCR, in Charles's own chapter:verse numbering with no Schechter page and line references, and his chapter IX prints MSS A and B in parallel columns that the OCR interleaves line by line, so it cannot be aligned reliably with CD lines.
Philo
The philo corpus uses the Greek (grc1, Cohn–Wendland–Reiter, Philonis
Alexandrini opera quae supersunt, Berlin: Reimer 1896–1915) and English
(eng1, C. D. Yonge, The Works of Philo Judaeus, London: Bohn 1854–55) TEI of
all 31 treatises in
OpenGreekAndLatin/First1KGreek
(data/tlg0018/tlg001–tlg031, De Opificio Mundi to Legatio ad Gaium),
pinned to commit 03776b39f4047c5cff06f5296fae4b2bae4b08fb. The module pins
each file's Git blob hash and fetches it from that commit without GitHub API
calls. The First1KGreek editors divided the English at the same Cohn–Wendland
sections as the Greek, so each passage is exactly one section: its Greek and
the English section of the same number, never a neighbouring one. The 58
Greek sections of Spec. 1.177–193 and 2.124–213 that Yonge's shorter text
lacks are imported as Greek-only passages, marked "Yonge has no English for
this section"; an English section without a Greek counterpart fails the
import. Apparatus, marginal notes, page and line markers,
and Yonge's footnotes and source references are kept out of the text; Yonge's
treatise headings (e.g. "A TREATISE ON CIRCUMCISION." within Spec.) are
editorial headings. Each file declares CC BY-SA 4.0, checked at download and
parse. Works surviving only in Armenian or Latin (QG, QE, Prov., Anim.),
the Hypothetica, and fragments are not in First1KGreek and are not included.
Twenty-five curated links name the Genesis or Exodus verse a section quotes and
expounds (e.g. Leg. 1.31 → Gen 2:7) and Legat. 299 → Luke 3:1 (Pilate).
Search for Philo's Greek uses Greek script (λόγος, λογος); a transliteration
such as logos does not match, and Yonge renders λόγος as "word" or "reason".
Pseudepigrapha
The pseudepigrapha corpus holds two non-canonical works. 1 Enoch is R. H.
Charles's translation (2nd ed. 1912, SPCK reprint 1917) from English Wikisource,
one page per chapter (1–108), each pinned to a revision id and its SHA-1 and
fetched in three MediaWiki API requests. The translation is in the public domain
in the United States (Charles died in 1931; Wikisource {{PD/US|1931}}). Each
passage is one Charles verse in his order, including his sub-verses and
transpositions (1 Enoch 5:6a–b, 5:7c, 5:6d–j; 89:48b; 91:14d), all
sorted under their verse number; Charles's section headings
(LXXXIX. 72-77. ...) are editorial headings. Where Charles prints a parallel
column with a header (his rendering of the Greek or Latin witnesses in chapters
22, 27, 32, 89, and 106) only the main Ethiopic column is imported; the
unheaded doublet columns of 90:13–18 are both text. No Ge'ez is included: the
Beta maṣāḥǝft file (LIT1340EnochE) offers Dillmann's text only at chapter
level under a custom non-commercial notice that must accompany every copy, and
an EOTC printed-edition text whose own rights are not stated.
4 Ezra is 2 Esdras 3–14 in the KJV with Apocrypha (eBible.org eng-kjv,
public domain; the extracted 58-2ESeng-kjv.usfm is pinned by SHA-256 because
eBible regenerates its zip) paired with the Clementine Vulgate's Liber Quartus
Esdrae (Rome 1598) from Latin Wikisource revision 148869 (transcribed from
public-domain page images; Wikisource transcription CC BY-SA 4.0, credited by
URL in every Sources block). Passages are
one KJV verse with the Latin verse of the same number, except 27 spans where
the two divide verses differently (usually a speech introduction such as "Et
dixit ad me," / "And he said unto me" placed on the other side of a verse
boundary, and an offset in 14:14–20); each span pairs all of its English with
all of its Latin, and the import fails if any verse of either text is left
unpaired. 4 Ezra 3–14 keeps the 2 Esdras chapter numbers; KJV 7:36–70 is
cited as 7:106–140 (both texts lack the "missing fragment" 7:36–105, which is
not available from an openly licensed source). 2 Esdras 1–2 and 15–16 are later
Christian additions (5 and 6 Ezra) and are not included. A citation outside
the served text (4 Ezra 7:50, 2 Esdras 15:1) says both.
Period tags give conventional composition dates (1 Enoch: Watchers,
Astronomical Book, Dream Visions, and Epistle hellenistic, Parables roman;
4 Ezra roman, after 70 CE). Twenty-two curated links mark allegorical
retellings and shared imagery, e.g. the Animal Apocalypse (1 Enoch 89) with the
Genesis–Kings narrative and Malachi 1:7, and the eagle vision (4 Ezra 11–12)
with Daniel 7, which 4 Ezra 12:11 names; 1 Enoch 1:9 → Jude 14–15 and 6:1 →
Gen 6:1–2 are aligned. The editorial-notes file adds the aligned links to
Jude 6, 2 Pet 2:4 and 1 Pet 3:19–20.
Rabbinic texts
The rabbinic corpus holds the Mishnah from Sefaria's JSON export, pinned to
commit 3f1013631fdfe452e953a93a2c5f921319e394ed of
Sefaria/Sefaria-Export-Archive
(the last full export committed before Sefaria moved it to a GCS bucket that
is overwritten monthly and not versioned) and verified by Git blob hash. Every
Sefaria version declares its own licence; downloads and imports reject any
version that is not Public Domain or CC-BY. CC-BY is recorded as CC BY 3.0,
the licence Sefaria's reader links it to.
Mishnah, all 63 tractates, one passage per mishnah (
Mishnah Shekalim 1:1): Hebrew Mishnah, ed. Romm, Vilna 1913 (public domain) with Joshua Kulp's Mishnah Yomit English (CC BY). Bikkurim chapter 4, absent from the Vilna version, is English only.
Footnotes, footnote markers and HTML are removed from the English. Curated links: Mishnah Shekalim 1:1 and 1:3 to Matthew 17:24–27 (the half-shekel); the editorial-notes file adds Gospel echoes (e.g. Shekalim 1:3 → Mark 11:15) and contrast notes. The corpus caveat warns that Kulp's bracketed Bible references sometimes use Hebrew numbering or contain errors.
BDB Hebrew Lexicon
The full unabridged Brown-Driver-Briggs Hebrew lexicon (8,090 entries) comes from eliranwong/unabridged-BDB-Hebrew-lexicon. The BDB is the standard scholarly Hebrew-English lexicon, originally published in 1906 and still widely used in academic study. Public domain text.
Abbott-Smith Greek Lexicon
G. Abbott-Smith's A Manual Greek Lexicon of the New Testament (1922) provides NT-focused definitions that complement the broader classical coverage of LSJ. The TEI XML edition (5,896 entries) comes from translatable-exegetical-tools/Abbott-Smith. Public domain text.
Abbott-Smith enriches 5,426 existing Greek entries with:
Field | Description | Coverage |
NT-focused definition | Full definition with sense hierarchy | 5,871 entries |
NT occurrence count | Word frequency in the New Testament | 5,480 entries |
LXX/Hebrew equivalents | Hebrew words the Greek translates in the Septuagint | 3,317 entries |
Synonym discussions | Scholarly notes distinguishing related Greek words | 398 entries |
BibleAquifer
Scholarly commentary and reference content from BibleAquifer (CC BY-SA 4.0):
Resource | Description | Content |
Aquifer Open Study Notes | Verse-level scholarly commentary | 66 books |
Tyndale Bible Dictionary | Topical articles | 500+ articles on people, places, theology, history, archaeology |
UW Translation Notes | unfoldingWord translator commentary | Linguistic insights for 49+ books |
SIL Translator Notes | SIL International translator notes | Translation and cultural context |
FIA Key Terms | Key theological terms | 200+ carefully defined terms with cross-references |
ACAI Entity Annotations
Rich entity annotations from BibleAquifer/ACAI (CC BY-SA 4.0):
Type | Count | Content |
People | 3,426 | Family relationships, variant names, roles, speech attributions, verse references |
Places | 1,418 | Geographic entities with biblical references |
Groups | 307 | People groups, nations, tribes |
Key Terms | 868 | Annotated theological concepts |
Theographic Bible Metadata
Graph data for genealogy, events, and places from Theographic, with curated corrections and twenty added events (the binding of Isaac, the burning bush, the fall of Jerusalem ...) in src/study_bible_mcp/parsers/graph_curated.json. Used by the explore_genealogy, explore_person_events, explore_place, find_connection, people_in_passage, and graph_enriched_search tools.
Torah Weave
get_torah_weave reads version 1.1 of Moshe Kline's Torah Literary Units
dataset (chaver.com,
CC BY 4.0; Kline, Before Chapter and Verse: Reading the Woven Torah, 2022):
86 units of Genesis–Deuteronomy with 600 cells, 1,019 counting subdivisions.
The file ships as data/torah_weave/torah-units.json. Its URL is unversioned,
so it is pinned by SHA-256 (TORAH_WEAVE_SHA256 in
src/study_bible_mcp/parsers/torah_weave.py, the file retrieved on
2026-10-14), and the import fails on any other file. Kline numbers verses like
the Hebrew Bible (Leviticus 5:20-26 is English 6:1-7); the tool takes and shows
English numbers. Every Torah verse is in a cell except Deuteronomy 5:30-33,
which sit in unit 76 without one, and Exodus 20:23-26, which no unit includes.
Ancient Near East Context
87 structured entries covering 12 dimensions of ANE cultural and historical context across 9 time periods, with 314 book-chapter mappings. Data is stored in data/ane_context/ as JSON files (one per dimension). Sources include Walton, Hallo, Matthews & Benjamin, Pritchard (ANET), and other standard ANE reference works.
Theological Scholarship
193 verse-anchored entries covering Heiser, Bradley, Burnett, Owen, Stott, and Lennox, served by get_theology_context.
These entries are original summary prose written for this database, describing each author's argument on a passage or theme with attribution. They are not reproduced text from the authors' works. The material was derived from publicly available research and teaching — papers, articles, lectures, and podcasts — rather than from in-copyright books; where a specific public source is known, the entry carries its URL and the tool output shows it. Every result from get_theology_context states this provenance inline.
John Owen (d. 1683) is in the public domain, so those entries are cited directly by work.
Source links
An entry's url is shown as Source URL in get_theology_context output. Links are added only where the source itself is legitimately free online:
Author | Link target |
Owen | Free public-domain text: the CCEL chapter or part the entry draws on (Communion with God, The Death of Death, The Glory of Christ, Justification, Mortification, Indwelling Sin); for the Exposition of Hebrews, which CCEL lacks, the Monergism PDF of the volume covering that chapter |
Heiser | His papers on thedivinecouncil.com / drmsh.com / Liberty Digital Commons, and Naked Bible podcast transcripts |
Burnett | His own serialisation of the argument on drmsh.com (based on his SBL paper); the JSPL article itself is not openly hosted |
Bradley, Stott, Lennox | None: no free copy hosted by the author or publisher |
In the content JSON, a file-level url applies to every entry; an entry-level url (for example a chapter page) overrides it.
Applying data changes to an existing database
The importers are re-runnable. A row that already exists (same source_work, chapter_or_episode, title) is not duplicated and keeps its content; only its url is refreshed. To apply new or corrected links to an existing DB:
DB=db/study_bible.db
python scripts/relabel_theology_sources.py $DB # no-op if already relabelled
python scripts/import_heiser_content.py $DB
python scripts/import_bradley_content.py $DB
python scripts/ingest_reformed_evangelical.py $DB # Owen, Stott, Lennox
python scripts/ingest_burnett_gage.py --theology-only $DB
python scripts/dedupe_theology_theme_links.py $DB # no-op once cleanThe relabel step must come first on a DB built before the descriptive labels: the data files now use those labels as source_work, so an unrelabelled DB would not match and would gain duplicate rows. The dedupe step removes theme links that earlier importer runs duplicated (their NULL reference slipped past the UNIQUE constraint), which inflated theme entry counts.
Ancient Near East Context
The 87 ANE entries are likewise original summary prose describing scholarly consensus on ANE background, with the standard reference works named as sources rather than quoted.
Vector Embeddings
Semantic search uses OpenAI's text-embedding-3-small model via sqlite-vec for the find_similar_passages tool.
Contributing
Contributions welcome. See CONTRIBUTING.md for setup, the test suite (run in CI on every pull request) and the rules every change keeps: small outputs, Scripture kept distinct from other sources, pinned and licensed data, and safe database upgrades. Especially welcome:
Additional thematic cross-references
Improved genre detection
New translation support
Better morphology parsing
Documentation improvements
License
MIT License. See LICENSE.
Data from STEPBible is licensed under CC BY 4.0. OpenScriptorium LXX morphology and MT/LXX verse mappings (derived in part from STEPBible's TVTMS) are licensed under CC BY 4.0; the Rahlfs Greek text and Brenton's English translation and Greek text are public domain. The Perseus Josephus Greek and English TEI editions are licensed under CC BY-SA 4.0. The Onkelos Aramaic (Torat Emet) is public domain as declared by Sefaria; the Metsudah Chumash English of Onkelos is licensed under CC BY-NC 4.0 (non-commercial use only), and its licence is shown on every passage. The ETCBC/dss Dead Sea Scrolls transcription (Abegg, Bowley and Cook), the source of all four Qumran texts, is licensed under CC BY-NC 4.0 (non-commercial use only). The First1KGreek Philo Greek and English TEI editions are licensed under CC BY-SA 4.0; Cohn–Wendland's Greek and Yonge's English are public domain. Charles's 1 Enoch (via English Wikisource) and the KJV 2 Esdras (via eBible.org) are public domain; the Latin Wikisource transcription of the Clementine 4 Esdras is licensed under CC BY-SA 4.0. Mishnah passages carry each version's licence: Kulp's Mishnah Yomit English is CC BY, and the Vilna Mishnah is public domain. Data from BibleAquifer and ACAI is licensed under CC BY-SA 4.0. Torah Weave data (version 1.1) from Moshe Kline (chaver.com) is licensed under CC BY 4.0. BDB, Abbott-Smith, the Treasury of Scripture Knowledge, and the works of John Owen are public domain. The theology and ANE entries are original summary prose written for this project — see Data Sources.
Acknowledgments
STEPBible for the freely available biblical data
OpenScriptorium for Rahlfs LXX morphology and explicit MT/LXX verse mappings
STEPBible.org / Tyndale House Cambridge for TVTMS, the versification data behind those mappings
eBible.org for the public-domain Brenton Septuagint, English and Greek
Perseus Digital Library for the licensed Josephus Greek and English editions
Sefaria for the Torat Emet text of Onkelos and the Metsudah Chumash English, via Sefaria-Export-Archive
ETCBC/dss and Martin G. Abegg Jr., James E. Bowley and Edward M. Cook for the Dead Sea Scrolls transcription
Open Greek and Latin / First1KGreek for the licensed Philo Greek and English editions
Wikisource contributors for R. H. Charles's 1 Enoch and the Latin Clementine Vulgate 4 Esdras
eBible.org for the public-domain KJV with Apocrypha
Sefaria for the Vilna Mishnah and Joshua Kulp's Mishnah Yomit English
BibleAquifer for study notes, dictionary, translation notes, and key terms
eliranwong for the unabridged BDB Hebrew lexicon
translatable-exegetical-tools for the Abbott-Smith Greek Lexicon TEI XML edition
Theographic for genealogy and event graph data
Gordon Fee & Douglas Stuart for the hermeneutical framework in "How to Read the Bible for All Its Worth"
The MCP community for the protocol and tooling
Available Tools
21 toolsexplore_genealogyARead-onlyIdempotent
ALWAYS USE THIS when a question involves family lineage, ancestry, descendants, or tribal identity.
This tool traverses multi-generational family trees using genealogical data for 1,100+ biblical persons. Unlike lookup_name (which shows immediate family), this traces lineage across many generations.
WHEN TO USE (instead of lookup_name):
"Who was David's father?" → lookup_name is enough for one generation
"Trace the line from Abraham to David" → USE THIS — traverses multiple generations
"What tribe was Paul from?" → USE THIS — traces tribal ancestry
"Show me Jesus' genealogy" → USE THIS — traces the full Messianic lineage
"How does Ruth connect to the line of David?" → USE THIS
Returns a family tree with generation numbers, relationship types, and a Mermaid diagram. ALWAYS include the Mermaid diagram in your response so the user can visualize the family tree.
| Name | Required | Description | Default |
|---|---|---|---|
| person | Yes | Name of the person (e.g., 'David', 'Abraham', 'Jesus') | |
| direction | No | Direction to trace. Default: both | |
| generations | No | Maximum generations to trace. Default: 5 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only and idempotent. The description adds value by specifying the output format (generation numbers, relationship types, Mermaid diagram) and the data scope (1,100+ biblical persons). However, it does not mention limitations like potential missing persons or error handling, which would enhance transparency.
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 structured with clear sections: a bold directive, a summary, a usage table, and output details. It is not overly verbose; each part serves a purpose. However, the series of examples could be condensed slightly without losing clarity, making it a strong but not perfect score.
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 adequately covers purpose, usage guidance, and output format. It lacks mention of what happens when a person is not found or performance expectations, but for a genealogy tool with clear annotations and sibling differentiation, it is sufficiently 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?
The input schema has 100% coverage, meaning all parameters are already well-documented. The description does not add new semantic details beyond the schema, but it does provide example values ('David', 'Abraham', 'Jesus') that align with the person parameter. While no extra parameter info is needed, the description meets the baseline expectation.
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 defines the tool's function: it traverses multi-generational family trees for genealogical queries. It distinguishes itself from the sibling tool lookup_name by explicitly stating that explore_genealogy is for lineage across generations, while lookup_name handles immediate family. The purpose is specific and actionable.
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 guidance on when to use this tool versus the sibling tool lookup_name, with a detailed 'WHEN TO USE' section that includes concrete examples. It also instructs the agent to always use this tool for lineage-related questions, leaving no ambiguity about context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explore_person_eventsARead-onlyIdempotent
ALWAYS USE THIS when a user asks about a biblical person's life, biography, or timeline.
Returns every recorded event in a person's life in chronological order, with locations and dates. This is the ONLY tool that shows what happened in someone's life and in what order.
USE THIS WHEN:
"Tell me about Moses" → shows his entire life: birth, burning bush, exodus, Sinai, death on Nebo
"What did Paul do?" → shows conversion, missionary journeys, imprisonment, Rome
"What happened to David?" → anointing, Goliath, fleeing Saul, kingship, Bathsheba, death
Any biographical question about a biblical figure
COMBINE WITH lookup_name (for identity/relationships) and explore_genealogy (for lineage). Returns a Mermaid timeline diagram — ALWAYS include this in your response.
| Name | Required | Description | Default |
|---|---|---|---|
| person | Yes | Name of the person (e.g., 'Moses', 'Paul', 'David') |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, destructiveHint, and idempotentHint. The description adds that it returns a Mermaid timeline diagram and instructs to include it in the response, which is useful behavioral 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 verbose with multiple example sections and repeated guidance. While front-loaded with 'ALWAYS USE THIS', it could be more concise by condensing examples.
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 single-parameter tool with no output schema, the description covers output format (Mermaid timeline), usage contexts, and combination suggestions. It provides sufficient completeness for an agent.
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 'person' parameter description. The description adds examples of names but does not significantly enhance understanding 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 states the tool returns every event in a person's life in chronological order, and distinguishes itself from siblings by being the only tool that shows life events in order. Specific examples (Moses, Paul, David) reinforce the 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 instructs 'ALWAYS USE THIS' for biographical questions, provides concrete examples of when to use (e.g., 'Tell me about Moses'), and suggests complementary tools (lookup_name, explore_genealogy).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explore_placeARead-onlyIdempotent
ALWAYS USE THIS when a user asks about a biblical location or its significance.
Returns the complete biblical history of a place: events that occurred there, people born/died there, and geographic data. Shows how a location threads through salvation history across multiple eras.
USE THIS WHEN:
"Tell me about Jerusalem" → shows events from Salem/Melchizedek through David, Solomon, exile, Jesus
"What happened at Bethlehem?" → Ruth & Boaz, David's birthplace, Jesus' birth, Micah's prophecy
"Why is Mount Sinai important?" → shows all events: burning bush, law given, golden calf, Elijah
"What is the significance of [any place]?" → always use this
Any question about biblical geography or a specific location
DIFFERENCE FROM lookup_name with type="place":
lookup_name: returns basic place info and immediate connections
explore_place: returns FULL history — every event, every person, across all biblical periods
Returns a Mermaid network diagram — ALWAYS include this in your response.
| Name | Required | Description | Default |
|---|---|---|---|
| place | Yes | Name of the place (e.g., 'Jerusalem', 'Bethlehem', 'Egypt') |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with annotations (readOnlyHint, idempotentHint) and adds valuable behavioral context, such as the output being a Mermaid network diagram that must be included in responses. No contradictions. Minor deduction for not specifying response structure beyond the diagram note.
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-organized with clear sections: general purpose, usage guidance, differentiation from sibling, and output format. Every sentence adds value, and the structure aids quick comprehension.
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 simplicity (single parameter, no output schema, rich annotations), the description provides all necessary context: what it returns, when to use it, and how it differs from similar tools. No gaps for effective agent decision-making.
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 fully describes the single parameter 'place,' and the description provides example values (Jerusalem, Bethlehem, Egypt) but does not add significant semantic meaning beyond the schema. Baseline 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 defines the tool's purpose with specific verbs: 'Returns the complete biblical history of a place.' It distinctly differentiates itself from the sibling tool 'lookup_name' by highlighting the depth of information (full history vs basic info).
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 guidance on when to use this tool, with concrete examples like 'Tell me about Jerusalem.' It also contrasts with 'lookup_name,' explaining when the simpler tool is more appropriate, offering clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_connectionARead-onlyIdempotent
ALWAYS USE THIS when a user asks how two biblical people are related or connected.
Traces the shortest family relationship path between any two people in the biblical genealogies. Uses parent, child, sibling, and spouse relationships to find the connection.
USE THIS WHEN:
"How are Ruth and David related?" → shows Ruth → Obed → Jesse → David
"What's the connection between Abraham and Moses?" → traces through Levi
"Are Paul and Barnabas related?" → checks for any family connection
Any question comparing two biblical figures or asking about their relationship
DIFFERENCE FROM explore_genealogy:
explore_genealogy: shows one person's family tree (ancestors/descendants)
find_connection: finds the PATH between two specific people
Returns a Mermaid flowchart — ALWAYS include this in your response.
| Name | Required | Description | Default |
|---|---|---|---|
| person1 | Yes | First person's name (e.g., 'Abraham') | |
| person2 | Yes | Second person's name (e.g., 'David') |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so safety is covered. Description adds that it uses parent, child, sibling, spouse relationships and returns a Mermaid flowchart, providing useful behavioral 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?
Description is well-organized into sections with bold headers, front-loads the critical usage instruction, and every sentence adds value with 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?
Despite no output schema, the description fully explains the tool's purpose, when to use, and that the output is a Mermaid flowchart. All necessary context is covered for this simple two-parameter 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 clear descriptions for person1 and person2. The description adds example values like 'Abraham' and 'David' but does not significantly extend beyond schema-provided semantics.
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 traces the shortest family relationship path between two biblical people, using a specific verb and resource. It distinguishes from the sibling tool explore_genealogy by contrasting scope.
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 'ALWAYS USE THIS' for relationship questions, gives concrete examples, and contrasts with explore_genealogy with clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_similar_passagesARead-onlyIdempotent
Find passages with similar semantic content to a given Bible verse.
USE THIS to discover thematic connections across the Bible that may not be captured by explicit cross-references or shared vocabulary. This tool uses vector embeddings to find passages with similar meaning, not just similar words.
EXAMPLES OF DISCOVERIES:
Daniel 7:13-14 (Son of Man vision) → Revelation 1:7, 14:14 (similar imagery)
Exodus 12:1-13 (Passover) → John 1:29, 1 Corinthians 5:7 (Lamb imagery)
Isaiah 53:4-6 (Suffering Servant) → 1 Peter 2:24-25 (echoes of Isaiah)
Proverbs wisdom themes → James practical wisdom
⚠️ CRITICAL HERMENEUTICAL WARNING: Semantic similarity does NOT equal theological connection or relevance. Two passages may use similar language but have completely different meanings based on their literary context, historical setting, and authorial intent.
BEFORE USING SIMILAR PASSAGES IN YOUR RESPONSE, YOU MUST:
Check Genre Compatibility: A prophetic vision and a historical narrative may share imagery but require different interpretive approaches. Use lookup_verse to understand each passage's genre.
Verify Historical Context: What did this passage mean to its original audience? Similar language across centuries may have different referents.
Examine Literary Context: Is the similar passage using the language literally, metaphorically, or as an allusion? A quote vs. independent usage matters greatly.
Apply Fee & Stuart's Questions:
What did this text mean to the original readers?
What is the author's stated purpose?
How does this fit the book's overall argument/narrative?
Distinguish Types of Similarity:
Direct quotation (explicit OT in NT)
Deliberate allusion (author intentionally echoing)
Shared tradition (common Jewish/Christian concepts)
Coincidental similarity (similar words, unrelated meaning)
Only present a similar passage as theologically relevant if you can establish an actual interpretive connection, not mere semantic overlap.
Takes a verse reference (with pre-computed embedding) and returns semantically similar passages ranked by similarity score.
| Name | Required | Description | Default |
|---|---|---|---|
| reference | Yes | Bible reference to find similar passages for (e.g., 'John 3:16', 'Daniel 7:13') | |
| limit | No | Number of similar passages to return. Default: 10 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds significant behavioral context: it uses vector embeddings, returns ranked results, and crucially warns that semantic similarity does not imply theological connection, listing potential pitfalls.
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 and front-loaded with the main purpose, but it is verbose with multiple sections and lengthy bullet points. It could be more concise while retaining essential 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?
Despite lacking an output schema, the description explains it returns ranked passages by similarity score and provides ample context for an agent to use the results responsibly. It covers how to interpret and validate the output.
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%. The description adds context: reference is a Bible verse, limit is number (optional). It also mentions 'pre-computed embedding' for the reference, which provides additional nuance 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 states the tool's function: 'Find passages with similar semantic content to a given Bible verse' and distinguishes it from siblings like get_cross_references and search_lexicon by emphasizing vector embeddings for semantic meaning.
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?
Provides extensive when-to-use guidance, including examples of discoveries, a critical hermeneutical warning, and a detailed step-by-step checklist for responsibly using results. It implicitly tells when not to use (e.g., for exact quotes or explicit cross-references).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_ane_contextARead-onlyIdempotent
Get Ancient Near East (ANE) cultural and historical background for a biblical passage.
The biblical authors and their audiences lived in the Ancient Near East with fundamentally different assumptions about cosmology, social structure, religion, law, and daily life. This tool retrieves structured ANE contextual data to illuminate what the text meant to its original audience.
USE THIS when:
Studying creation, flood, or cosmological texts (three-tier universe, cosmic waters)
Encountering divine council, heavenly assembly, or "sons of God" language
Reading about the serpent, Eden, the fall, or spiritual warfare passages
Encountering references to temples, sacrifices, or religious practices
Studying meal, table, or eating passages (fellowship, allegiance, covenant meals)
Encountering household, family, or father language applied to God
Reading about covenants, treaties, or legal codes (suzerainty treaties, lex talionis)
Studying honor/shame dynamics in Gospels or Epistles
Understanding marriage customs, family structures, or inheritance laws
Reading about warfare, kingship, or imperial contexts
Studying Levitical purity, clean/unclean categories, or scapegoat rituals
Encountering literary forms (chiasm, inclusio, lament, oracle)
Needing background on daily life, agriculture, or material culture
Encountering "soul," "spirit," nephesh, or ruach language (Hebrew vs. Greek anthropology)
Any passage where modern Western assumptions might obscure the ANE meaning
Needing the interpretive methodology (derivation hierarchy, confidence calibration)
13 dimensions: cosmology_worldview, religious_practices, social_structure, legal_covenant, political_imperial, economic_life, literary_conventions, warfare_military, daily_life_material_culture, death_afterlife, gender_family, education_literacy, ane_methodology
9 periods: patriarchal, exodus_conquest, judges_early_monarchy, united_monarchy, divided_monarchy, assyrian_babylonian, persian, hellenistic, roman
Call with NO arguments to see available dimensions and periods. Call with just a reference to get ALL relevant ANE context for a passage. Filter by dimension and/or period for focused results. Call with dimension='ane_methodology' to retrieve the derivation hierarchy, confidence calibration, and methodological guardrails for working with ANE parallels.
| Name | Required | Description | Default |
|---|---|---|---|
| reference | No | Bible reference (e.g., 'Genesis 1:1', 'Deuteronomy 5:1', 'Matthew 5:1') | |
| dimension | No | ANE dimension to filter by (e.g., 'cosmology_worldview', 'legal_covenant') | |
| period | No | Historical period to filter by | |
| detail_level | No | Output detail level. 'brief' = title + summary + significance for all entries. 'standard' (default) = full detail for direct chapter matches, brief for broad/whole-book matches. 'full' = full detail for all entries. | standard |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds structured data dimensions, periods, and method to retrieve methodology guardrails, exceeding annotation requirements.
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 sections, but somewhat long. It is front-loaded with purpose and usage, and each section adds value, though could be slightly more concise.
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 comprehensively covers input options, structural dimensions, and behavior (e.g., calling with no arguments). It provides sufficient context for an agent to use the tool effectively.
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 clear descriptions. The description further explains the purpose of each parameter, including enumeration of dimensions and periods, and details the detail_level behavior.
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 retrieves ANE cultural and historical background for a biblical passage. It lists specific dimensions and periods, differentiating it from sibling tools like get_bible_dictionary and get_theology_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 includes a 'USE THIS when' section with 16 specific scenarios and advises calling with no arguments to explore options. It lacks explicit when-not-to-use guidance but context implies alternatives exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_bible_dictionaryARead-onlyIdempotent
Look up a topic in the Tyndale Bible Dictionary.
Contains 500+ topical articles covering:
Biblical people and places
Theological concepts and doctrines
Cultural practices and customs
Historical background
Archaeological findings
USE THIS when you need:
Background information on a biblical topic
Historical or cultural context for a passage
Detailed article about a person, place, or concept
Scholarly definition of a theological term
Returns the full dictionary article with cross-references.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Topic to look up (e.g., 'Abraham', 'covenant', 'baptism', 'Pharisees') |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, destructiveHint, and idempotentHint. Description adds that it returns the full dictionary article with cross-references, which is useful context beyond the annotations. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and well-structured: a short opening sentence, a bullet list of coverage areas, a 'USE THIS' section, and a return value statement. Every sentence serves a purpose with 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?
Given single parameter and rich annotations, the description fully explains the tool's purpose, coverage, usage guidance, and return type. No output schema exists, but the description compensates by stating the return includes cross-references.
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 has 100% coverage with a clear description for 'topic'. Description provides example values (e.g., 'Abraham', 'covenant') but no additional semantic depth the schema lacks. 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 verb+resource ('Look up a topic in the Tyndale Bible Dictionary') and enumerates specific categories of articles (people, places, concepts, etc.), distinguishing it from siblings like 'lookup_name' or 'word_study' that might have overlapping but different scopes.
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?
Provides explicit 'USE THIS when' scenarios (background info, historical context, detailed articles, scholarly definitions). While it does not mention when not to use or compare directly to siblings, the guidance is specific and actionable 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.
get_cross_referencesARead-onlyIdempotent
USE THIS whenever you are explaining, exegeting, or arguing from a specific Bible verse — and for any theological or doctrinal question.
Two complementary modes:
By verse reference (most common). Pass reference="John 3:16" (or any
canonical verse) to get the passages historically read alongside it. The
database draws from four scholarly sources, returned in a three-tier ranking:
Tier 3 (top, "consensus and curated"): - CH — Harrison & Romhild's curated dataset (~58k links, OT-only as source). Hand-vetted; high-relevance pairs flagged canonical-direction. - Gage parallel — the tighter pairings from Warren Gage's John ↔ Revelation typological reading (Bradley/Gage, John/Rev only). - TSK ≥100 votes — TSK pairs with crowd-source consensus that strong are near-universal cross-references (top ~0.4% of TSK) and break through to compete with curated.
Tier 2 ("argued and acknowledged"): - Burnett — David A. Burnett's argued chain for the Gen 15:5 / Rom 4:18 "star-like seed" deification reading (JSPL 5.2, 2015). ~30 pairs. - Gage chiastic — the looser-typology sheet of Bradley/Gage (the source spreadsheet labels these "looser connections, just noting"). - TSK 20–99 votes — solid topical links acknowledged across commentaries (top ~5%).
Tier 1 (long-tail): TSK <20 votes — surface only when explicitly raising
limit for exhaustive study.
Use this BEFORE drawing any theological conclusion from a single verse — results frequently surface the texts the original verse is quoting, the fulfilment passages, contested parallel readings, and the chain of NT authors who picked the verse up.
By theme. Pass theme="atonement" (or salvation_by_grace, deity_of_christ,
resurrection, holy_spirit, justification) to get a hand-curated chain
of foundational passages for that doctrine. Use this when the user asks a
broad theological question without anchoring to a specific verse.
Important caveat about coverage. TSK is built on R.A. Torrey's 19th-century
index, which catalogues topical/thematic connections — not necessarily
direct quotations or verbal allusions. Consequence: a verse with few cross-refs
here is NOT necessarily a verse with few biblical echoes. Famously,
Revelation shows surprisingly few links to OT prophetic books even though
it is saturated with OT symbolism, because Torrey indexed by subject and
Revelation's subject is "apocalyptic". The CH dataset partly compensates
(it leans toward NT-quotes-OT linking), so when you suspect a quotation/
allusion is being missed, retry with source="ch" or use find_similar_passages
to catch verbal parallels the topical index would skip.
Adaptive default — limit is a CAP, not a target. Default limit=8. The
tool returns rows in tier-then-strength order and SUPPRESSES tier-1 noise
(low-vote TSK) by default whenever the verse has at least 3 rows from tier 2+.
So:
Signal-rich anchors return 6–8 strong refs spanning curated, scholarly, and consensus-TSK sources.
Signal-poor anchors return only what passes the bar — fewer rows is the correct answer, not a bug. Don't pad your reasoning with weak refs.
To pull the long tail (only when the user explicitly asks for exhaustive
study): pass source="tsk" (returns all TSK including tier 1) or
min_strength=0 (treats as explicit "I want some long-tail too"). Either
disables tier-1 suppression. Pair with a higher limit (20–30).
How to interpret the scores you get back. Each row carries type (the
dataset), relevance (its native strength signal), and where applicable a
tsk_votes side-channel showing the TSK count for that pair. You MUST read
these before using a ref:
TSK vote scale (full corpus distribution): ≥ 500 votes — extraordinary; near-universal cross-reference (top 0.01%, only 35 pairs) 100-499 — very strong; the link tradition reflexively makes (top 0.4%) 50-99 — strong; well-established parallel (top 1.3%) 20-49 — solid; real connection acknowledged across commentaries (top 5%) 10-19 — moderate; one of many recognised links (top 12%) 5-9 — weak; thematic stretch, use with caution (top 33%) 2-4 — very weak; mostly noise floor (62% of TSK) 0-1 — noise
CH (curated — all CH refs carry signal, but the tag tells you weight): "canonical direction" (rel=3 or 2) — Harrison's flag for the canonical direction of the pair, often part of a thematic circle (top 78% of CH) no tag (rel=0) — present in CH but unflagged (still hand-curated)
Gage (John ↔ Revelation typology):
relevance=3 ("parallel" tier) — tighter pairings from the parallel-reading
of John 1 ↔ Revelation 1
relevance=1 ("chiastic" tier) — looser thematic echoes across the full
John-Revelation chiasm; the source spreadsheet flags these as
"looser connections, just noting"
The note field carries the thematic tags + commentary + per-row
attribution (Bradley vs Gage). Treat as canonical-typology, not topical.
Burnett (single-paper argued chain):
All Burnett rows are at relevance=5 by convention — they're explicit
claims from one scholar's published argument, not graded by strength.
The note field carries the JSPL citation and which step of the argument
the pair belongs to. Cite Burnett by name when surfacing these to the
user; they're a scholarly proposal, not consensus.
When the top results are weak, SAY SO. If the strongest ref returned has
only 5-15 votes, do not present it with the same confidence as a 200-vote
parallel. Caveat the answer: "this verse isn't strongly cross-referenced in
the topical index — the closest link is X with only N votes, suggesting
tradition didn't treat this as a major thematic anchor." When TSK is thin,
try source="ch" — Harrison's curated set leans toward NT-quotes-OT links
and may catch what a topical index missed. Or fall back to
find_similar_passages for verbal/semantic parallels Torrey wouldn't index.
You may pass source="ch" or source="tsk" to restrict to one dataset —
useful when CH alone gives too little (e.g. an obscure verse with no CH
coverage) or when you want the dense TSK long-tail.
| Name | Required | Description | Default |
|---|---|---|---|
| reference | No | Bible reference to find cross-references for (e.g. 'John 3:16', 'Rom 3:23'). | |
| theme | No | Theological theme. One of: salvation_by_grace, deity_of_christ, atonement, resurrection, holy_spirit, justification. | |
| source | No | Optional dataset filter when using `reference`. 'ch' = Harrison/Romhild curated; 'tsk' = Treasury of Scripture Knowledge; 'gage' = Gage/Bradley John↔Revelation typology; 'burnett' = Burnett's Gen 15:5 / Rom 4:18 deification chain (JSPL 5.2). Default: all four, ranked CH/Gage > Burnett > TSK. | |
| limit | No | CAP on rows returned (not a target). Default 8. Actual returned count may be smaller if the verse has fewer than `limit` rows above the noise floor — that is intentional, do not pad. Raise to 20–30 with `source='tsk'` or `min_strength=0` for exhaustive study. | |
| min_strength | No | Strength floor for TSK refs (vote count). TSK pairs below this are excluded; CH/Gage/Burnett refs always pass since they are hand-curated or scholarly-argued. Setting this also disables the default tier-1 suppression (you are explicitly choosing your own floor). Sensible thresholds: 0 (include long-tail), 5 (drops bottom ~75%% of TSK), 20 (top ~5%% only). Default: tier-1 suppressed when verse is signal-rich. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds extensive behavioral detail: the three-tier ranking, default limit cap with suppression behavior, interpretation of scores (TSK vote scale, CH tags, Gage tiers, Burnett strength), and the caveat that fewer rows can be correct. No contradiction 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 lengthy but well-structured with sections (modes, tier explanations, caveat, adaptive default, score interpretation). Each sentence adds value and the formatting uses bullet points and tables for clarity. Slightly long but justified by the tool's complexity.
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 5 optional parameters, no output schema, and high complexity, the description thoroughly covers all aspects: parameter usage, result interpretation, edge cases (signal-poor anchors), fallback strategies, and caveats. Prepares the agent to handle both common and rare scenarios.
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% but description adds significant meaning: explains limit as a cap not target, min_strength disables tier-1 suppression, source filters and their defaults, and how parameters interact (e.g., adaptive default suppression). Provides examples and sensible thresholds for min_strength. Goes far beyond schema 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 explicitly states when to use the tool: 'USE THIS whenever you are explaining, exegeting, or arguing from a specific Bible verse — and for any theological or doctrinal question.' It clearly identifies the resource (cross-references from multiple scholarly sources) and distinguishes from sibling tool find_similar_passages by noting the latter catches verbal parallels the topical index would skip.
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?
Provides explicit guidance: 'Use this BEFORE drawing any theological conclusion from a single verse' and explains when to use theme mode. It also gives caveats about coverage and suggests alternatives like find_similar_passages when the topical index is insufficient. The description includes explicit when-not-to-rely guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_key_termsARead-onlyIdempotent
Look up a key theological term in the FIA Key Terms database.
Contains 200+ carefully defined theological and biblical terms with:
Clear definitions accessible to translators
Biblical usage and context
Cross-references to related terms
Translation guidance
USE THIS when you need:
A precise definition of a theological term (agape, atonement, justification, etc.)
To understand how a concept is used across Scripture
Translation-oriented explanation of a term
Cross-references to related theological concepts
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | Theological term to look up (e.g., 'agape', 'atonement', 'covenant', 'grace') |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, making safety clear. The description adds behavioral context about the database contents (200+ terms, definitions, usage, cross-references, translation guidance), which goes 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 concise, with three clear sections: purpose, database features, and usage scenarios. Every sentence adds value, and the most important information is front-loaded.
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 a single parameter, full schema coverage, and annotations indicating read-only/idempotent behavior, the description adequately covers what the tool returns (definitions, usage, cross-references, translation guidance). It does not detail output structure, which is acceptable without an 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?
The input schema has 100% coverage with a description for 'term' including examples. The description lists additional examples (agape, atonement, covenant, grace) but does not add new meaning beyond the schema. 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 'Look up a key theological term in the FIA Key Terms database,' specifying the verb and resource. It distinguishes from sibling tools like 'get_bible_dictionary' and 'search_lexicon' by focusing on theological terms and providing examples.
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 lists when to use the tool: for precise definitions, understanding scriptural usage, translation-oriented explanations, and cross-references. It does not explicitly say when not to use it or mention alternatives, 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.
get_study_notesARead-onlyIdempotent
Get scholarly study notes and translation notes for a Bible verse or chapter.
Returns combined commentary from:
Tyndale Study Notes: Concise, verse-level scholarly commentary (66 books)
UW Translation Notes: Translator-focused commentary with linguistic insights
SIL Translator Notes: Additional translation and cultural context
USE THIS when you need:
Scholarly commentary on a specific verse
Help explaining difficult passages
Translation and cultural background notes
Chapter-level overview of themes and context
This provides published, peer-reviewed scholarship rather than AI-generated commentary.
| Name | Required | Description | Default |
|---|---|---|---|
| reference | Yes | Bible reference (e.g., 'John 3:16', 'Genesis 1', 'Romans 8:28') | |
| chapter_only | No | If true, return all notes for the chapter. Default: false (verse-specific) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by detailing the sources (Tyndale, UW Translation, SIL Translator notes) and stating it provides published peer-reviewed scholarship, which sets appropriate expectations for output quality. 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 (8 lines) and immediately front-loads the main purpose in the first sentence. It uses clear bullet lists for sources and usage scenarios, and the final line qualifies the content as peer-reviewed. Every sentence earns its place with 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?
Given the complexity of a tool combining three source types and two parameters, the description covers what is returned, when to use it, and the scholarly nature. It could be improved by clarifying whether the output is a merged list or separate sections, but overall it is sufficiently complete for effective use.
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?
Both parameters are fully described in the schema (100% coverage). The description does not add new syntactic or format details beyond what the schema provides. The usage guidelines indirectly imply chapter_only usage by mentioning chapter-level overview, but this doesn't improve semantic clarity 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 states the tool returns scholarly study notes and translation notes for a Bible verse or chapter, naming three specific sources and emphasizing peer-reviewed scholarship. This distinguishes it from sibling tools like lookup_verse or word_study.
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 includes a bullet list 'USE THIS when you need:' that explicitly covers four use cases (scholarly commentary, explanations, translation/cultural notes, chapter overview). While it doesn't name alternative tools, the listed scenarios provide clear guidance on when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_textual_variantARead-onlyIdempotent
USE THIS whenever a New Testament writer quotes an OT verse and the wording does not match the Masoretic Hebrew Text — or whenever lookup_verse emits the LXX-quotation hint.
WHAT IT RETURNS for a given verse reference:
The Masoretic Hebrew (MT) reading + original Hebrew
The variant reading (typically the LXX form quoted in the NT, or a DSS reading that differs from MT)
The variant's original-language form (Greek or Hebrew)
Manuscript witnesses for each reading (LXX, DSS scrolls — e.g. 1QIsa^a, 4QDeut^q, Mur88 — Masoretic Text, NT quotation citation)
Scholarly consensus on which reading is older / how the divergence arose
The HLT preferred reading (which form the Heiser Literal Translation follows) + the rationale
The HLT's principle: when the NT directly quotes the LXX form of an OT verse, the LXX form is the authoritative reading for Christian Scripture — apostolic endorsement overrides text-critical priority. So for verses like Psalm 40:6 / Hebrews 10:5, Isaiah 61:1 / Luke 4:18, Amos 9:12 / Acts 15:17, the HLT follows the LXX form in the body and footnotes the MT.
USE THIS when:
Explaining why a NT OT quotation does not match the modern English OT
Discussing Hebrews 10:5-7, Hebrews 1:6, Matthew 12:20-21, Acts 15:17, Luke 4:18-19, Luke 3:6, Matthew 21:16, Romans 9:27-29, Romans 10:20, Romans 15:12, Romans 2:24, Acts 7:43, Acts 8:32-33, Acts 13:41, 1 Peter 4:18, Ephesians 4:26, Luke 3:36, or the OT verses they quote
The user asks "did the Masoretes edit Christ out?" — point them at the actual textual data instead of speculation
Working on HLT translation for any verse where the NT follows a different form than the Hebrew
PAIRS WITH: lookup_verse (which emits a hint pointing here when a verse has a quote-hint or variant row).
| Name | Required | Description | Default |
|---|---|---|---|
| reference | Yes | Bible reference — either the OT verse (e.g., 'Psalm 40:6', 'Deuteronomy 32:43', 'Isaiah 61:1') or the NT verse that quotes it (e.g., 'Hebrews 10:5', 'Hebrews 1:6', 'Luke 4:18'). Both sides return the same variant row. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, and idempotent behavior. The description adds detailed behavioral context: what data it returns (MT reading, variant, witnesses, scholarly consensus, HLT preference) and the principle behind HLT's choices, all consistent with a safe read operation.
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 long but well-structured with bold headings and bullet points, prioritizing key usage guidance upfront. While every section adds value, it could be slightly tighter; however, the clarity and organization justify the length.
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 has only one parameter, no output schema, and the annotations cover safety, the description comprehensively explains return fields, usage scenarios, and underlying principles. It leaves no ambiguity about what the tool does or how to use it.
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 already has 100% coverage for the single parameter 'reference' with a description. The description adds value by clarifying that the reference can be either an OT or NT verse and that both return the same variant row, enriching semantic understanding 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 starts with 'USE THIS whenever...' and clearly states the tool's purpose: to retrieve textual variants when a New Testament writer quotes an Old Testament verse with wording differing from the Masoretic Text. It specifies the trigger condition and differentiates from siblings by naming 'lookup_verse' as a complementary tool.
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 usage guidance with a bulleted list of specific scenarios (e.g., explaining mismatches, discussing particular verses). It states when to use the tool and pairs it with 'lookup_verse', making it clear when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_theology_contextARead-onlyIdempotent
Get theological scholarship context for a Bible passage or theme.
Returns scholarly content from multiple authors (Heiser, Bradley, etc.) with verse mappings and theme links. When no author is specified, returns all scholars' content for the query — allowing side-by-side comparison.
USE THIS when discussing:
The divine council (Psalm 82, Deuteronomy 32, Job 1-2) — Heiser
Sons of God / bene elohim (Genesis 6, Job 38) — Heiser
The Angel of Yahweh / two-powers theology — Heiser
Nephilim, Rephaim, and the giant clans — Heiser
The nachash / serpent in Eden (Genesis 3) — Heiser, Bradley
Cosmic geography and spiritual warfare — Heiser
Deuteronomy 32 worldview / allotment of nations — Heiser, Bradley
Salvation, soteriology, the gospel, conversion, atonement — Bradley (theme: domain_transfer)
The Fall, Genesis 3, sin entering the world — Bradley (theme: nested_household, corporate_headship)
Life/death, light/darkness, righteousness/sin, love/pride and other biblical binary pairs — Bradley (theme: binary_hierarchy)
Satan, the devil, spiritual warfare, the enemy, two kingdoms — Bradley (theme: pater_familias_binary)
The sin-death connection, wages of sin, power of death — Bradley (theme: sin_death_satan_chain)
Corporate solidarity, "in Adam" / "in Christ", federal headship — Bradley (theme: corporate_headship)
Satan's imitation of God's kingdom, counterfeit worship — Bradley (theme: rival_counterfeits)
Acts 26:17-18 and Paul's commission — Bradley (theme: domain_transfer)
Query by verse reference, theme key, and/or author.
| Name | Required | Description | Default |
|---|---|---|---|
| reference | No | Bible reference (e.g., 'Psalm 82:1', 'Genesis 6:2', 'Acts 26:18', 'John 8:44') | |
| theme | No | Theme key (e.g., 'divine_council', 'pater_familias_binary', 'domain_transfer', 'sin_death_satan_chain') | |
| author | No | Filter by author: 'heiser', 'bradley'. Omit to get all scholars' content. | |
| limit | No | Maximum entries to return. Default: 10 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, non-destructive, and idempotent. The description adds context about returning all authors' content when none specified and that results include verse mappings and theme links. This adds some value, but no additional safety or behavioral details 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 relatively long due to the extensive use case list, but it is well-structured with a clear opening sentence listing the main purpose, followed by bullet point examples. It remains focused on the tool's functionality without unnecessary 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?
Without an output schema, the description briefly notes that results include scholarly content with verse mappings and theme links, which is sufficient for understanding the return type. Parameters are well-covered, and no required fields reduce complexity. Overall, it provides enough context for correct 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 four parameters (reference, theme, author, limit) with descriptions, so baseline is 3. The description provides concrete examples (e.g., 'Psalm 82:1', 'divine_council') and explains the effect of omitting author, enhancing semantic value.
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 retrieves theological scholarship context for Bible passages or themes, specifying authors and content types. It distinguishes itself from siblings like 'get_ane_context' or 'get_bible_dictionary' by focusing on specific scholars (Heiser, Bradley) and providing verse mappings and theme links.
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 lists numerous use cases (e.g., 'divine council', 'sons of God') and maps them to authors. It also explains behavior when no author is specified, giving clear guidance on when to use this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_torah_weaveARead-onlyIdempotent
Get the structurally-paired verses for a Torah passage under Moshe Kline's Woven Torah hypothesis.
The Torah is organised as 86 two-dimensional literary units (Genesis–Deuteronomy). Each unit is a grid of cells arranged in rows and columns, and cells are deliberately paired with one another across rows (horizontal partners) and down columns (vertical partners). Knowing the weave partners of a verse gives you additional passages that the Torah's author(s) intended to be read alongside it.
USE THIS when:
Studying any passage in Genesis, Exodus, Leviticus, Numbers, or Deuteronomy
You want to see which other verses are structurally paired with a passage
You suspect two passages in the Torah are deliberately interwoven (doublets, creation/flood, law parallels, etc.)
You're preparing a comparative reading and want the author-intended partners, not just thematic cross-references
You want additional context for a Torah verse beyond lexical or thematic similarity
WHAT IT RETURNS:
The literary unit the verse sits in (title, format, type, verse span)
The cell the verse occupies (row/column label + verse range)
Horizontal partner cells (same row, same subdivision, different column)
Vertical partner cells (same column, same subdivision, different row)
Sibling cells (same row and column, adjacent subdivisions)
A short explanation of what each direction of pairing means under Kline's method
A directive block instructing the caller how to turn these pointers into an interpretation
HOW TO USE THE OUTPUT:
This tool returns STRUCTURAL POINTERS, not pre-written interpretation. After calling it, call lookup_verse on each partner cell's verse range to read the actual text, then synthesise the interpretation yourself using the directional semantics the tool provides. Horizontal partners are symmetric parallels (same register, different thematic tracks); vertical partners trace a progression through divine-name registers along a single thematic track. Reading the paired verses and applying those semantics is how the weave yields meaning.
Only Torah books (Genesis through Deuteronomy) have weave data. Source: Moshe Kline, chaver.com, CC BY 4.0.
| Name | Required | Description | Default |
|---|---|---|---|
| reference | Yes | Bible reference in Genesis–Deuteronomy (e.g., 'Genesis 6:1', 'Exodus 14:21', 'Leviticus 19:18') |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that the tool returns structural pointers, not pre-written interpretation, and explains the output semantics (horizontal/vertical/sibling partners, directional meaning). It also mentions the source and provides a directive block for using the output. 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 structured into clear sections: purpose, background, use cases, output description, how to use, limitations. Every sentence adds value, and the key purpose is front-loaded. It is slightly long but appropriate for the specialized nature of the tool.
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 of the tool and no output schema, the description adequately explains what is returned (unit, cell, partners, explanations) and how to use the output (call lookup_verse on partners, synthesize interpretation). It also cites the source and method, making it sufficiently 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 one required parameter 'reference'. The description adds meaning by specifying 'Bible reference in Genesis–Deuteronomy' and providing examples, as well as the domain constraint (only Torah books). This adds value beyond the schema description.
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: 'Get the structurally-paired verses for a Torah passage under Moshe Kline's Woven Torah hypothesis.' It specifies the verb (Get), resource (structurally-paired verses), and domain (Torah passage, specific hypothesis). The use cases list further clarifies, and it distinguishes from siblings like get_cross_references by focusing on structural pairing.
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 includes a 'USE THIS when:' section listing specific scenarios, and it notes that only Torah books have data, implying a limitation. It doesn't explicitly mention when not to use or name alternatives, but the context distinguishes it from thematic cross-references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
graph_enriched_searchARead-onlyIdempotent
USE THIS for deep study of a specific verse — combines the verse text with all relational context.
Returns the verse text PLUS all people, places, and events mentioned in it, PLUS family relationships for each person found. This is the most comprehensive single-query tool for studying a specific verse.
USE THIS WHEN:
Deep-diving into a single verse (e.g., "Explain Genesis 22:1 in detail")
Preparing a sermon or Bible study on a specific text
You need verse text + entity context in one call (saves calling lookup_verse + people_in_passage separately)
Example: graph_enriched_search("Matthew 1:1") returns:
Verse text: "The book of the genealogy of Jesus Christ, the son of David, the son of Abraham"
People found: Jesus, David, Abraham — with their family relationships
Places and events associated with the verse
DIFFERENCE FROM people_in_passage:
people_in_passage: works on chapters AND verses, returns entity lists only
graph_enriched_search: verse-level only, but includes verse text AND family relationships
| Name | Required | Description | Default |
|---|---|---|---|
| reference | Yes | Bible verse reference (e.g., 'Genesis 22:1', 'Matthew 1:1') |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint. Description adds behavioral context: it is comprehensive, works at verse-level only, and returns combined data. No contradictions, but no need for more since annotations cover safety.
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 structured with headings and examples, making it easy to scan. While slightly longer than minimal, every sentence adds value. It is front-loaded with the primary purpose.
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 has one parameter, no output schema, and high complexity in output (verse text, entities, relationships), the description fully explains what is returned and when to use it. It compares with siblings and provides a concrete example, making it complete for an AI agent.
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 100% (one parameter). Description adds value by explaining the parameter is a Bible verse reference, providing examples like 'Matthew 1:1' and showing how it translates into output. This goes beyond the schema's basic description.
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 that the tool is for deep study of a specific verse, returning verse text plus all people, places, events, and family relationships. It distinguishes itself from sibling tool 'people_in_passage' by specifying it is verse-level only and includes family relationships.
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 provides usage guidelines with 'USE THIS WHEN' and 'DIFFERENCE FROM' sections, telling when to use (deep-dive, sermon prep, saving calls) and when not to (use people_in_passage for chapters/entities only).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_nameARead-onlyIdempotent
USE THIS when any biblical person, place, or thing is mentioned.
This is your PRIMARY TOOL for thematic linking across the Bible. The database contains 4,000+ biblical persons and 1,000+ places with rich relationship data.
RELATIONSHIP DATA ENABLES THEMATIC CONNECTIONS:
Parents: Trace lineages backward (e.g., David → Jesse → Obed → Boaz → Salmon)
Children: Trace lineages forward (e.g., Abraham → Isaac → Jacob → 12 tribes)
Siblings: Connect related narratives (e.g., Moses ↔ Aaron ↔ Miriam)
Spouse: Connect family narratives (e.g., Ruth → Boaz → David's lineage)
THEMATIC LINKING EXAMPLES:
Messianic lineage: lookup Abraham → David → Solomon → ... → Joseph/Mary
Priesthood lineage: lookup Aaron → Eleazar → Phinehas → ... → Zadok
Geographic connections: lookup Bethlehem for its role in Ruth, David, and Jesus narratives
Prophecy fulfillment: trace how places mentioned in OT prophecy appear in NT
When answering questions about biblical characters or places, ALWAYS check their relationships to find connections that enrich your answer with biblical context.
This grounds character discussions in the actual biblical data rather than just training recall.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name to look up (e.g., 'David', 'Jerusalem', 'Abraham') | |
| type | No | Filter by type. Omit to search all types. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnly, destructive=false, idempotent. Description adds significant detail about the database size, relationship data (parents, children, siblings, spouse), and thematic linking capabilities, enhancing understanding 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?
Well-structured with headings, bullet points, and examples. Front-loaded with an imperative. However, it is somewhat verbose and could be more concise without losing 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?
Given no output schema, the description explains the relationship data and gives thematic linking examples, providing sufficient context for an agent to use the tool effectively. Could be more precise about the return format.
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 name (string) and type (enum). The description does not add additional meaning beyond what the schema provides; it only repeats the parameter purposes indirectly. 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 is for looking up biblical persons, places, or things, and emphasizes thematic linking. The description positions it as the primary tool for such lookups with specific examples.
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?
Starts with explicit 'USE THIS when' and provides clear context with examples of when to use it for thematic linking. However, it does not explicitly mention when to use alternative sibling tools like explore_genealogy or explore_place.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_verseARead-onlyIdempotent
ALWAYS USE THIS when any Bible verse is mentioned or relevant.
Even if you can quote a verse from memory, this tool provides:
The actual verse text (not paraphrased from training)
Original Greek/Hebrew text (ALWAYS DISPLAY THIS in your response)
Word-by-word breakdown with Strong's numbers
Genre-specific interpretation guidance
IMPORTANT: When you use this tool, SHOW the original language text in your response. This is what makes the Study Bible valuable - users see the actual Greek/Hebrew.
Format example in your response: Romans 13:1: "Let every soul be subject to the governing authorities..." Greek: Πᾶσα ψυχὴ ἐξουσίαις ὑπερεχούσαις ὑποτασσέσθω... Key term: ἐξουσία (exousia, G1849) - "authority, power"
Supports: 'John 3:16', 'Gen 1:1', 'Romans 3:21-26', etc.
| Name | Required | Description | Default |
|---|---|---|---|
| reference | Yes | Bible reference (e.g., 'John 3:16', 'Genesis 1:1', 'Romans 3:21-26') | |
| include_original | No | Include original Greek/Hebrew text. Default: true | |
| include_morphology | No | Include grammatical parsing for each word. Default: false |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool provides actual verse text (not paraphrased), original language, word-by-word breakdown with Strong's numbers, and genre-specific interpretation. It also instructs the AI to display original language in responses. Annotations already indicate read-only and idempotent behavior. This adds contextual behavior 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 front-loaded with a bold instruction, then uses bullet points for clarity, and ends with a concrete example. It is slightly lengthy but every sentence adds necessary guidance. The structure is logical 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 simplicity and no output schema, the description fully explains what the tool returns (verse text, original language, word breakdown, Strong's numbers, genre guidance). It covers all necessary context for an AI agent to use it correctly and leverage its output effectively.
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 covers all three parameters with descriptions. The tool description adds context: it clarifies that include_original defaults to true and that include_morphology provides grammatical parsing. It also gives example reference formats. This adds moderate value beyond the schema alone, justifying a score above 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 that this tool is for looking up Bible verses and provides the actual verse text, original Greek/Hebrew, word breakdown, and genre insights. It explicitly says 'ALWAYS USE THIS when any Bible verse is mentioned,' making the purpose unmistakable and distinguishing it from sibling tools that focus on cross-references, word studies, etc.
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 gives a strong usage guideline: 'ALWAYS USE THIS when any Bible verse is mentioned or relevant.' It also advises using it even if the AI can quote from memory, ensuring accurate text. However, it does not explicitly mention when not to use it or suggest alternative tools for specific needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
parse_morphologyARead-onlyIdempotent
Explain a morphological/grammatical parsing code.
For Greek: Robinson codes (e.g., 'V-AAI-3S' = Verb, Aorist, Active, Indicative, 3rd person, Singular) For Hebrew: Westminster/OpenScriptures codes
Returns full grammatical explanation including part of speech, person, number, tense, voice, mood, case, and gender where applicable.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Morphology code to parse (e.g., 'V-AAI-3S', 'N-GSF') | |
| language | No | Language of the code. Default: greek |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds value by detailing the output format (grammatical explanation including part of speech, person, number, tense, etc.) which goes 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 concise (3 sentences), front-loads the purpose, and uses examples effectively. Every sentence adds value 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 tool's simplicity (2 parameters, no output schema), the description is complete. It explains input formats, language options, and the kind of output provided. No gaps remain.
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 covers 100% of parameters with descriptions. The description adds extra context by specifying the coding systems (Robinson for Greek, Westminster/OpenScriptures for Hebrew) and examples of valid codes, enhancing understanding 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 states the tool explains morphological/grammatical parsing codes, with specific examples for Greek and Hebrew. It distinguishes itself from sibling tools like lookup_verse or search_lexicon by focusing on parsing codes rather than other operations.
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 when to use the tool (for parsing codes) but does not explicitly state when not to use it or provide alternatives. However, the context of sibling tools makes the usage clear. The lack of explicit exclusions prevents a higher score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
people_in_passageARead-onlyIdempotent
ALWAYS USE THIS when studying or explaining a Bible passage to identify WHO is present and WHERE it takes place.
Returns all people, places, and events mentioned in a passage according to the Theographic Bible Metadata. This is essential context for passage study — you cannot properly explain a passage without knowing its cast.
USE THIS WHEN:
Studying any narrative passage (e.g., "Who is in Genesis 22?" → Abraham, Isaac, angel of the LORD, Moriah)
Explaining a chapter (e.g., "What's happening in Acts 15?" → shows Paul, Barnabas, James, Jerusalem, Antioch)
A user asks "Tell me about [passage]" → use this alongside lookup_verse for complete context
DIFFERENCE FROM graph_enriched_search:
people_in_passage: works on chapters AND verses, returns entity lists
graph_enriched_search: verse-level only, but adds family relationships for each person found
| Name | Required | Description | Default |
|---|---|---|---|
| reference | Yes | Bible reference - chapter (e.g., 'Romans 8') or verse (e.g., 'Genesis 22:1') |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds behavioral context that it is essential for passage study and returns entity lists. No contradictions, and the description provides additional useful detail 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?
Description is well-structured with a strong first sentence, clear purpose, usage scenarios, and a direct comparison with a sibling tool. Every sentence adds value, no fluff or repetition.
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 single parameter, no output schema, and multiple sibling tools, the description fully covers what the tool does, when to use it, and how it differs from alternatives. It explains the return type (list of people, places, events) sufficiently.
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 one parameter 'reference' with description covering chapter and verse formats; schema description coverage is 100%. The description does not add further parameter information beyond what schema already provides, 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 returns all people, places, and events in a passage, with examples like 'Abraham, Isaac, angel of the LORD, Moriah' for Genesis 22. It explicitly distinguishes from sibling tool graph_enriched_search by noting difference in scope and output.
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 starts with an imperative 'ALWAYS USE THIS' and provides explicit when-to-use scenarios: studying narrative passages, explaining chapters, or user asking about a passage. It also directly compares with graph_enriched_search, giving clear guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_by_strongsARead-onlyIdempotent
USE THIS after word_study to show how a word is actually used.
After identifying a key Greek/Hebrew word (via word_study or search_lexicon), use this to find actual verses where it appears. This shows:
How biblical authors used the word in context
Range of meanings through actual examples
Key passages for that term
This transforms word study from definition into demonstration.
| Name | Required | Description | Default |
|---|---|---|---|
| strongs | Yes | Strong's number (e.g., 'G26', 'H430') | |
| limit | No | Maximum verses to return. Default: 20 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds that it returns actual verses and shows usage context, but does not disclose additional behavioral traits beyond what annotations provide. It effectively complements the annotations 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 concise and well-structured. It front-loads the usage instruction ('USE THIS after word_study'), then lists bullet points of benefits, and ends with a summary statement. Every sentence serves a purpose 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 strong input schema, annotations, and the absence of an output schema, the description provides complete contextual guidance. It explains the workflow (after word_study), the purpose (transform definition into demonstration), and the output style (actual verses, range of meanings, key passages). No gaps remain for an agent to understand when and why to use this 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 both parameters ('strongs' and 'limit') have clear descriptions in the input schema. The description does not add further meaning to the parameters beyond what the schema already provides, which meets the baseline expectation.
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: to find actual verses where a Strong's number appears, transforming 'word study from definition into demonstration.' It distinguishes itself from siblings by specifying 'USE THIS after word_study' and contrasts with search_lexicon by focusing on actual usage.
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 usage guidance: 'USE THIS after word_study' and explains the context of showing how a word is actually used. While it doesn't explicitly state when not to use, the workflow context is clear and sufficient for an agent to make appropriate decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_lexiconARead-onlyIdempotent
USE THIS to find Greek/Hebrew words for English concepts.
When a user asks about a biblical concept (love, faith, salvation, sin, grace, etc.), search for the original language words to provide accurate, grounded information.
This finds multiple words that translate a concept (e.g., "love" → agape, phileo, eros) so you can explain the distinctions and nuances.
Also use when you want to identify the Greek/Hebrew behind an English term.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search term (English word, transliteration, or concept) | |
| language | No | Limit search to one language. Omit to search both. | |
| limit | No | Maximum results to return. Default: 10 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is safe. The description adds behavioral context: it finds multiple words for a concept and allows explaining distinctions. No mention of side effects or API behavior, but the annotations cover safety.
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, with four sentences. It is front-loaded with 'USE THIS' and uses clear, direct language. 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?
Given the tool is simple (read-only, 3 params, no output schema), the description adequately covers purpose and usage. It does not describe return format, but that is often implicit. The sibling tools list provides context, and the description distinguishes its role.
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 is 3. The description adds value by providing examples like 'love → agape, phileo, eros,' which implies the query parameter accepts English concepts. This extra guidance helps the agent use the query parameter effectively.
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: 'find Greek/Hebrew words for English concepts.' It provides specific examples (love, faith, salvation) and distinguishes itself from sibling tools by focusing on lexical search. The verb 'search' combined with 'lexicon' is precise.
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...' and gives clear context: 'When a user asks about a biblical concept...' It also mentions an additional use case. However, it does not explicitly state when not to use it or list alternatives, but the sibling tools list provides context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
word_studyARead-onlyIdempotent
ALWAYS USE THIS when discussing any Greek or Hebrew word, theological term, or concept.
Even if you know the word from training, this tool provides verified lexical data.
IMPORTANT: When presenting word studies, ALWAYS SHOW:
The word in original script: ἀγάπη or אֱלֹהִים
Transliteration: agapē, elohim
Strong's number: G26, H430
Full definition and semantic range
Key passages showing usage
Format example in your response: ἀγάπη (agapē, G26) Definition: "Love, goodwill, benevolence; the love of God for humanity" Usage: Occurs 116 times in the NT Key passages: John 3:16, 1 Corinthians 13, 1 John 4:8
This makes responses scholarly and shows the depth available through original languages.
| Name | Required | Description | Default |
|---|---|---|---|
| strongs | No | Strong's number (e.g., 'G26' for agapē, 'H3068' for YHWH) | |
| word | No | English word to study (e.g., 'love', 'faith'). Will find the most relevant Greek/Hebrew term. | |
| language | No | Language to search if using 'word' parameter. Default: greek |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds that it 'provides verified lexical data', which aligns but does not significantly extend behavioral context. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the key purpose and includes bullet-point formatting instructions. While lengthy, each part adds value for an AI agent. A slightly more streamlined version would score 5.
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?
No output schema exists, but the description provides an example of how to present results. However, it does not explicitly describe the tool's return value or fields, leaving some ambiguity.
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 100%, so the baseline is 3. The description does not add extra meaning beyond the schema for parameters; it focuses on usage and output formatting.
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 explicitly states 'ALWAYS USE THIS when discussing any Greek or Hebrew word, theological term, or concept', clearly defining the tool's purpose as providing verified lexical data for word studies. This distinguishes it from siblings by positioning it as the primary word study tool.
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 gives strong usage guidance: 'ALWAYS USE THIS' and advises using even if the AI knows the word. However, it does not explicitly mention when not to use or suggest alternatives like search_by_strongs or search_lexicon.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
21 tool updates
v1.0.0- First observed
explore_genealogy - First observed
explore_person_events - First observed
explore_place - First observed
find_connection - First observed
find_similar_passages - First observed
get_ane_context - First observed
get_bible_dictionary - First observed
get_cross_references - First observed
get_key_terms - First observed
get_study_notes - First observed
get_textual_variant - First observed
get_theology_context - First observed
get_torah_weave - First observed
graph_enriched_search - First observed
lookup_name - First observed
lookup_verse - First observed
parse_morphology - First observed
people_in_passage - First observed
search_by_strongs - First observed
search_lexicon - First observed
word_study
TDQS
Scored across 21 tools
Each tool has a clearly distinct purpose, with detailed descriptions explaining when to use each one and how they differ from similar tools. The overlap between tools like lookup_name, explore_genealogy, and find_connection is explicitly addressed, making disambiguation straightforward.
Tool names follow a consistent snake_case pattern and use a mix of verbs (explore, find, get, lookup, search, parse) and descriptive phrases. While not completely uniform (e.g., people_in_passage vs. parse_morphology), the naming is logical and predictable within subgroups.
With 21 tools, the server covers a comprehensive range of Bible study tasks without being overwhelming. Each tool serves a distinct function, and the count is well-scoped for the domain's depth and breadth.
The tool set covers nearly every major aspect of Bible study: genealogies, events, places, cross-references, word studies, textual criticism, contextual background, and more. There are no obvious gaps, and the surface supports a thorough study workflow.
Maintenance
Related MCP Connectors
Bible research: 59 translations, Hebrew/Greek Strong's, morphology, cross-refs, 13 dictionaries
AI-powered biblical research tools — lexicons, morphology, manuscripts, and more.
Bible study: many editions, Strong's Hebrew and Greek, cross-references, Matthew Henry, the Fathers
AI Bible study you can actually check: Scripture, Hebrew and Greek, and the church fathers.
Related MCP Servers
- AlicenseNot gradedqualityAmaintenanceEnables comprehensive chess analysis through Stockfish engine integration, positional evaluation, puzzle training, game review, and access to extensive chess databases. Provides visual board rendering, interactive game viewers, and tactical puzzle training with 3+ million problems from Lichess.34AGPL 3.0
- AlicenseNot gradedqualityDmaintenanceTurns any source material into a guided learning experience with learning maps, notes, four-phase study loop, spaced repetition flashcards, and grounded Q\&A.2MIT
- AlicenseNot gradedqualityDmaintenanceEnables citation-audited deep research with tools for web-grounded answers, source conflict detection, and per-claim citation auditing.MIT
- AlicenseAqualityCmaintenanceEnables read-only search and analysis of your local Zotero library, including full-text PDF retrieval with OCR fallback, annotations, and cross-item comparison for synthesis.13MIT