What can you do with this server?

This MCP server gives LLMs fast, structured access to the Open English Translation (OET) Bible — its dual Readers'/Literal versions, original-language word data, and translator decision annotations. * Read scripture (get_passage): any passage in parallel (RV+LV side-by-side), rv, lv, or token-level interlinear view, as markdown or JSON, with optional footnotes, raw USFM, and inline \add decision codes. * Compare versions (compare_translations): granular divergence breakdown between OET-RV and OET-LV — added copulas/articles/direct objects, untranslated particles, rewordings, number changes, poetic parallelism (≈/^/→), and clause inversions (⇔). * Full-text search (search_text): fast FTS5 keyword/phrase search across RV, LV, or both, filtered by testament. * Concordance / lemma search (search_lemma): trace how a Hebrew or Greek lemma or Strong's ID (e.g. logos, G3056, H7225) is glossed across the whole Bible, with frequency distributions. * Word-level lookup (lookup_word): drill into a single original-language token (e.g. JHNc1v1w5) for parsing, morphology, Strong's number, manuscript collation, and gloss. * Lexicon entries (get_lexicon_entry): dictionary definition, semantic range, and distribution stats for a lemma or Strong's ID, in Greek or Hebrew. * Translation decisions (get_translation_decisions): isolate all explicit translator \add annotations in a passage. * Browse resources/URIs: book catalog (66 canonical + 15 deuterocanonical, with chapter counts and translation status), RV/LV metadata and format specs, plus direct oet://passage/..., oet://word/..., and oet://lexicon/... URIs. * Use guided prompts: comparative_exegesis, biblical_word_study, and translation_critique for structured exegetical workflows.

Which integrations are available for this server?

Provides access to the Open English Translation (OET) Bible corpus stored in SQLite, enabling high-speed full-text search, word-level lexical lookups, interlinear views, and translation comparison tools.

Open English Translation of the Bible

Official

by Freely-Given-org

Overview Schema Source Related Servers Discussions Admin

Python

Local

Open English Translation (OET) MCP Server

An official Model Context Protocol (MCP) server providing Large Language Models (LLMs) with high-speed, structured access to the Open English Translation (OET) of the Bible.

The OET design specifications are at OET.Bible. The OET text is available on GitHub here.

What the server provides

The OET Readers’ Version (RV) and Literal Version (LV) are intended to be read together. This server supplies parallel passages, translator notes, source-word links, lemma usage statistics, and explicit translation annotations for LLM research.

Greek interlinears and counts exclude unused source variants by default; variants remain available with their original selection marker.
Hebrew and Aramaic words link to their actual lemma components, including prefixed forms.
Standard Strong’s identifiers are distinct from the extended identifiers in SR-GNT.
Decisions retain their source version and affected ESFM span. Their category is not a passage-specific explanation; translator notes and model inference remain distinct.
Paragraph/poetry structure, introductions, sections, source declarations, word alignments, and decoded morphology are available on demand.
Every tool is read-only and returns structured data plus readable text. Searches and passages have bounded pages and continuation offsets.

The lexical data describes OET-LV word-table usage, not dictionary definitions, etymology, manuscript witness evidence, or RV gloss frequencies. Hebrew whole-word glosses can contain several morphemes. Read get_oet_guide before interpreting unfamiliar conventions.

Related MCP server: Echo Prayer MCP Server

Quick Start

Running via `uvx`

uvx oet-mcp-server

Installation from Source

Note: the approximately 417 MiB corpus database is a Git-LFS file. Without git lfs pull you get only a ~130-byte LFS pointer, and every data tool fails at runtime.

git clone https://github.com/Freely-Given-org/open-english-translation-mcp-server.git
cd open-english-translation-mcp-server
git lfs install && git lfs pull   # materialize the real corpus database
uv sync
uv run oet-mcp-server

AI Client Configuration

1. Claude Desktop / Antigravity / Cursor

Add to your claude_desktop_config.json or MCP settings:

{
  "mcpServers": {
    "oet-bible": {
      "command": "uvx",
      "args": ["oet-mcp-server"]
    }
  }
}

Or for local development:

{
  "mcpServers": {
    "oet-bible": {
      "command": "uv",
      "args": [
        "--directory",
        "/srv/FreelyGiven/open-english-translation-mcp-server",
        "run",
        "oet-mcp-server"
      ]
    }
  }
}

MCP Server Capabilities

Tools

Tool	Purpose	Useful options
`get_oet_guide`	Interpretation conventions and evidence limits	No arguments
`get_passage`	Parallel, RV, LV, or interlinear passages	`include_notes`, `show_decision_codes`, `include_structure`, `include_alignment`, `include_raw`, `include_variants`, `limit`, `offset`
`get_book_context`	Introductions, source notes, version declarations and section outlines	`book`, `limit`, `offset`
`get_section`	Read a complete contextual section in bounded pages	`section_id`, `limit`, `offset`
`compare_translations`	Version-specific annotation comparison	`reference`, `limit`, `offset`
`get_translation_decisions`	Decision categories, source spans and supporting notes	`reference`, `limit`, `offset`
`search_text`	English keyword/phrase matches in the requested translation	`version`, `testament`, `book`, `limit`, `offset`
`search_lemma`	Selected source-word counts and representative occurrences	`testament`, `book`, `include_variants`, `sampling`, `limit`, `offset`
`lookup_word`	Selection status, lemma components, grammar and aligned English	`word_id`
`get_lexicon_entry`	Complete LV gloss distribution and selected/unused/unglossed counts	`query`, `lang` (`auto`, `greek`, `hebrew`, `aramaic`)

Examples:

get_passage(reference="John 1:1", version="interlinear", include_alignment=true)
get_passage(reference="Psalm 1:1-6", include_structure=true)
get_book_context(book="John")
get_section(section_id="JHN.RV.S1")
search_lemma(lemma_or_strongs="G3056", sampling="representative")
search_lemma(lemma_or_strongs="H7225", book="Genesis", sampling="canonical")
lookup_word(word_id="GEN_1:1w1")

get_passage defaults to 20 verse records, with at most 10 in interlinear mode. Other limits are described in each tool schema; all are capped at 100. Repeat the same request with the returned next_offset to continue. Grouped source verses such as 1–3 retain their labels and can be retrieved by requesting a verse inside the group. RV and LV may use different groupings; unavailable matching segments are identified explicitly.

Text search treats unquoted words as AND terms and double-quoted text as an exact phrase. Punctuation is accepted; FTS operators are not exposed. Version filters constrain the search itself. Results include a filtered total, not just the page size.

Lemma lookup accepts original-script or source-transliterated lemmas, accent variants, standard Strong’s IDs (G3056, H7225), and returned lemma keys. Extended Greek IDs remain accepted when unambiguous. Disambiguate explicitly with strongs:G260 versus strongs_ext:G260. Do not infer a root from an English gloss. Ambiguous lemma lookup returns candidate keys; concordance search can combine matching lemma entries without double-counting source words. Representative sampling rotates across books; canonical sampling supports consecutive traversal. Full-corpus statistics are labelled separately from filtered samples.

Word IDs include JHN_1:1w5, JHNc1v1w5, and namespaced source-table rows (NT:62342, OT:1). Alignment spans and decision spans are half-open character offsets in the returned verse ESFM, not in the cleaned English text. Source-table IDs are revision-specific. Links are imported from the source; missing links are not guessed. Greek word order follows source-table positions. Decoded grammar names its scheme and preserves unknown codes rather than guessing their meaning.

format="markdown" is the default passage reading view. format="json" changes its text representation; both formats always return typed MCP structuredContent with an output schema. Raw ESFM, structure and alignments are opt-in. Null and default optional values are omitted. Public passage URLs may show a newer edition than the local corpus; cite its revision and hashes.

Resources and prompts

Resources: oet://guide, oet://catalog, oet://metadata/rv, oet://metadata/lv, oet://formats, oet://passage/{version}/{reference}, oet://word/{word_id}, and oet://lexicon/{lang}/{query}. Resource passage reads use a bounded default page; use the tools to continue or request detailed views.

The comparative_exegesis, biblical_word_study, and translation_critique prompts start from context and source evidence. They distinguish translator notes from model interpretation and do not request unsupported dictionary or manuscript claims.

Corpus updates and compatibility

Version 0.2 requires MCP SDK 2.1.1 or newer within major version 2 and corpus schema 2. Older corpus files are rejected with a rebuild message. The database is approximately 417 MiB and remains a Git-LFS artifact. Build from the local OET checkout with:

uv run python scripts/build_db.py
uv run python scripts/verify_db.py
uv run pytest -q

The builder writes a temporary database and replaces the destination only after a successful build and integrity check. --output /path/to/corpus.db builds to a different destination. Provenance records the OET repository revision, whether source files differ from that revision, source-file and word-table hashes, build timestamp, attribution and text licence. Per-book declarations retain source edition and adaptation notes, including WEBBE material.

Regression scenarios cover unused variants in John 1:1, logos counts, prefixed Hebrew stems, invalid ranges, version/language filters, decision attribution, recovered notes, poetry boundaries, word alignment, grouped verses, pagination, morphology and the MCP output contract.

OET Translation Decision Codes Reference

Code	Category	Meaning	Example
`@`	Referent Replacement	Pronoun changed to explicit name	`\add @David\add*`
`≈`	Rewording	Rephrased for modern clarity	`\add ≈answered\add*`
`#`	Number Change	Singular generalized to plural	`\add #people\add*`
`%`	Person Shift	Direct speech flattened to indirect	`\add %that he will\add*`
`^`	Opposite Phrasing	Saying phrased positively	`\add ^always open\add*`
`+`	Added Article	Article added for English grammar	`\add +the\add*`
`=`	Added Copula	Helping verb ('is', 'was') added	`\add =is\add*`
`<`	Added Direct Object	Object added for transitive verb	`\add <it\add*`
`>`	Added Implied Object	Implied entity ('thing', 'person')	`\add >things\add*`
`≡`	Elided Repetition	Repeated elided word for clarity	`\add ≡pursued\add*`
`&`	Added Owner	Possessive added for naturalness	`\add &his\add*`
`?`	Uncertainty Marker	Translator doubt regarding intent	`\add ?in the clouds\add*`
`!`	Alternate Name	Familiar/traditional name added in parentheses after an OET distinctive name	`\add !(Moses)\add*`
`≈` (line)	Synonymous Parallelism	Second poetic line reiterates first	`\q1 ≈Yahweh gives comfort`
`^` (line)	Antithetic Parallelism	Second poetic line states contrast	`\q1 ^but Israel will fall`
`→` (line)	Synthetic Parallelism	Second poetic line reaches result	`\q1 →and he answered`
`⇔` (verse)	Order Swapped	Clauses inverted for English flow	`\v 10 ⇔The girls did...`

Deployment (Docker)

Important: the approximately 417 MiB corpus database is stored as a Git-LFS file. A checkout without git lfs pull contains only a ~130-byte LFS pointer, which makes every data tool fail at runtime. The Dockerfile guards against this: scripts/verify_db.py runs at build time and fails the build if the DB isn't a real, queryable SQLite database.

Recommended: use the CI-built image

The .github/workflows/docker-publish.yml workflow materializes the LFS data, builds the image, and pushes it to ghcr.io/freely-given-org/open-english-translation-mcp-server as :latest and :main (on pushes to main) and :v* (on version tags). Deploying servers then pull instead of building:

Before this works, the workflow must have published at least one image (push to main, create a v* tag, or trigger it from the GitHub Actions tab). Until then docker compose pull fails, so use the local-build path below.

git clone --filter=blob:none https://github.com/Freely-Given-org/open-english-translation-mcp-server.git
cd open-english-translation-mcp-server
docker compose pull          # pulls the GHCR image
docker compose up -d         # no local build, no LFS data needed on the server

OET_MCP_IMAGE overrides the image used by docker-compose.yml.

Building locally

git lfs install && git lfs pull   # materialize the real corpus DB
docker compose up -d --build

The container exposes a Docker healthcheck (scripts/healthcheck.py) that validates the DB and that the MCP proxy is accepting connections, so docker inspect / orchestrators report the deploy as unhealthy if the DB is invalid.

License

Code: Open Source under CC0 1.0 Universal (see the LICENSE file).
OET Text & Datasets: Creative Commons Attribution-ShareAlike (CC-BY-SA 4.0) by Freely-Given.org.

Available Tools

7 tools

compare_translationsA

Isolates and computes detailed translation divergencies between OET-RV and OET-LV for a passage.

Identifies:

Added words in LV (copulas, articles, direct objects).
Untranslated original language particles (Greek articles before proper names, Hebrew DOM).
Explicit RV translation decisions (referents substituted for pronouns, rewordings, number changes).
Poetic parallelism (≈) and clause inversions (⇔).

Args: reference: Scripture reference (e.g. 'John 1:1-3', 'Romans 1:16-17').

Name	Required	Description	Default
`reference`	Yes

Output Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior4/5

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

The description lists concrete outputs: added words, untranslated particles, explicit translation decisions, poetic parallelism, and clause inversions. This gives an agent a clear expectation of the tool's behavior and result format. No side effects are mentioned, but the tool appears to be read-only, consistent with the absence of annotations.

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?

The description is moderately detailed but well-organized with a bulleted list of identification categories. It is not overly verbose and communicates the core purpose and expected output efficiently. The structure makes the information easy to parse.

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?

Given the presence of an output schema (not shown but indicated), the description provides sufficient context about the tool's function and output. It does not explicitly explain its relationship to sibling tools, but the listing of sibling tools helps an agent infer when to use this one. No critical information appears to be missing for a typical use case.

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 only parameter, 'reference', has no schema description (0% coverage), but the tool description provides examples like 'John 1:1-3' and 'Romans 1:16-17', which clarifies the expected format. This adds enough meaning to compensate for the bare schema, though it is a common parameter type that an agent might infer.

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 clearly states the tool's function: computing detailed translation divergencies between OET-RV and OET-LV for a passage. The verb 'isolates and computes' is specific, and the resource (translation versions) is named. It distinguishes itself from siblings like get_passage and get_translation_decisions by focusing on comparison rather than retrieval or decision lookup.

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

Usage Guidelines3/5

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

The description implies when to use the tool (when detailed divergencies are needed) but does not explicitly contrast it with alternatives like get_translation_decisions, which might also be relevant. No clear 'when not to use' guidance is provided, leaving some ambiguity for an agent deciding between closely related tools.

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

get_lexicon_entryC

Retrieve full lexicon definition, semantic range, and distribution statistics for a lemma or Strong's ID.

Args: query: Greek/Hebrew lemma or Strong's ID (e.g. 'G3056', 'logos', 'H7225', 'shalom'). lang: Language filter ('auto', 'greek', 'hebrew').

Name	Required	Description	Default
`lang`	No		auto
`query`	Yes

Output Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries full responsibility for disclosing behavior. It states that the tool retrieves information, implying a read-only operation, but does not explicitly mention any side effects, permissions, or lack thereof.

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 a single, concise sentence with no unnecessary words. It is well-structured and immediately conveys the tool's core function.

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

Completeness3/5

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

The description covers the basic purpose and some parameter semantics, but lacks usage context (e.g., when to prefer this over siblings) and does not describe the return format. Since an output schema is present, the return format omission is acceptable, but the missing usage guidance leaves the description incomplete for effective tool selection.

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 description partially explains the 'query' parameter by indicating it accepts a lemma or Strong's ID. The 'lang' parameter is only presented with an enum and default, leaving its purpose inferable but not explicit. This adds some value beyond the raw schema, which has no descriptions.

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

Purpose4/5

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

The description clearly states the action ('Retrieve') and the resource ('lexicon definition, semantic range, and distribution statistics'). It is specific and unambiguous, though it does not explicitly differentiate from sibling tools like 'lookup_word' or 'search_lemma'.

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

Usage Guidelines1/5

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

No guidance is provided on when to use this tool versus the sibling tools. The description does not mention any conditions or contexts that would make this tool the preferred choice.

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

get_passageA

Retrieve Scripture from the Open English Translation (OET).

Supports:

'parallel': Side-by-side comparison of Readers' Version (OET-RV) and Literal Version (OET-LV).
'rv': Easy-to-read Readers' Version.
'lv': Hyper-literal, grammatically transparent Literal Version.
'interlinear': Token-level table with original Greek/Hebrew, transliterated lemmas, Strong's numbers, morphology, and glosses.

Args: reference: Standard reference (e.g. 'John 1:1-5', 'Rom 8:28', 'Gen 1:1-3', 'JHN.1.1'). version: Translation view ('parallel', 'rv', 'lv', 'interlinear'). include_notes: Whether to attach translator footnotes and cross-references. format: Output format ('markdown' or 'json'). show_decision_codes: If true, reveals inline decision codes (e.g. [@referent], [≈rewording], [+the]).

Name	Required	Default
`format`	No	markdown
`version`	No	parallel
`reference`	Yes
`include_notes`	No
`show_decision_codes`	No

Output Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

The description discloses what the tool does (retrieves passages, supports certain versions, can reveal decision codes) but does not mention side effects, rate limits, or the read-only nature of the operation. Since no annotations are provided, the description bears the full burden of transparency.

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 concise and well-organized. It opens with a one-line purpose, lists versions in a bullet-like format, and then enumerates arguments with examples. No redundant or irrelevant information is present.

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?

The description covers the tool's inputs and behavior but does not explicitly describe the return structure or any error cases. Given the tool's simplicity and the specified output format, this is largely sufficient, though a brief note on return content would make it fully complete.

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

Parameters5/5

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

All five parameters are clearly explained. Reference includes examples, version lists all enum options, include_notes and show_decision_codes have explicit meanings, and format specifies the available output types. This adds substantial meaning beyond the bare schema.

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

Purpose4/5

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 retrieve Scripture from the Open English Translation. It lists the supported versions, but does not explicitly distinguish itself from sibling tools like compare_translations or search_text, though the function is nonetheless clear.

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

Usage Guidelines2/5

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

The description does not provide guidance on when to use this tool versus alternatives. While it explains the parameters and versions, it does not mention cases where another tool might be more appropriate, leaving usage decisions to the agent.

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

get_translation_decisionsA

Extract all explicit translator decision annotations (\add tags, referents, rewordings) in a passage.

Args: reference: Scripture reference (e.g. 'John 1:1-18', 'Romans 1:1-7').

Name	Required	Description	Default
`reference`	Yes

Output Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior3/5

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

No annotations are provided, and the description does not explicitly state that the operation is read-only or whether it has any side effects. However, the nature of 'extract' implies no mutation, but this is not made explicit.

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 concise and well-structured, stating the purpose in one sentence and providing parameter guidance in a clear list. No unnecessary information.

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?

The description is complete for a tool with a single parameter; it covers what is extracted and how to specify the reference. It does not detail output format, but that is not essential for the given scope.

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

Parameters5/5

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

The single parameter 'reference' is fully described with concrete examples (e.g., 'John 1:1-18'), matching the schema's string type. This is clear and actionable.

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 clearly states the action (extract) and the resource (translator decision annotations in a passage). It also lists specific annotation types, distinguishing it from sibling tools like get_passage or search_text.

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 implies usage when translator decision annotations are needed, but does not explicitly contrast with sibling tools or state when not to use. However, for such a straightforward retrieval tool, the implied usage is sufficient.

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

lookup_wordA

Drill down into a specific original word link token (e.g. 'JHNc1v1w5' or 'JHN_1:1w5'). Returns complete grammatical parsing, SR-GNT / UHB collation, Strong's number, and gloss.

Args: word_id: Token ID (e.g. 'JHNc1v1w5', 'MAT_1:1w1', 'GEN_1:1w1').

Name	Required	Description	Default
`word_id`	Yes

Output Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses what the tool returns (grammatical parsing, collation, Strong's number, gloss), which is sufficient for a read-only lookup. It does not mention potential errors or side effects, but none are expected for this simple operation.

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 concise, with two sentences that front-load the purpose and then list the expected output. Every word adds value, and it is easy to scan.

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?

For a simple lookup tool, the description covers the essential context: what it does, what input it expects, and what it returns. There is no output schema, but the description explicitly lists the returns, making it complete for an agent to decide when to use it.

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

Parameters5/5

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

The schema only provides the parameter name, type, and title. The description enriches it by explaining that word_id is a specific original word link token and giving concrete format examples (e.g., 'JHNc1v1w5'). This fully clarifies the parameter meaning.

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 clearly states the tool's purpose: to drill down into a specific original word link token and return detailed information. The verb 'drill down' and the focus on a specific token distinguish it from sibling tools like search_text or search_lemma.

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

Usage Guidelines3/5

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

The description implies usage when you have a specific token ID (with examples), but it does not explicitly contrast with alternatives or mention when not to use it. The examples help, but there is no direct guidance on choosing between this and sibling tools.

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

search_lemmaA

Find all biblical occurrences of an original Hebrew/Greek root or Strong's number. Returns the exact gloss frequency distribution across both OET-RV and OET-LV.

Args: lemma_or_strongs: Lemma (e.g. 'logos', 'agape', 'bereshit') or Strong's ID ('G3056', 'H7225'). testament: 'all', 'OT', or 'NT'. limit: Max occurrences to return (default: 30).

Name	Required	Default
`limit`	No
`testament`	No	all
`lemma_or_strongs`	Yes

Output Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It states that the tool returns a frequency distribution, but does not mention whether it is read-only, any side effects, limitations, or edge cases (e.g., how occurrences are counted or whether the limit applies to lemmas or glosses). The behavior is generally clear but lacks completeness.

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 concise, using two sentences plus the parameter list. It is well-structured and avoids unnecessary detail, making it easy to parse quickly.

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?

The description provides enough context to understand the tool's core function and output (gloss frequency distribution across OET-RV and OET-LV). However, it does not explain what OET-RV/OET-LV are, the exact format of the output, or any prerequisites, which might be needed for full comprehension in an unfamiliar context.

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?

Although the schema has no individual parameter descriptions, the tool description includes an Args section that explains each parameter: lemma_or_strongs with examples, testament with allowed values, and limit with a default. The explanation is helpful but the 'limit' parameter could be ambiguous given the output is a frequency distribution rather than a list of occurrences.

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

Purpose4/5

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

The description clearly states the tool's purpose: finding biblical occurrences via lemma or Strong's number and returning gloss frequency distribution. It is specific but does not explicitly differentiate itself from sibling tools like lookup_word or search_text, though the focus on original language roots and Strong's numbers is distinctive.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It only explains the arguments and return behavior, leaving the agent to infer usage context from the tool name and sibling tool list.

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

search_textA

High-speed full-text search across the Open English Translation using SQLite FTS5.

Args: query: Search keywords or exact phrase (e.g. 'true light', 'messenger God', 'covenant'). version: Search in 'rv', 'lv', or 'both'. testament: Filter by 'all', 'OT', or 'NT'. limit: Maximum number of verse matches (default: 20).

Name	Required	Default
`limit`	No
`query`	Yes
`version`	No	both
`testament`	No	all

Output Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior2/5

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

No annotations are provided, and the description does not mention side effects, permissions, or read-only nature. Although a search tool is likely read-only, this is not explicitly stated, leaving behavior partly undisclosed.

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 concise and directly to the point, with no redundant or irrelevant information. It efficiently communicates the tool's purpose and parameters.

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?

Given the presence of an output schema in the context, the description does not need to explain return values. It provides adequate information to invoke the tool correctly, though it lacks details on edge cases or query formatting nuances.

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?

The description covers all four parameters in the Args section, including the parameter names, expected values, and examples for query. It also clarifies default values. However, it does not elaborate on query syntax constraints beyond basic examples.

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 clearly states this is a full-text search tool for the Open English Translation, using SQLite FTS5. It is distinct from sibling tools like search_lemma and lookup_word by focusing on full-text search across the translation.

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

Usage Guidelines3/5

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

The description implies usage for searching English text but does not explicitly instruct when to choose this over alternatives like search_lemma or lookup_word. No direct guidance is given 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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

7 tool updatesv0.1.1Sep 7, 2026
- First observedcompare_translations
- First observedget_lexicon_entry
- First observedget_passage
- First observedget_translation_decisions
- First observedlookup_word
- First observedsearch_lemma
- First observedsearch_text

Deploy Server

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

TDQS

A3.9/5.0

Scored 2026-09-07 03:15 across 7 tools

Disambiguation5/5

Each tool has a distinct purpose: passage retrieval, lexicon lookup, word-level token lookup, translation comparison, annotation extraction, lemma search, and full-text search. Even the seemingly related compare_translations and get_translation_decisions are clearly differentiated by scope and output.

Naming Consistency5/5

All tool names follow a consistent action_object pattern (compare_, get_, lookup_, search_, etc.), making the API predictable and intuitive. The verbs vary but are semantically appropriate for each operation.

Tool Count5/5

Seven tools is well-scoped for a Bible study and translation-analysis server. Each tool covers a necessary facet without redundancy or bloat, and the count feels natural for the domain.

Completeness5/5

The toolset covers the full workflow: retrieving passages, comparing translations, extracting decisions, looking up lexemes, drilling into word tokens, searching lemmas, and full-text searching. No significant gap is apparent for the stated purpose.

Maintenance

ActivityActive

ResponsivenessNo recent community issues

Resources

Related MCP Connectors

Shepherd Bible APIA
com.simplecohortllc.bible
Bible translations, books, chapters, verses, and search
Search Art & Culture
52
https://bible.simplecohortllc.com/mcp
Cross + Covenant BibleA
co.crossandcovenant
Public-domain Bible text (WEB and KJV), reading plans and a daily devotional. Read-only.
Education & Learning Tools Open Data
51
https://crossandcovenant.co/api/mcp/bible
Audio Bible
pro.publifye
The World English Bible read aloud for AI: verse text, listening links, recordings and downloads
Audio Processing Art & Culture
1
https://audiobible.publifye.com/mcp
TrulyRandomVerseA
com.trulyrandomverse
Bible study: many editions, Strong's Hebrew and Greek, cross-references, Matthew Henry, the Fathers
Education & Learning Tools Research & Data Search
161
https://mcp.trulyrandomverse.com

Related MCP Servers

Bible MCP
Education & Learning Tools Open Data
midvash
A
license
A
quality
A
maintenance
Free, no-key MCP server for reading scripture from 35+ public-domain translations in 8 languages. Lets users fetch verses, chapters, and passages via natural language from any MCP client.
Updated 9 days ago (2026-10-28 15:00 UTC)
7
126 npm
1
MIT
Echo Prayer MCP Server
Search
faith-tools
A
license
Not graded
quality
D
maintenance
Provides guided prayers, semantic search, and pastoral care tools (encouragement, condolence, advice) via a read-only database without authentication.
Updated a year ago (2025-10-09 23:30 UTC)
MIT
bible-translation-mcp
Education & Learning Tools Research & Data
jeremymikkelsen
A
license
Not graded
quality
D
maintenance
Enables AI to access Bible translations in hundreds of languages, original Greek and Hebrew texts with morphology, word-level interlinear alignments, and lexicons.
Updated 8 months ago (2026-03-08 22:11 UTC)
CC BY-SA 4.0
soapbox-faith
Education & Learning Tools Search
alansafahi
A
license
Not graded
quality
B
maintenance
Faith tools for AI agents: cited public-domain (KJV) Scripture verification, ORA Bible Q&A, sermon search, a church directory, and consent-gated prayer requests and giving. Free read tools need no key.
Updated 14 days ago (2026-10-24 01:27 UTC)
MIT

Open English Translation (OET) MCP Server

What the server provides

Quick Start

Running via uvx

Installation from Source

AI Client Configuration

1. Claude Desktop / Antigravity / Cursor

MCP Server Capabilities

Tools

Resources and prompts

Corpus updates and compatibility

OET Translation Decision Codes Reference

Deployment (Docker)

Recommended: use the CI-built image

Building locally

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Running via `uvx`