Study Bible MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose, with detailed descriptions explaining when to use each one and how they differ from similar tools. The overlap between tools like lookup_name, explore_genealogy, and find_connection is explicitly addressed, making disambiguation straightforward.
Naming Consistency4/5
Tool names follow a consistent snake_case pattern and use a mix of verbs (explore, find, get, lookup, search, parse) and descriptive phrases. While not completely uniform (e.g., people_in_passage vs. parse_morphology), the naming is logical and predictable within subgroups.
Tool Count5/5
With 21 tools, the server covers a comprehensive range of Bible study tasks without being overwhelming. Each tool serves a distinct function, and the count is well-scoped for the domain's depth and breadth.
Completeness5/5
The tool set covers nearly every major aspect of Bible study: genealogies, events, places, cross-references, word studies, textual criticism, contextual background, and more. There are no obvious gaps, and the surface supports a thorough study workflow.
Average 4.4/5 across 21 of 21 tools scored. Lowest: 3.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 3 community issues answered or closed in the last 6 months
- 14 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds that it 'provides verified lexical data', which aligns but does not significantly extend behavioral context. No contradiction.
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 front-loaded with the key purpose and includes bullet-point formatting instructions. While lengthy, each part adds value for an AI agent. A slightly more streamlined version would score 5.
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?
No output schema exists, but the description provides an example of how to present results. However, it does not explicitly describe the tool's return value or fields, leaving some ambiguity.
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 100%, so the baseline is 3. The description does not add extra meaning beyond the schema for parameters; it focuses on usage and output formatting.
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 explicitly states 'ALWAYS USE THIS when discussing any Greek or Hebrew word, theological term, or concept', clearly defining the tool's purpose as providing verified lexical data for word studies. This distinguishes it from siblings by positioning it as the primary word study tool.
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 gives strong usage guidance: 'ALWAYS USE THIS' and advises using even if the AI knows the word. However, it does not explicitly mention when not to use or suggest alternatives like search_by_strongs or search_lexicon.
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 annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds that it returns actual verses and shows usage context, but does not disclose additional behavioral traits beyond what annotations provide. It effectively complements the annotations without contradiction.
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. It front-loads the usage instruction ('USE THIS after word_study'), then lists bullet points of benefits, and ends with a summary statement. Every sentence serves a purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the strong input schema, annotations, and the absence of an output schema, the description provides complete contextual guidance. It explains the workflow (after word_study), the purpose (transform definition into demonstration), and the output style (actual verses, range of meanings, key passages). No gaps remain for an agent to understand when and why to use this tool.
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 100%, and both parameters ('strongs' and 'limit') have clear descriptions in the input schema. The description does not add further meaning to the parameters beyond what the schema already provides, which meets the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to find actual verses where a Strong's number appears, transforming 'word study from definition into demonstration.' It distinguishes itself from siblings by specifying 'USE THIS after word_study' and contrasts with search_lexicon by focusing on actual usage.
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 provides explicit usage guidance: 'USE THIS after word_study' and explains the context of showing how a word is actually used. While it doesn't explicitly state when not to use, the workflow context is clear and sufficient for an agent to make appropriate decisions.
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?
Annotations already indicate readOnlyHint, destructiveHint, and idempotentHint. The description adds that it returns a Mermaid timeline diagram and instructs to include it in the response, which is useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose with multiple example sections and repeated guidance. While front-loaded with 'ALWAYS USE THIS', it could be more concise by condensing examples.
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 single-parameter tool with no output schema, the description covers output format (Mermaid timeline), usage contexts, and combination suggestions. It provides sufficient completeness for an agent.
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 100% with a clear 'person' parameter description. The description adds examples of names but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns every event in a person's life in chronological order, and distinguishes itself from siblings by being the only tool that shows life events in order. Specific examples (Moses, Paul, David) reinforce the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs 'ALWAYS USE THIS' for biographical questions, provides concrete examples of when to use (e.g., 'Tell me about Moses'), and suggests complementary tools (lookup_name, explore_genealogy).
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?
Annotations already indicate readOnlyHint, destructiveHint, and idempotentHint. Description adds that it returns the full dictionary article with cross-references, which is useful context beyond the annotations. No contradiction.
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?
Description is concise and well-structured: a short opening sentence, a bullet list of coverage areas, a 'USE THIS' section, and a return value statement. Every sentence serves a purpose with no 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?
Given single parameter and rich annotations, the description fully explains the tool's purpose, coverage, usage guidance, and return type. No output schema exists, but the description compensates by stating the return includes cross-references.
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 has 100% coverage with a clear description for 'topic'. Description provides example values (e.g., 'Abraham', 'covenant') but no additional semantic depth the schema lacks. Baseline 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?
Description clearly states verb+resource ('Look up a topic in the Tyndale Bible Dictionary') and enumerates specific categories of articles (people, places, concepts, etc.), distinguishing it from siblings like 'lookup_name' or 'word_study' that might have overlapping but different scopes.
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?
Provides explicit 'USE THIS when' scenarios (background info, historical context, detailed articles, scholarly definitions). While it does not mention when not to use or compare directly to siblings, the guidance is specific and actionable for an AI agent.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, making safety clear. The description adds behavioral context about the database contents (200+ terms, definitions, usage, cross-references, translation guidance), which goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with three clear sections: purpose, database features, and usage scenarios. Every sentence adds value, and the most important information is 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?
Given a single parameter, full schema coverage, and annotations indicating read-only/idempotent behavior, the description adequately covers what the tool returns (definitions, usage, cross-references, translation guidance). It does not detail output structure, which is acceptable without an output schema.
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 100% coverage with a description for 'term' including examples. The description lists additional examples (agape, atonement, covenant, grace) but does not add new meaning beyond the schema. Baseline 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 'Look up a key theological term in the FIA Key Terms database,' specifying the verb and resource. It distinguishes from sibling tools like 'get_bible_dictionary' and 'search_lexicon' by focusing on theological terms and providing examples.
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 explicitly lists when to use the tool: for precise definitions, understanding scriptural usage, translation-oriented explanations, and cross-references. It does not explicitly say when not to use it or mention alternatives, but the context is clear.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by detailing the sources (Tyndale, UW Translation, SIL Translator notes) and stating it provides published peer-reviewed scholarship, which sets appropriate expectations for output quality. No contradictions with annotations.
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 (8 lines) and immediately front-loads the main purpose in the first sentence. It uses clear bullet lists for sources and usage scenarios, and the final line qualifies the content as peer-reviewed. Every sentence earns its place with no 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?
Given the complexity of a tool combining three source types and two parameters, the description covers what is returned, when to use it, and the scholarly nature. It could be improved by clarifying whether the output is a merged list or separate sections, but overall it is sufficiently complete for effective use.
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?
Both parameters are fully described in the schema (100% coverage). The description does not add new syntactic or format details beyond what the schema provides. The usage guidelines indirectly imply chapter_only usage by mentioning chapter-level overview, but this doesn't improve semantic clarity beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns scholarly study notes and translation notes for a Bible verse or chapter, naming three specific sources and emphasizing peer-reviewed scholarship. This distinguishes it from sibling tools like lookup_verse or word_study.
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 includes a bullet list 'USE THIS when you need:' that explicitly covers four use cases (scholarly commentary, explanations, translation/cultural notes, chapter overview). While it doesn't name alternative tools, the listed scenarios provide clear guidance on when to invoke this tool.
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?
Annotations already declare the tool as read-only and idempotent. The description adds value by specifying the output format (generation numbers, relationship types, Mermaid diagram) and the data scope (1,100+ biblical persons). However, it does not mention limitations like potential missing persons or error handling, which would enhance transparency.
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 structured with clear sections: a bold directive, a summary, a usage table, and output details. It is not overly verbose; each part serves a purpose. However, the series of examples could be condensed slightly without losing clarity, making it a strong but not perfect score.
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 tool's complexity (3 parameters, no output schema), the description adequately covers purpose, usage guidance, and output format. It lacks mention of what happens when a person is not found or performance expectations, but for a genealogy tool with clear annotations and sibling differentiation, it is sufficiently complete.
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 100% coverage, meaning all parameters are already well-documented. The description does not add new semantic details beyond the schema, but it does provide example values ('David', 'Abraham', 'Jesus') that align with the person parameter. While no extra parameter info is needed, the description meets the baseline expectation.
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 defines the tool's function: it traverses multi-generational family trees for genealogical queries. It distinguishes itself from the sibling tool lookup_name by explicitly stating that explore_genealogy is for lineage across generations, while lookup_name handles immediate family. The purpose is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus the sibling tool lookup_name, with a detailed 'WHEN TO USE' section that includes concrete examples. It also instructs the agent to always use this tool for lineage-related questions, leaving no ambiguity about context.
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?
Annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that the tool returns structural pointers, not pre-written interpretation, and explains the output semantics (horizontal/vertical/sibling partners, directional meaning). It also mentions the source and provides a directive block for using the output. No contradictions.
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 structured into clear sections: purpose, background, use cases, output description, how to use, limitations. Every sentence adds value, and the key purpose is front-loaded. It is slightly long but appropriate for the specialized nature of the tool.
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 complexity of the tool and no output schema, the description adequately explains what is returned (unit, cell, partners, explanations) and how to use the output (call lookup_verse on partners, synthesize interpretation). It also cites the source and method, making it sufficiently 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 100% with one required parameter 'reference'. The description adds meaning by specifying 'Bible reference in Genesis–Deuteronomy' and providing examples, as well as the domain constraint (only Torah books). This adds value beyond the schema description.
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: 'Get the structurally-paired verses for a Torah passage under Moshe Kline's Woven Torah hypothesis.' It specifies the verb (Get), resource (structurally-paired verses), and domain (Torah passage, specific hypothesis). The use cases list further clarifies, and it distinguishes from siblings like get_cross_references by focusing on structural pairing.
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 includes a 'USE THIS when:' section listing specific scenarios, and it notes that only Torah books have data, implying a limitation. It doesn't explicitly mention when not to use or name alternatives, but the context distinguishes it from thematic cross-references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnly, destructive=false, idempotent. Description adds significant detail about the database size, relationship data (parents, children, siblings, spouse), and thematic linking capabilities, enhancing understanding beyond 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?
Well-structured with headings, bullet points, and examples. Front-loaded with an imperative. However, it is somewhat verbose and could be more concise without losing value.
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 no output schema, the description explains the relationship data and gives thematic linking examples, providing sufficient context for an agent to use the tool effectively. Could be more precise about the return format.
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 100% with name (string) and type (enum). The description does not add additional meaning beyond what the schema provides; it only repeats the parameter purposes indirectly. Baseline 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?
Clearly states the tool is for looking up biblical persons, places, or things, and emphasizes thematic linking. The description positions it as the primary tool for such lookups with specific examples.
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?
Starts with explicit 'USE THIS when' and provides clear context with examples of when to use it for thematic linking. However, it does not explicitly mention when to use alternative sibling tools like explore_genealogy or explore_place.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds significant behavioral context: it uses vector embeddings, returns ranked results, and crucially warns that semantic similarity does not imply theological connection, listing potential pitfalls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the main purpose, but it is verbose with multiple sections and lengthy bullet points. It could be more concise while retaining essential 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?
Despite lacking an output schema, the description explains it returns ranked passages by similarity score and provides ample context for an agent to use the results responsibly. It covers how to interpret and validate the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. The description adds context: reference is a Bible verse, limit is number (optional). It also mentions 'pre-computed embedding' for the reference, which provides additional nuance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Find passages with similar semantic content to a given Bible verse' and distinguishes it from siblings like get_cross_references and search_lexicon by emphasizing vector embeddings for semantic meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides extensive when-to-use guidance, including examples of discoveries, a critical hermeneutical warning, and a detailed step-by-step checklist for responsibly using results. It implicitly tells when not to use (e.g., for exact quotes or explicit cross-references).
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 discloses that the tool provides actual verse text (not paraphrased), original language, word-by-word breakdown with Strong's numbers, and genre-specific interpretation. It also instructs the AI to display original language in responses. Annotations already indicate read-only and idempotent behavior. This adds contextual behavior beyond 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 front-loaded with a bold instruction, then uses bullet points for clarity, and ends with a concrete example. It is slightly lengthy but every sentence adds necessary guidance. The structure is logical and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and no output schema, the description fully explains what the tool returns (verse text, original language, word breakdown, Strong's numbers, genre guidance). It covers all necessary context for an AI agent to use it correctly and leverage its output effectively.
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 input schema covers all three parameters with descriptions. The tool description adds context: it clarifies that include_original defaults to true and that include_morphology provides grammatical parsing. It also gives example reference formats. This adds moderate value beyond the schema alone, justifying a score above baseline 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 clearly states that this tool is for looking up Bible verses and provides the actual verse text, original Greek/Hebrew, word breakdown, and genre insights. It explicitly says 'ALWAYS USE THIS when any Bible verse is mentioned,' making the purpose unmistakable and distinguishing it from sibling tools that focus on cross-references, word studies, etc.
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 gives a strong usage guideline: 'ALWAYS USE THIS when any Bible verse is mentioned or relevant.' It also advises using it even if the AI can quote from memory, ensuring accurate text. However, it does not explicitly mention when not to use it or suggest alternative tools for specific needs.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is safe. The description adds behavioral context: it finds multiple words for a concept and allows explaining distinctions. No mention of side effects or API behavior, but the annotations cover safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with four sentences. It is front-loaded with 'USE THIS' and uses clear, direct language. Every sentence adds value, with no redundancy or filler.
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 tool is simple (read-only, 3 params, no output schema), the description adequately covers purpose and usage. It does not describe return format, but that is often implicit. The sibling tools list provides context, and the description distinguishes its role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by providing examples like 'love → agape, phileo, eros,' which implies the query parameter accepts English concepts. This extra guidance helps the agent use the query parameter effectively.
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: 'find Greek/Hebrew words for English concepts.' It provides specific examples (love, faith, salvation) and distinguishes itself from sibling tools by focusing on lexical search. The verb 'search' combined with 'lexicon' is precise.
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 explicitly says 'USE THIS to find...' and gives clear context: 'When a user asks about a biblical concept...' It also mentions an additional use case. However, it does not explicitly state when not to use it or list alternatives, but the sibling tools list provides context.
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 aligns with annotations (readOnlyHint, idempotentHint) and adds valuable behavioral context, such as the output being a Mermaid network diagram that must be included in responses. No contradictions. Minor deduction for not specifying response structure beyond the diagram note.
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 well-organized with clear sections: general purpose, usage guidance, differentiation from sibling, and output format. Every sentence adds value, and the structure aids quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema, rich annotations), the description provides all necessary context: what it returns, when to use it, and how it differs from similar tools. No gaps for effective agent decision-making.
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 fully describes the single parameter 'place,' and the description provides example values (Jerusalem, Bethlehem, Egypt) but does not add significant semantic meaning beyond the schema. Baseline 3 for high 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 defines the tool's purpose with specific verbs: 'Returns the complete biblical history of a place.' It distinctly differentiates itself from the sibling tool 'lookup_name' by highlighting the depth of information (full history vs basic info).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool, with concrete examples like 'Tell me about Jerusalem.' It also contrasts with 'lookup_name,' explaining when the simpler tool is more appropriate, offering clear decision criteria.
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?
Annotations already declare readOnlyHint and idempotentHint, so safety is covered. Description adds that it uses parent, child, sibling, spouse relationships and returns a Mermaid flowchart, providing useful behavioral context beyond annotations.
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?
Description is well-organized into sections with bold headers, front-loads the critical usage instruction, and every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully explains the tool's purpose, when to use, and that the output is a Mermaid flowchart. All necessary context is covered for this simple two-parameter tool.
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 100% with clear descriptions for person1 and person2. The description adds example values like 'Abraham' and 'David' but does not significantly extend beyond schema-provided semantics.
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 it traces the shortest family relationship path between two biblical people, using a specific verb and resource. It distinguishes from the sibling tool explore_genealogy by contrasting scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'ALWAYS USE THIS' for relationship questions, gives concrete examples, and contrasts with explore_genealogy with clear when-to-use and 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, non-destructive, and idempotent. The description adds context about returning all authors' content when none specified and that results include verse mappings and theme links. This adds some value, but no additional safety or behavioral details beyond 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 relatively long due to the extensive use case list, but it is well-structured with a clear opening sentence listing the main purpose, followed by bullet point examples. It remains focused on the tool's functionality without unnecessary filler.
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?
Without an output schema, the description briefly notes that results include scholarly content with verse mappings and theme links, which is sufficient for understanding the return type. Parameters are well-covered, and no required fields reduce complexity. Overall, it provides enough context for correct usage.
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 covers all four parameters (reference, theme, author, limit) with descriptions, so baseline is 3. The description provides concrete examples (e.g., 'Psalm 82:1', 'divine_council') and explains the effect of omitting author, enhancing semantic value.
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 retrieves theological scholarship context for Bible passages or themes, specifying authors and content types. It distinguishes itself from siblings like 'get_ane_context' or 'get_bible_dictionary' by focusing on specific scholars (Heiser, Bradley) and providing verse mappings and theme links.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists numerous use cases (e.g., 'divine council', 'sons of God') and maps them to authors. It also explains behavior when no author is specified, giving clear guidance 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?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint. Description adds behavioral context: it is comprehensive, works at verse-level only, and returns combined data. No contradictions, but no need for more since annotations cover safety.
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?
Description is structured with headings and examples, making it easy to scan. While slightly longer than minimal, every sentence adds value. It is front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no output schema, and high complexity in output (verse text, entities, relationships), the description fully explains what is returned and when to use it. It compares with siblings and provides a concrete example, making it complete for an AI agent.
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 description coverage is 100% (one parameter). Description adds value by explaining the parameter is a Bible verse reference, providing examples like 'Matthew 1:1' and showing how it translates into output. This goes beyond the schema's basic description.
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 that the tool is for deep study of a specific verse, returning verse text plus all people, places, events, and family relationships. It distinguishes itself from sibling tool 'people_in_passage' by specifying it is verse-level only and includes family relationships.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides usage guidelines with 'USE THIS WHEN' and 'DIFFERENCE FROM' sections, telling when to use (deep-dive, sermon prep, saving calls) and when not to (use people_in_passage for chapters/entities only).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds structured data dimensions, periods, and method to retrieve methodology guardrails, exceeding annotation requirements.
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 well-structured with sections, but somewhat long. It is front-loaded with purpose and usage, and each section adds value, though could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description comprehensively covers input options, structural dimensions, and behavior (e.g., calling with no arguments). It provides sufficient context for an agent to use the tool effectively.
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?
Schema coverage is 100% with clear descriptions. The description further explains the purpose of each parameter, including enumeration of dimensions and periods, and details the detail_level behavior.
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 retrieves ANE cultural and historical background for a biblical passage. It lists specific dimensions and periods, differentiating it from sibling tools like get_bible_dictionary and get_theology_context.
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 includes a 'USE THIS when' section with 16 specific scenarios and advises calling with no arguments to explore options. It lacks explicit when-not-to-use guidance but context implies alternatives exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds value by detailing the output format (grammatical explanation including part of speech, person, number, tense, etc.) which goes beyond the annotations. No contradictions.
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 (3 sentences), front-loads the purpose, and uses examples effectively. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description is complete. It explains input formats, language options, and the kind of output provided. No gaps remain.
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 input schema covers 100% of parameters with descriptions. The description adds extra context by specifying the coding systems (Robinson for Greek, Westminster/OpenScriptures for Hebrew) and examples of valid codes, enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool explains morphological/grammatical parsing codes, with specific examples for Greek and Hebrew. It distinguishes itself from sibling tools like lookup_verse or search_lexicon by focusing on parsing codes rather than other operations.
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 when to use the tool (for parsing codes) but does not explicitly state when not to use it or provide alternatives. However, the context of sibling tools makes the usage clear. The lack of explicit exclusions prevents a higher score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds behavioral context that it is essential for passage study and returns entity lists. No contradictions, and the description provides additional useful detail beyond annotations.
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?
Description is well-structured with a strong first sentence, clear purpose, usage scenarios, and a direct comparison with a sibling tool. Every sentence adds value, no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter, no output schema, and multiple sibling tools, the description fully covers what the tool does, when to use it, and how it differs from alternatives. It explains the return type (list of people, places, events) sufficiently.
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?
Input schema has one parameter 'reference' with description covering chapter and verse formats; schema description coverage is 100%. The description does not add further parameter information beyond what schema already provides, so 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 returns all people, places, and events in a passage, with examples like 'Abraham, Isaac, angel of the LORD, Moriah' for Genesis 22. It explicitly distinguishes from sibling tool graph_enriched_search by noting difference in scope and output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description starts with an imperative 'ALWAYS USE THIS' and provides explicit when-to-use scenarios: studying narrative passages, explaining chapters, or user asking about a passage. It also directly compares with graph_enriched_search, giving clear guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds extensive behavioral detail: the three-tier ranking, default limit cap with suppression behavior, interpretation of scores (TSK vote scale, CH tags, Gage tiers, Burnett strength), and the caveat that fewer rows can be correct. No contradiction with 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 lengthy but well-structured with sections (modes, tier explanations, caveat, adaptive default, score interpretation). Each sentence adds value and the formatting uses bullet points and tables for clarity. Slightly long but justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 optional parameters, no output schema, and high complexity, the description thoroughly covers all aspects: parameter usage, result interpretation, edge cases (signal-poor anchors), fallback strategies, and caveats. Prepares the agent to handle both common and rare scenarios.
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?
Schema coverage is 100% but description adds significant meaning: explains limit as a cap not target, min_strength disables tier-1 suppression, source filters and their defaults, and how parameters interact (e.g., adaptive default suppression). Provides examples and sensible thresholds for min_strength. Goes far beyond schema 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 explicitly states when to use the tool: 'USE THIS whenever you are explaining, exegeting, or arguing from a specific Bible verse — and for any theological or doctrinal question.' It clearly identifies the resource (cross-references from multiple scholarly sources) and distinguishes from sibling tool find_similar_passages by noting the latter catches verbal parallels the topical index would skip.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Use this BEFORE drawing any theological conclusion from a single verse' and explains when to use theme mode. It also gives caveats about coverage and suggests alternatives like find_similar_passages when the topical index is insufficient. The description includes explicit when-not-to-rely guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, and idempotent behavior. The description adds detailed behavioral context: what data it returns (MT reading, variant, witnesses, scholarly consensus, HLT preference) and the principle behind HLT's choices, all consistent with a safe 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with bold headings and bullet points, prioritizing key usage guidance upfront. While every section adds value, it could be slightly tighter; however, the clarity and organization justify the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter, no output schema, and the annotations cover safety, the description comprehensively explains return fields, usage scenarios, and underlying principles. It leaves no ambiguity about what the tool does or how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage for the single parameter 'reference' with a description. The description adds value by clarifying that the reference can be either an OT or NT verse and that both return the same variant row, enriching semantic understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'USE THIS whenever...' and clearly states the tool's purpose: to retrieve textual variants when a New Testament writer quotes an Old Testament verse with wording differing from the Masoretic Text. It specifies the trigger condition and differentiates from siblings by naming 'lookup_verse' as a complementary tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance with a bulleted list of specific scenarios (e.g., explaining mismatches, discussing particular verses). It states when to use the tool and pairs it with 'lookup_verse', making it clear when this tool is appropriate.
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:

[![studybible-mcp MCP server](https://glama.ai/mcp/servers/djayatillake/studybible-mcp/badges/card.svg)](https://glama.ai/mcp/servers/djayatillake/studybible-mcp)

Score Badge

Copy to your README.md:

[![studybible-mcp MCP server](https://glama.ai/mcp/servers/djayatillake/studybible-mcp/badges/score.svg)](https://glama.ai/mcp/servers/djayatillake/studybible-mcp)

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/djayatillake/studybible-mcp'

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