js-translation-helps-proxy

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.1
Disambiguation4/5
Most tools target distinct resource types (scripture, notes, questions, words, word links, academy), making them easy to differentiate. However, the fetch tools' filter parameters overlap with the dedicated search tool, creating minor ambiguity about which tool to use for discovery.
Naming Consistency4/5
The majority follow a consistent 'fetch_<resource>' pattern (fetch_translation_notes, fetch_scripture, etc.), but 'get_system_prompt' and 'search_biblical_resources' break the pattern, mixing 'get' and 'search' verbs with 'fetch'.
Tool Count5/5
With 8 tools, the count is well within the ideal range for a domain-specific proxy. Each tool represents a distinct core capability, and none feel redundant or excessive.
Completeness5/5
The set covers all major translation help resources—scripture, notes, questions, words, word links, and academy articles—plus a cross-resource search tool. This provides a comprehensive read-only surface with no obvious gaps for the stated purpose.
Average 3.5/5 across 8 of 8 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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 MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
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 bears the full burden of behavioral disclosure. It states the tool 'gets' or 'searches' which implies read-only behavior, but it doesn't disclose details about response structure, pagination, rate limits, or any side effects. The schema adds some filter behavior (stemmed regex) but the description itself is thin on behavioral traits.
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 a single concise sentence, front-loaded with the main action. It avoids unnecessary words. However, it might be too terse given the tool's complexity, but for conciseness it earns a good score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no annotations, and no output schema, the description is insufficiently complete. It does not explain what the returned articles look like, how language/organization affect results, or provide examples of usage. For a tool with this complexity, the description should offer more context to enable correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 60%, with descriptions for filter, category, and moduleId. The description adds a small amount of semantic value by explaining that the filter searches across all modules, which parallels the schema's description. However, it does not clarify language or organization parameters, and the added value over the schema is minimal. Given moderate schema coverage, a baseline 3 is appropriate.
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 identifies the tool's purpose: retrieving Translation Academy articles. It also mentions an alternative mode (using filter to search across modules), which adds specificity. It distinguishes itself from siblings like fetch_translation_notes and fetch_translation_questions by explicitly naming the resource type (Translation Academy), though it doesn't contrast directly.
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 explicit guidance on when to use this tool versus alternatives. It does not mention siblings or exclusions. The only implicit hint is that it's for Translation Academy content, but there is no when-to-use/when-not-to-use guidance.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool 'gets' or 'searches,' implying read-only behavior, but does not describe what 'word links' are, the return format, pagination, or effects of invalid or missing parameters. This is a significant transparency gap even for a read 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 a single sentence with no filler, front-loading the core action ('Get translation word links') and then adding the alternative filter mode. Every word earns its place; it is excellently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description leaves many gaps: it does not define 'translation word links,' clarify the relationship between reference and filter, mention default values for language/organization, or explain what the output looks like. With 6 optional parameters and no output schema or annotations, the description is not sufficiently complete for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (filter, category, reference, testament have descriptions; language and organization rely on defaults). The description adds minimal extra parameter meaning—only that 'filter' enables a broader search. It does not explain language, organization, or the interplay between reference and filter, but the schema partially covers this.
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 uses a specific verb ('Get') and resource ('translation word links') with two clear modes: for a Bible reference or via filter. This distinguishes it from sibling tools like fetch_translation_word (singular) and search_biblical_resources, though it does not explicitly name alternatives. The resource is specific enough to convey its unique purpose.
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 two usage scenarios: use it with a reference to get links, or use a filter to search across all word links. However, it provides no explicit guidance on when to prefer this over fetch_translation_word or search_biblical_resources, and does not mention exclusions or preconditions. The usage context is implied but not fully clarified.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Fetch' (implying read-only) and describes two lookup modes, but does not explain the output format differences, default markdown behavior, or any limitations. The description adds minimal context beyond what the tool name already suggests.
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?
A single, well-structured sentence that states the core purpose and an alternative usage mode. Every word contributes meaning, and the filter parameter is mentioned to clarify a non-obvious usage.
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?
For a tool with 7 parameters, no output schema, and no annotations, the description is functional but sparse. It relies heavily on the schema to convey parameter details and does not mention output formats or default values, which are important for a fetch tool. The description is adequate for straightforward use but lacks depth for edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 71%, with good descriptions for filter, format, search, reference, and testament, but language and organization are undocumented. The description highlights the filter parameter's role in searching, aligning with the schema, but does not compensate for the missing parameter descriptions. Overall, the schema does most of the heavy lifting.
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 fetches translation notes, either for a specific Bible reference or via a filter search across all notes. This distinguishes it from sibling tools like fetch_translation_questions and fetch_translation_word by naming the resource type and its unique search mode.
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 two usage modes (reference lookup or filter search) but does not explicitly mention which sibling tool to use instead for other resource types. The context is evident from the tool name, but there are no explicit alternatives or when-not-to-use guidance.
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, so the description carries the full burden. 'Get' implies a read operation, but the description does not state whether this action is safe, non-mutating, or requires any special permissions. It also doesn't disclose potential side effects or what happens if the optional parameter is omitted. The transparency-focused wording does not compensate for these gaps.
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, compact sentence that directly states the tool's purpose with minimal waste. It is appropriately sized and front-loaded.
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 tool is simple with one optional parameter and no output schema. The description clearly indicates what the tool returns (system prompt and constraints), but it lacks usage guidance and behavioral disclosure. Given the simplicity, the description is adequate but not fully complete, especially due to missing annotations.
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 input schema has full coverage (100%) for the single parameter 'includeImplementationDetails', which includes its own description. The tool description adds no additional meaning about the parameter beyond the schema, so a baseline score of 3 is appropriate.
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: 'Get the complete system prompt and constraints'. It uses a specific verb and resource, and the purpose is distinct from sibling tools which focus on biblical resources and translations.
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 phrase 'for full transparency about AI behavior' implies a usage context, but there is no explicit guidance on when to use this tool versus alternatives, no when-not-to-use cases, and no mention of prerequisites. The sibling tools are clearly different in domain, so the purpose is understandable, but explicit guidelines are missing.
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?
With no annotations provided, the description must carry the burden of behavioral disclosure. It adds useful context by naming the BM25 scoring algorithm and the resource types searched, but it does not explicitly state that the operation is read-only or describe any side effects, rate limits, or permission requirements. For a simple search tool this is adequate but not thorough.
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, front-loaded sentence of 12 words. It contains no repetition, filler, or unnecessary details. Every word contributes to conveying the purpose and key behavioral attribute (BM25), making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no annotations, and no output schema, the description is too sparse. It does not mention return format, pagination, parameter usage, or relationship to sibling fetch tools. The brief description covers only the core purpose, leaving the agent without adequate context to invoke the tool correctly in varied scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (query and reference have descriptions). The description itself does not explain the remaining parameters (limit, language, includeHelps, organization) and only mentions resource types, which are not directly tied to parameters. This leaves the agent to guess meanings of several important fields, so the description fails to compensate for the low schema coverage.
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 performs a search over biblical translation resources (scripture, notes, questions, words) using BM25 scoring. This verb+resource combination is specific and distinguishes it from sibling fetch_* tools, which retrieve specific resources by identifier rather than searching across them.
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 as a discovery/search mechanism but does not explicitly state when to use it versus the fetch_* siblings. There is no mention of alternatives or exclusions, so the guidance remains implicit rather than spelled out. The tool name itself signals a search role, but the description alone lacks explicit direction.
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, so the description must carry the full burden of behavioral disclosure. It only mentions the two input modes but leaves critical ambiguities: what happens if both reference and filter are given, what happens when no parameters are supplied (since all are optional), and what the return structure looks like. These omissions limit 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 a single, concise sentence that front-loads the primary action and clearly contrasts the two usage modes. Every word contributes meaning, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 optional parameters, no output schema, and no annotations, the description is too brief to be considered complete. It fails to explain parameter interactions, default behaviors, ambiguity when both reference and filter are used, or the shape of the returned data, leaving an AI agent under-informed for proper invocation.
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 schema already covers 67% of parameters with descriptions for filter, search, reference, and testament. The description adds value by explaining the relationship between reference (specific Bible reference) and filter (search across all questions), but it does not clarify the remaining undocumented parameters like language and organization. Baseline for moderate coverage is 3.
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 uses the specific verb 'Fetch' with the clear resource 'translation questions', and explicitly defines two modes: fetching by Bible reference or searching via the filter param. This clearly distinguishes it from sibling tools like fetch_translation_notes and fetch_translation_word, which target different resource types.
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 clearly indicates the two primary use cases: retrieving questions for a specific Bible reference, or using the filter param to search across all questions. However, it does not explicitly name sibling tools or provide when-not-to-use guidance, such as when to prefer fetch_translation_notes over this tool.
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 adds the directive 'ALWAYS use format: "md" for best results', which is useful behavioral guidance, but it does not disclose return structure, rate limits, or potential side effects. Since this is a fetch operation, the lack of explicit read-only disclosure is mitigated but not fully addressed.
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 two sentences, front-loaded with the primary purpose, and every word earns its place. It is concise without sacrificing clarity.
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?
With 8 parameters and no output schema, the description leaves out explanations of resource, testament, organization, and language. It does cover the main usage modes, but relies heavily on the schema for full context, making it minimally sufficient rather than complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, and the description adds meaningful context by explaining when to use reference versus search/filter, and strongly recommends format 'md'. This clarifies parameter relationships beyond the schema's individual field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Fetch Bible scripture text' with a specific verb and resource, and clearly distinguishes this tool from sibling translation resources. It also differentiates the discovery modes (reference vs search/filter), making the scope unambiguous.
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 provides guidance on when to use reference versus search/filter, but does not explicitly mention alternatives or when not to use this tool relative to siblings like search_biblical_resources. Usage is implied rather than explicitly contrasted with other tools.
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 present, so the description carries full burden. It adds context about the library's size ('thousands of articles') but doesn't disclose behavior such as whether it returns a list or single item, nor any read-only/auth implications beyond the verb 'Get'.
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?
Two concise sentences: the first states the tool's purpose and scope, the second provides a key usage tip. No fluff, front-loaded.
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?
For a straightforward lookup tool with all-optional parameters and no output schema, the description covers the primary use case and the main search parameter. It doesn't detail return format, but that's not expected without an output schema. Minor gaps like language/organization are covered by defaults.
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 schema already describes term, filter, and category. The description adds a practical hint to use filter for searching, but doesn't explain the interaction between term and filter or the remaining language/organization parameters. With 60% schema coverage, this is adequate but not highly informative.
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 uses a specific verb phrase 'Get Translation Word articles' and enumerates content types (key biblical terms, names, places, other words), clearly distinguishing it from sibling tools like fetch_translation_notes or fetch_scripture.
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?
It gives an explicit directive to use the filter parameter for searching across all words, and the description implies that this tool is for word/article lookups. However, it doesn't explicitly contrast with alternatives or state when not to use it, so not a 5.
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:

[![js-translation-helps-proxy MCP server](https://glama.ai/mcp/servers/JEdward7777/js-translation-helps-proxy/badges/card.svg)](https://glama.ai/mcp/servers/JEdward7777/js-translation-helps-proxy)

Score Badge

Copy to your README.md:

[![js-translation-helps-proxy MCP server](https://glama.ai/mcp/servers/JEdward7777/js-translation-helps-proxy/badges/score.svg)](https://glama.ai/mcp/servers/JEdward7777/js-translation-helps-proxy)

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/JEdward7777/js-translation-helps-proxy'

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