Skip to main content
Glama

get_textual_variant

Read-onlyIdempotent

Retrieve textual variant records for Bible verses where Hebrew, Greek, and Dead Sea Scrolls readings differ, with witnesses and scholarly consensus, to resolve NT-OT quotation mismatches.

Instructions

Retrieve the textual variant record for a verse where the Masoretic Hebrew, the Septuagint, and/or the Dead Sea Scrolls diverge.

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.

Relevant where a New Testament quotation does not match the modern English Old Testament, and to questions about how the Hebrew, Greek, and Qumran textual traditions differ at a specific verse.

Covered verses include 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, and the Old Testament verses they quote. Either side of a pair returns the same variant row.

lookup_verse reports when a verse has a quotation hint or variant row.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
referenceYesBible 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare readOnlyHint/idempotent/destructive, so the safety profile is covered. The description adds substantial context beyond that: the exact returned fields (MT reading, variant reading, witnesses, scholarly consensus, HLT preferred reading and rationale), the HLT interpretive principle, and that 'Either side of a pair returns the same variant row' — behavior an agent could not infer from annotations alone.

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

Conciseness4/5

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

Long but well-structured with a clear return-value list and front-loaded purpose. The covered-verses enumeration and HLT rationale are relevant, though the HLT discussion is somewhat expansive relative to invocation needs, keeping it short of ideal conciseness.

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?

With no output schema, the description carries the return-value burden and does so thoroughly, enumerating every returned field and even the interpretive principle behind the preferred reading. An agent has everything needed to call it correctly and interpret results.

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?

Schema coverage is 100% and the single 'reference' parameter is fully described there, including the OT/NT examples and the same-row note. The description restates this implicitly but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

Purpose5/5

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

States a specific verb ('Retrieve') and resource ('the textual variant record for a verse where the Masoretic Hebrew, the Septuagint, and/or the Dead Sea Scrolls diverge'). This scope is distinct from siblings like lookup_verse and get_cross_references, so an agent can disambiguate without opening schemas.

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?

Gives clear conditions for use: 'Relevant where a New Testament quotation does not match the modern English Old Testament' and for questions about how Hebrew/Greek/Qumran traditions differ at a verse. It also routes to a sibling by noting 'lookup_verse reports when a verse has a quotation hint or variant row,' though it never states an explicit when-not or names a direct alternative to choose instead.

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