Open English Translation of the Bible
OfficialServer Quality Checklist
Latest release: v0.1.2
- 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/5All 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/5Seven 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/5The 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.
Average 3.8/5 across 7 of 7 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Creative Commons Zero v1.0 Universal.
This repository includes a README.md file.
Tools from this server were used 10 times in the last 30 days.
This repository includes a glama.json configuration file.
This server has been verified by its author.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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.
- 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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.
- 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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.
- 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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.
- 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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.
- 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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.
- 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
shields.io Endpoint
For READMEs with an existing badge row. Append &style=flat-square (or any other shields.io style) to match the rest, and &metric=tools, &metric=maintenance or &metric=claim to badge a different dimension.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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