VineVerse — Bible Knowledge Graph

Get the original-language words behind a passage

get_interlinear

Read-onlyIdempotent

The Hebrew, Aramaic or Greek behind the English, word by word, for one verse or a whole chapter. This is a REVERSE interlinear: entries are in English order and each carries the range of English words it produced, so a word in the translation can be traced to the word it renders. Each entry gives the original, its transliteration, its morphology spelled out, and its Strong’s number; lexeme is present only where the bundle carries a document for that number — the lexicon holds the words that spell a biblical name plus their roots, not all 8,674 Strong’s entries, and there is no Greek lexicon at all. Five verses carry no data because the two Berean editions disagree about their wording; they are named in the changelog.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`osis`	Yes	OSIS reference — a verse ("John.3.16") or a whole chapter ("John.3")

Output Schema

TableJSON Schema

Name	Required	Description	Default
`verses`	Yes
`licence`	No
`reference`	Yes
`translation`	Yes

TDQS

A4.5/5.0

Behavior5/5

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

The description goes beyond the annotations by disclosing meaningful behavior: entries are in English order, lexeme presence is conditional, the Greek lexicon is absent, and some verses are skipped due to Berean edition disagreement. This is exactly the kind of behavioral context an AI agent needs.

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

Conciseness5/5

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

The description is dense but front-loaded and every clause earns its place: the main purpose, the reverse-interlinear ordering, entry fields, and data availability limitations. It is long because the domain is complex, not because it repeats information already in quick access.

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

Completeness5/5

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

Given the output schema, annotations, and the one documented parameter, the description covers all important edge cases and expectations: what each entry contains, when lexeme is omitted, the lexicon scope, and the five verses with no data. It points to the changelog for those verse names, which is the right mechanism.

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

Parameters3/5

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

The schema already fully documents the single required parameter, osis, with explicit verse/chapter examples. The description restates 'one verse or whole chapter' but does not add materially new parameter guidance, so it meets the baseline for high schema coverage.

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

Purpose5/5

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

The description states exactly what the tool does: it returns the Hebrew/Aramaic/Greek original-language words behind an English passage, word by word, as a REVERSE interlinear. This distinguishes it clearly from sibling text access tools like get_passage.

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

Usage Guidelines4/5

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

The description gives clear context for when to call the tool — for a single verse or whole chapter when the original-language form and grammatical details are wanted. It does not explicitly name alternatives or exclusions, but the intended use case is evident.

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

All VineVerse — Bible Knowledge Graph tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation4/5

Each tool targets a distinct retrieval task, and the only near-overlaps—get_connections vs find_cross_references, get_stats vs get_status, get_entity vs get_family—are clearly separated by the descriptions. An agent could occasionally hesitate between get_entity and get_family for genealogy, but the purpose statements make the boundary clear.

Naming Consistency4/5

All tool names use clear snake_case verb_noun phrasing, and most are get_* operations. There is a minor stylistic split between get_*, find_*, search_*, and list_*, which gives the set a slightly less uniform feel but is still predictable and readable enough for an agent.

Tool Count4/5

At 16 tools, this is slightly above the typical 3-15 range, but every tool covers a genuinely separate capability: passage lookup, concept search, graph queries, genealogy, interlinear, statistics, and service health. The count is large but reasonable for the breadth of a Bible knowledge graph.

Completeness5/5

For read-only knowledge-graph, the surface is well covered: known-lookup, text and concept search, browsing by collection, cross-references, graph neighborhoods, genealogy, places, interlinear, vocabulary, tags, and every diagnostics. get_stats and get_vocabulary together give an agent a reliable map of the whole domain, so there are no obvious dead ends.

Resources

Need Help?