Open English Translation of the Bible

Name: Open English Translation of the Bible
Author: Freely-Given-org

Official

by Freely-Given-org

Overview Schema Related Servers Score Discussions

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.

What Makes the OET Different?

Dual-Stream Parallel Translation:
- Readers' Version (OET-RV): Natural, idiomatic, thought-for-thought modern English designed for macro-level discourse comprehension and fluency.
- Literal Version (OET-LV): Transparent, hyper-literal formal equivalence showing every added copula, article, transitive direct object, and untranslated particle.
Word-Level Lexical Graph & Interlinear:
- Every word token is cross-linked via TSV datasets to Hebrew/Aramaic (UHB) and Greek (SR-GNT) dictionary entries, lemmas, Strong's numbers, morphological tags, and canonical gloss distributions.
Explicit Translation Decision Tags (\add):
- Encodes the exact reason for every addition or divergence (@ for referent replacements, ≈ for rewordings, # for number changes, % for speech shifts, ^ for opposite phrasing, ? for uncertainty, ≈/^/→ for Hebrew poetic parallelism, and ⇔ for clause re-ordering).

Related MCP server: Echo Prayer MCP Server

Quick Start

Running via `uvx`

uvx oet-mcp-server

Installation from Source

git clone https://github.com/Freely-Given-org/open-english-translation-mcp-server.git
cd open-english-translation-mcp-server
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

1. Resources & Resource Templates

URI Pattern	Description
`oet://catalog`	Lists all 66+ biblical books, chapter counts, testaments, and translation status.
`oet://metadata/rv`	Translation philosophy and `\add` decision encoding guide for OET-RV.
`oet://metadata/lv`	Markup guide for OET-LV (added copulas, untranslated particles, direct objects).
`oet://formats`	Complete specification of OET encoding formats and special character codes.
`oet://passage/{version}/{reference}`	Direct reading URI for any passage (`parallel`, `rv`, `lv`, `interlinear`).
`oet://word/{word_id}`	Lookup a specific word link token (e.g. `JHNc1v1w5`, `MAT_1:1w1`).
`oet://lexicon/{lang}/{query}`	Dictionary definition and canonical gloss distribution for a lemma or Strong's ID.

2. Tools

`get_passage`

Retrieve scripture in parallel side-by-side, readers, literal, or interlinear table view.

Arguments:
- reference (string, required): e.g. "John 1:1-5", "Rom 8:28", "Gen 1:1".
- version (string): "parallel", "rv", "lv", or "interlinear".
- include_notes (bool): Attach translator footnotes (TD:, TC:) and cross-references.
- format (string): "markdown" or "json".
- show_decision_codes (bool): Reveal inline decision tags ([@referent], [≈rewording]).

`compare_translations`

Calculates a granular comparative breakdown between OET-RV and OET-LV for a passage.

Arguments:
- reference (string, required): e.g. "John 1:1-3", "Romans 1:16-17".

`search_text`

High-speed full-text search across RV and LV using SQLite FTS5.

Arguments:
- query (string, required): e.g. "true light", "covenant".
- version (string): "both", "rv", or "lv".
- testament (string): "all", "OT", or "NT".
- limit (int): Max results (default 20).

`search_lemma`

Concordance lookup showing how an original Hebrew/Greek root or Strong's ID is translated across the entire Bible.

Arguments:
- lemma_or_strongs (string, required): e.g. "logos", "G3056", "bereshit", "H7225".
- testament (string): "all", "OT", "NT".
- limit (int): Max sample occurrences.

`lookup_word`

Drill down into a specific original word link token with complete grammatical parsing and manuscript collations.

Arguments:
- word_id (string, required): e.g. "JHNc1v1w5", "MAT_1:1w1".

`get_lexicon_entry`

Retrieve dictionary definition, semantic domain, and canonical distribution for a lemma or Strong's ID.

Arguments:
- query (string, required): Lemma or Strong's ID.
- lang (string): "auto", "greek", "hebrew".

`get_translation_decisions`

Isolates all explicit \add decision codes in a passage.

Arguments:
- reference (string, required): e.g. "John 1:1-18".

3. MCP Prompts

comparative_exegesis: Guided prompt leading an AI through rigorous exegesis (macro discourse in RV, micro syntax in LV, and root word studies).
biblical_word_study: Guided prompt performing a complete biblical word study across genres and testaments.
translation_critique: Guided prompt analyzing why modern dynamic translations diverge from literal syntax in difficult verses.

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*`
`≈` (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...`

License

Code: Open Source under the MIT / GPL-3.0 License.
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').

ParametersJSON Schema

Name	Required	Description	Default
`reference`	Yes

Output Schema

ParametersJSON 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').

ParametersJSON Schema

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

Output Schema

ParametersJSON 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]).

ParametersJSON Schema

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

Output Schema

ParametersJSON 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').

ParametersJSON Schema

Name	Required	Description	Default
`reference`	Yes

Output Schema

ParametersJSON 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').

ParametersJSON Schema

Name	Required	Description	Default
`word_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

No annotations are present, but the description discloses what the tool returns (parsing, collation, Strong's number, gloss), which is transparent about its behavior. It does not mention error handling or side effects, but for a read-only lookup this is adequate.

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 extremely concise—two sentences—and front-loads the action and the key output information. There is no fluff or redundancy.

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 enough for a simple lookup tool: it explains the input format and the output categories. Given the sibling tools and lack of an explicit output schema, the description provides sufficient context to use the tool correctly.

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 schema only specifies type 'string', but the description enriches the parameter by showing valid token examples (e.g., 'JHNc1v1w5' or 'JHN_1:1w5'), clarifying the expected format. This goes beyond the schema's minimal information.

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 with a specific verb ('drill down into') and resource ('specific original word link token'), and lists the output categories. It distinguishes itself from siblings like get_passage or search_text by focusing on a single token 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 usage when a word token ID is available, and gives example token formats. However, it does not explicitly state when to prefer this over sibling tools or when not to use it, leaving some inference required.

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).

ParametersJSON Schema

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

Output Schema

ParametersJSON 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).

ParametersJSON Schema

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

Output Schema

ParametersJSON 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. Dates show when Glama detected each change.

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

Install Server

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

TDQS

A3.9/5.0

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

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Shepherd Bible API A
com.simplecohortllc.bible
Bible translations, books, chapters, verses, and search
Search Art & Culture
52
bible-mcp A
io.github.nirajagarwal
Bible corpus MCP server: scripture, Greek/Hebrew interlinear data, cross-refs, semantic search.
Search Knowledge & Memory Open Data
1312
Bible by Midvash
com.midvash
Free, no-key Bible MCP server — 86 translations in 32 languages, from any MCP client.
Language Translation Education & Learning Tools
1
bible-app A
com.thaiapp
Read-only Bible for AI: search & read scripture in Thai & English, plus a daily verse.
Search Knowledge & Memory
52

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 a month ago (2026-07-30 16:59 UTC)
7
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
F
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 6 months ago (2026-03-08 22:11 UTC)
-
soapbox-faith
Education & Learning Tools Search
alansafahi
A
license
Not graded
quality
C
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 2 months ago (2026-07-20 16:39 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Freely-Given-org/open-english-translation-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Open English Translation (OET) MCP Server

What Makes the OET Different?

Quick Start

Running via uvx

Installation from Source

AI Client Configuration

1. Claude Desktop / Antigravity / Cursor

MCP Server Capabilities

1. Resources & Resource Templates

2. Tools

get_passage

compare_translations

search_text

search_lemma

lookup_word

get_lexicon_entry

get_translation_decisions

3. MCP Prompts

OET Translation Decision Codes Reference

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

Latest Blog Posts

MCP directory API

Running via `uvx`

`get_passage`

`compare_translations`

`search_text`

`search_lemma`

`lookup_word`

`get_lexicon_entry`

`get_translation_decisions`