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

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedAug 23, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": {},
+  "properties": {
+    "licence": {
+      "additionalProperties": {},
+      "properties": {
+        "document": {
+          "type": "string"
+        },
+        "note": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "reference": {
+      "type": "string"
+    },
+    "translation": {
+      "type": "string"
+    },
+    "verses": {
+      "items": {
+        "additionalProperties": {},
+        "properties": {
+          "osis": {
+            "type": "string"
+          },
+          "reference": {
+            "type": "string"
+          },
+          "words": {
+            "items": {
+              "additionalProperties": {},
+              "properties": {
+                "english": {
+                  "type": "string"
+                },
+                "from": {
+                  "type": "number"
+                },
+                "language": {
+                  "type": "string"
+                },
+                "lexeme": {
+                  "type": "string"
+                },
+                "parsing": {
+                  "type": "string"
+                },
+                "strongs": {
+                  "type": "string"
+                },
+                "to": {
+                  "type": "number"
+                },
+                "transliteration": {
+                  "type": "string"
+                },
+                "word": {
+                  "type": "string"
+                }
+              },
+              "required": [
+                "from",
+                "to",
+                "language",
+                "word",
+                "transliteration",
+                "parsing",
+                "strongs",
+                "english"
+              ],
+              "type": "object"
+            },
+            "type": "array"
+          }
+        },
+        "required": [
+          "osis",
+          "reference",
+          "words"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "reference",
+    "translation",
+    "verses"
+  ],
+  "type": "object"
+}

First observedAug 23, 2026

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

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?