The Study Bible MCP Server is a comprehensive biblical study assistant providing scholarly resources, original language analysis, graph-based knowledge, and hermeneutical guidance for in-depth biblical interpretation. It offers 20 tools across several domains:
Core Text & Language
Retrieve any Bible verse with original Greek/Hebrew text, word-by-word breakdowns, Strong's numbers, morphological parsing, and genre-specific interpretation guidance
Conduct word studies using full scholarly lexicons (LSJ Greek, Abbott-Smith NT Greek, BDB Hebrew) with etymology, semantic range, and usage counts
Search lexicons by English concept to find corresponding Greek/Hebrew words
Search by Strong's number to find every verse where a specific word appears
Parse morphology codes (e.g., V-AAI-3S) for full grammatical explanations
Compare textual variants between the Masoretic Text (MT) and LXX/DSS
Cross-References & Semantic Search
Find cross-references for any verse or theological theme from four scholarly datasets (Harrison/Romhild, Gage, Burnett, TSK) with tiered relevance ranking
Discover semantically similar passages via vector embeddings for thematic connections beyond explicit cross-references
Scholarly Commentary & Definitions
Access study notes combining Tyndale Study Notes, unfoldingWord, and SIL Translator Notes for any verse or chapter
Look up 500+ Tyndale Bible Dictionary articles on people, places, theology, and archaeology
Define 200+ key theological terms from the FIA Key Terms database
Biblical People, Places & Genealogy
Look up biblical names (people, places, things) with original language forms and relationships
Trace multi-generational family trees for 1,100+ biblical persons (with Mermaid diagram output)
Explore a person's life events chronologically with locations and dates
Get the complete biblical history of geographic locations
Find the shortest relationship path between any two biblical people
Identify all people, places, and events mentioned in a passage
Perform graph-enriched verse study combining text with all relational entity context
Cultural & Historical Context
Retrieve Ancient Near East (ANE) context across 13 dimensions (cosmology, covenant, social structure, warfare, daily life, etc.) and 9 time periods
Access theological scholarship from scholars like Michael Heiser (divine council, cosmic geography) and David Bradley (domain transfer, corporate headship)
Advanced Biblical Studies
Explore Torah Weave structural parallels using Moshe Kline's hypothesis for structurally-paired verses across Genesis–Deuteronomy
All tools are guided by Fee & Stuart's hermeneutical methodology with genre-specific principles for Epistles, Narratives, Gospels, Parables, Prophets, Psalms, Wisdom Literature, and Apocalyptic literature
Click on "Install 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 Server What 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.
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".
Open Settings → Connectors
Click Add Custom Connector
Paste: https://studybible-mcp.fly.dev/sse
Restart Claude Desktop
That's it. No signup, no API keys, no downloads.
claude mcp add study-bible https://studybible-mcp.fly.dev/sseOpen Settings → Developer Mode → enable it
Go to Actions → Add MCP Server
Enter URL: https://studybible-mcp.fly.dev/mcp
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/sse"]
}
}
}pip install studybible-mcp
studybible-mcp --transport stdioOr run directly without installing:
uvx studybible-mcp --transport stdioIf you prefer editing config files directly:
{
"mcpServers": {
"study-bible": {
"command": "npx",
"args": ["-y", "mcp-remote", "https://studybible-mcp.fly.dev/sse"]
}
}
}Config file locations:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
Related MCP server: mcp-bible
┌─────────────────────┐ ┌──────────────────────────────────────────┐
│ Claude Desktop │ │ Study Bible MCP Server │
│ or Claude Code │ │ (Fly.io) │
│ │ │ │
│ ┌───────────────┐ │ MCP │ ┌─────────────┐ ┌───────────────────┐ │
│ │ User asks a │──┼─────┼─▶│ MCP Server │─▶│ SQLite DB (359MB) │ │
│ │ Bible question│ │ │ │ (Python) │ │ │ │
│ └───────────────┘ │ │ └─────────────┘ │ • Lexicons (LSJ, │ │
│ │ │ │ │ BDB, Abbott- │ │
│ ┌───────────────┐ │ │ ▼ │ Smith, Strong's) │ │
│ │ Claude uses │◀─┼─────┼── Tool Results │ • Tagged NT + OT │ │
│ │ 18 tools to │ │ │ │ • Names + ACAI │ │
│ │ look up data │ │ │ │ • 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 all 18 tools and how the agent chains them together.
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 |
| 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 |
| 3,175 | 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 |
| 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 (~600MB)
lookup_verseRetrieve a verse with its original language text and word-by-word analysis.
When Claude uses it: User asks about a specific verse, wants to see the Greek or Hebrew text, or asks about specific words in a passage.
What it returns: English translation, original Greek/Hebrew text, word-by-word breakdown with Strong's numbers, morphological parsing, genre-specific interpretation guidance.
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?"word_studyDeep 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)search_lexiconSearch 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, wishget_cross_referencesFind 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 righteousnesslookup_nameGet 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 speechesparse_morphologyExplain 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: Singularsearch_by_strongsFind 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...get_study_notesGet 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]get_bible_dictionaryLook 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: Full dictionary article from a collection of 500+ topical articles covering biblical people, places, theological concepts, cultural practices, historical background, and archaeological findings.
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.get_key_termsLook 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.explore_genealogyTrace family relationships (ancestors or descendants) for a biblical person using genealogical data for 1,100+ persons.
What it returns: Family tree with generation numbers and relationship types, immediate family (spouse, siblings), Mermaid diagram.
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.explore_person_eventsFind all events a biblical person participated in, in chronological order.
What it returns: Timeline of a person's life events with locations and approximate dates, Mermaid timeline diagram.
explore_placeExplore the biblical history of a geographic location.
What it returns: Events at the location, people born or who died there, coordinates, Mermaid network diagram.
find_connectionFind the family relationship path between two biblical people.
What it returns: Shortest relationship path through parent, child, sibling, and partner relationships, Mermaid flowchart.
Example:
User: "How are Ruth and Jesus related?"
Claude calls: find_connection(person1="Ruth", person2="Jesus")
Returns: Ruth → child → Obed → child → Jesse → child → David → ... → Jesuspeople_in_passageFind 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.
get_ane_contextRetrieve 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 himselfgraph_enriched_searchCombine 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.
find_similar_passagesDiscover 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 statueUsers 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?" |
|
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.
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.This isn't just a reference tool. It's designed to guide users toward sound biblical interpretation.
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 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:
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
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
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
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
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
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
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
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
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 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
Want to run your own instance? See docs/SELF_HOST.md.
Options:
Local Python development
Docker deployment
Your own Fly.io instance
studybible-mcp/
├── src/study_bible_mcp/
│ ├── server.py # MCP server (stdio + SSE transports)
│ ├── database.py # SQLite queries (async)
│ ├── tools.py # 18 tool definitions
│ ├── hermeneutics.py # Genre detection & interpretation
│ └── 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
│ ├── tagged_text.py # TAGNT/TAHOT morphology parsers
│ └── proper_names.py # TIPNR name parser
├── scripts/
│ ├── download_stepbible.py # Download all source data (--aquifer flag)
│ ├── build_database.py # Build SQLite database
│ ├── generate_embeddings.py # Generate vector embeddings
│ ├── import_theographic.py # Import Theographic graph data
│ └── test_server.py # Manual test suite
├── tests/
│ └── test_tool_selection.py # Pytest: agent tool selection (71 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 all 18 tools
├── Dockerfile # Multi-stage build with database
├── fly.toml # Fly.io deployment config
└── pyproject.tomlBiblical 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 |
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.
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 |
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 |
Rich entity annotations from BibleAquifer/ACAI (CC BY-SA 4.0):
Type | Count | Content |
People | ~2,500 | Family relationships, variant names, roles, speech attributions, verse references |
Places | ~400 | Geographic entities with biblical references |
Groups | ~200 | People groups, nations, tribes |
Key Terms | ~75 | Annotated theological concepts |
Graph data for genealogy, events, and places from Theographic. Used by the explore_genealogy, explore_person_events, explore_place, find_connection, people_in_passage, and graph_enriched_search tools.
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.
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.
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.
Semantic search uses OpenAI's text-embedding-3-small model via sqlite-vec for the find_similar_passages tool.
Contributions welcome! Especially:
Additional thematic cross-references
Improved genre detection
New translation support
Better morphology parsing
Documentation improvements
MIT License. See LICENSE.
Data from STEPBible is licensed under CC BY 4.0. Data from BibleAquifer and ACAI is licensed under CC BY-SA 4.0. Torah Weave data 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.
STEPBible for the freely available biblical data
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
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 |
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.
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') |
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.
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') |
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.
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') |
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 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 |
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 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 |
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.
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') |
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.
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. |
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.
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') |
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 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) |
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.
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. |
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 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 |
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 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') |
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.
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') |
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.
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. |
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.
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 |
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.
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 |
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.
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') |
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.
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 |
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.
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 |
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.
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 |
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI-powered biblical research tools — lexicons, morphology, manuscripts, and more.
Scripture-cited answers to any Bible question, plus verse text and study pages, for AI agents.
Read Hebrew Bible (Tanakh) verses & chapters in 10 languages, plus guided study plans.
Read-only scripture-study engine: complete-or-fail concordance over Greek NT, Hebrew OT, LXX.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/djayatillake/studybible-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
