Besorah — the Bible in Hebrew, Greek, Aramaic and English

Read a passage

get_passage

Read-onlyIdempotent

Returns a verse, range or chapter in its original language (Hebrew, Greek or Aramaic) with its English and a link; a range is capped at 80 verses. edition (septuagint, onkelos, pseudo-jonathan, jonathan, hebrew-nt, hebrew, greek) chooses the text. words=true adds, for each verse whose words line up with the Strong's tagging, every word's Strong's number, lemma, meaning and grammatical parsing. Use when the user asks to read or quote a verse, range or chapter.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "reference": "<reference>"
    },
    "name": "get_passage"
  }
}

Input Schema

Name	Required	Description
`words`	No	true adds each word's Strong's number, lemma, meaning and parsing
`format`	No	optional: json (default) or markdown (compact, readable)
`edition`	No	which text, e.g. septuagint, onkelos, pseudo-jonathan, jonathan, hebrew-nt, hebrew or greek
`max_chars`	No	optional: cap the answer at about this many characters (lists are shortened and marked truncated; use offset/nextOffset to get the rest)
`reference`	Yes	e.g. 'John 3:16', 'Psalm 23', 'Genesis 1:1-3', '1 Corinthians 13:4-7'

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 12, 2026

addedInput schema / properties / edition / description

Added value: +"which text, e.g. septuagint, onkelos, pseudo-jonathan, jonathan, hebrew-nt, hebrew or greek"

addedInput schema / properties / words / description

Added value: +"true adds each word's Strong's number, lemma, meaning and parsing"

First observedNov 11, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare a safe, idempotent read, so the description focuses on what they can't say: the 80-verse cap on ranges, that an English rendering and link are always included, and that Strong's word data is only supplied for verses whose words align with the tagging. One flaw: it references 'offset/nextOffset' for truncated output, but no such parameters exist in the schema.

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?

Purpose and reference scope are front-loaded and every sentence carries information. The middle is a dense run-on covering edition and words in one breath, which makes it slightly harder to scan than it needs to be.

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

Completeness4/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 does the work of describing the return payload (original-language text, English, link, optional word-level data). It is nearly complete, with the loose end being the undefined offset/nextOffset truncation mechanism.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description exceeds it by explaining that edition selects the underlying text tradition and by clarifying the conditional nature of words=true (only verses that line up with Strong's tagging). It adds meaning rather than restating the schema.

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 a specific verb and resource ('returns a verse, range or chapter in its original language ... with its English and a link') and names the exact scope limits (80-verse cap). An agent can distinguish it from siblings like get_context or get_word without inspecting 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?

'Use when the user asks to read or quote a verse, range or chapter' gives a clear triggering condition. It does not mention alternatives or exclusions (e.g. when to prefer get_context or get_verse_study instead), so it stops short of full routing guidance.

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

All Besorah — the Bible in Hebrew, Greek, Aramaic and English 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?