Bibelstudium MCP

Server Details

Wortgetreue deutsche Bibelarbeit: Grundtext, Morphologie, Konkordanz, Querverweise

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Last Tested: 2026-09-07 20:19
Transport: Streamable HTTP
URL
Repository: fidpa/bibelstudium-mcp
GitHub Stars: 2

Available Tools

7 tools

bible_compareA

Read-only

Inspect

Compare one NT verse word-by-word across the Greek editions (byzantine Majority Text, tr Textus Receptus, sblgnt critical text) and list the textual differences. Accentuation/case are ignored (byzantine/tr are stored unaccented), so reported differences are real variants or spelling variants (e.g. movable Ny). Additionally reports per-word attestation across eight editions (NA27/28, Tyndale House, SBL, Westcott-Hort, Tregelles, TR, Byzantine; STEPBible TAGNT). Use for questions about textual variants (e.g. the Comma Johanneum, 1Jn 5:7). OT verses have only one edition (WLC) and cannot be compared.

ParametersJSON Schema

Name	Required	Description
`book`	Yes	NT book name in German (e.g. "Römer", "1Joh")
`verse`	Yes	Single verse number
`chapter`	Yes	Chapter number

Output Schema

ParametersJSON Schema

Name	Required	Description
`hinweis`	Yes
`kurzref`	Yes	Same reference in the short German citation form ("2Kor 8,9.13-15"). Copy this into prose; `reference` spells the book out and is not the citation form.
`quellen`	Yes
`sprache`	Yes
`warnung`	No	The TAGNT attestation contradicts the edition text here. Belongs in the answer about this verse, not in a footnote.
`bezeugung`	No
`editionen`	Yes
`reference`	Yes
`vergleiche`	Yes
`bezeugung_fehlt`	No	Why `bezeugung` is absent for this verse. A gap in the source, not a statement about the verse.
`quellenkonflikte`	No	Per affected form, what the edition actually reads. The edition text governs, not the TAGNT note.

TDQS

A4.7/5.0

Behavior5/5

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

The description adds substantial behavioral context beyond the readOnlyHint annotation: accentuation/case are ignored, reported differences are real variants or spelling variants (e.g., movable Ny), and it reports per-word attestation across eight editions. It also discloses the OT limitation. This exceeds what annotations alone convey.

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 front-loaded with the core action, followed by technical nuances, usage examples, and limitations. Every sentence earns its place, with no repetitive or filler content, and the length is appropriate for 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?

For a comparison tool with an output schema, the description covers the essential aspects: what is compared, how differences are normalized, the attestation feature, and the OT limitation. The output format is presumably handled by the output schema, so no gaps remain.

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 already provides full descriptions for all three parameters (100% coverage), including the German NT book naming convention. The description adds no additional parameter-specific semantics beyond the schema, so the baseline 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: 'Compare one NT verse word-by-word across the Greek editions... and list the textual differences.' This specific verb+resource distinguishes it from siblings like bible_lookup or bible_search, and the mention of per-word attestation further clarifies the 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?

Explicit usage guidance is provided: 'Use for questions about textual variants (e.g. the Comma Johanneum, 1Jn 5:7).' It also gives a clear exclusion: 'OT verses have only one edition (WLC) and cannot be compared.' This tells the agent exactly when to select this tool over alternatives.

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

bible_concordanceA

Read-only

Inspect

Concordance / word study: find ALL occurrences of an original-language word across the Bible. Search by Strong's number (preferred; "G26" = Greek/NT, "H7225" = Hebrew/OT) or by exact lemma as returned by bible_original (e.g. "ἀγάπη", "רֵאשִׁית"). Returns total count, per-book distribution, an occurrence list with the inflected surface forms, and English lexicon data (gloss, Strong's definition; for Greek also the full Abbott-Smith entry). NT edition selectable via texttyp (default byzantine).

ParametersJSON Schema

Name	Required	Description	Default
`lemma`	No	Exact Greek or Hebrew lemma (alternative to strong; script determines testament)
`limit`	No	Maximum occurrences to list (default 50, max 200); counts are always exact
`strong`	No	Strong's number with testament prefix, e.g. "G26" or "H7225"
`texttyp`	No	NT text edition: "byzantine" (default), "sblgnt", or "tr". Ignored for Hebrew.	byzantine

Output Schema

ParametersJSON Schema

Name	Required	Description
`suche`	Yes
`verse`	Yes	Distinct verses containing it, exact.
`gesamt`	Yes	Occurrences of the word, exact. Counts are never capped by `limit`.
`strong`	No
`buecher`	Yes	Full distribution over all occurrences, not only the listed ones.
`edition`	Yes
`hinweis`	No
`lexikon`	No
`quellen`	Yes
`texttyp`	Yes
`bedeutung`	No
`grundform`	Yes
`umschrift`	No
`vorkommen`	Yes
`kjv_woerter`	No	English renderings the King James Version uses for this word. A statement about that translation, not about the Greek or Hebrew word itself.
`kurzbedeutung`	No

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already include readOnlyHint=true, but the description adds substantial behavioral detail: it lists the exact outputs (total count, per-book distribution, occurrence list with inflected forms, lexicon data including Abbott-Smith for Greek) and explains NT edition selection via texttyp. It also clarifies that counts are always exact, which is useful behavioral information.

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 dense paragraph with no wasted words. It front-loads the purpose, then covers search methods, outputs, and edition selection. Every sentence adds critical information.

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

Completeness4/5

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

The tool is complex, but the description covers the core functionality well: how to search, what results look like, and edition selection. Given an output schema exists, it doesn't need to detail return values. It's slightly incomplete around edge cases like mixed-testament searches, but overall it's adequate.

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% and each parameter is well-explained. The description adds value by marking Strong's as the preferred method and referencing bible_original, which provides additional context beyond the schema. It also explicitly notes the texttyp default and that it's ignored for Hebrew, though this is already in 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 opens with 'Concordance / word study: find ALL occurrences of an original-language word across the Bible.' This clearly identifies the tool's function (find all occurrences) and its scope (original-language words in the Bible). It distinguishes itself from siblings like bible_lookup or bible_search by focusing on word study and referencing bible_original for lemma input.

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 states when to use this tool ('word study') and gives specific search methods (by Strong's number or exact lemma from bible_original). It doesn't explicitly state when not to use it, but the context is clear enough to guide selection among the sibling tools.

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

bible_crossrefsA

Read-only

Inspect

Find cross-references (related/parallel passages) for one Bible verse, ranked by relevance votes, with the German text of the targets (in editions that cap verbatim quoting, the later targets carry stelle and votes only). Use this to find where a theme, quote or promise recurs elsewhere in Scripture. Where the UBS Parallel Passage Database lists the verse, parallelen adds the closed set of parallel places (synoptic pericopes, Kings/Chronicles doublets, OT quotations in the NT, recurring formulas) that the vote ranking often buries. Data: Treasury of Scripture Knowledge (expanded), OpenBible.info, CC-BY; UBS Parallel Passage Database, CC BY-SA 4.0.

ParametersJSON Schema

Name	Required	Description	Default
`book`	Yes	Book name in German (e.g. "Jesaja", "1. Mose", "Römer")
`limit`	No	Maximum number of references to return (default 10, max 30)
`verse`	Yes	Single verse number
`chapter`	Yes	Chapter number
`translation`	No	Translation for the quoted target texts: "LUT" (Luther 1912), "SCH" (Schlachter 1951), "ELB" (Elberfelder 1871), "MB" (Menge 1939), "SLT" (Schlachter 2000). Default: "SLT" (Schlachter 2000). Aliases like "luther", "schlachter" accepted. Only editions this instance actually loaded can be requested; bible_server_info lists them.	SLT

Output Schema

ParametersJSON Schema

Name	Required	Description
`gesamt`	Yes	Number of references that exist for this verse, independent of `limit`. Larger than `verweise.length` means the list was cut; take this number, do not derive one from the list.
`hinweis`	No
`kurzref`	Yes	Same reference in the short German citation form ("2Kor 8,9.13-15"). Copy this into prose; `reference` spells the book out and is not the citation form.
`quellen`	Yes
`gekuerzt`	No
`verweise`	Yes
`reference`	Yes
`parallelen`	No	Present only when the UBS Parallel Passage Database lists this verse. A group is an unordered set with no direction and no ranking, unlike `verweise`; a verse can belong to more than one group.
`lesehinweis`	No

TDQS

A4.1/5.0

Behavior4/5

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

Beyond the readOnlyHint annotation, the description discloses ranking by relevance votes, the caveat that later targets may carry only stelle and votes in verbatim-quote-capping editions, and the special parallelen addition from the UBS Parallel Passage Database. It also names data sources and licenses, which is useful behavioral context.

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?

Four sentences, with the main purpose front-loaded and each sentence adding distinct information. The parenthetical about verbatim quoting is dense but not wasteful.

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?

Covers the purpose, ranking behavior, the special UBS parallel set, and data provenance, while the output schema presumably documents the return structure. It lacks error-handling or invalid-input notes, but these are not critical for a read-only lookup 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%, so the schema already documents all five parameters. The description adds some context about translation edition behavior and German target text, but it does not materially go beyond what the parameter descriptions already provide.

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?

States a specific verb and resource: 'Find cross-references (related/parallel passages) for one Bible verse, ranked by relevance votes, with the German text of the targets'. This clearly identifies what the tool does and produces, and it is distinguishable from sibling tools like bible_lookup or bible_search by the cross-reference focus.

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?

Gives an explicit use case: 'Use this to find where a theme, quote or promise recurs elsewhere in Scripture.' It does not explicitly name alternative sibling tools, but this usage context plus the output type makes when-to-use clear.

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

bible_lookupA

Read-only

Inspect

Look up Bible verses by reference. Returns exact text from a licensed German translation (see the translation argument for this instance's default). Use this for ALL Bible quotes — never quote from memory. When the edition carries footnotes for the requested verses, the field 'fussnoten' holds them verbatim: these are the publisher's own notes, not this server's, and they typically record an alternative rendering the edition weighed. Also call it when a book or reference looks unfamiliar, misspelled or made up, and before answering whether a book exists or belongs to the canon: the error names the nearest known book and states which canon this database covers. Do not answer such questions from memory either — a reference that seems wrong is a reason to call this tool, not to skip it.

ParametersJSON Schema

Name	Required	Description	Default
`book`	Yes	Book name in German (e.g. "Jesaja", "1. Mose", "Römer", "Ps", "Mt")
`verses`	No	Verse(s): single "4", range "16-17", list "1,3,5", or combined "1-3,7". Omit for the whole chapter. Some editions cap how many verses one call may quote; the response then says so in `hinweis` and `gekuerzt`, and `reference` names what it contains.
`chapter`	Yes	Chapter number
`translation`	No	Translation: "LUT" (Luther 1912), "SCH" (Schlachter 1951), "ELB" (Elberfelder 1871), "MB" (Menge 1939), "SLT" (Schlachter 2000). Default: "SLT" (Schlachter 2000). Aliases like "luther", "schlachter" accepted. Only editions this instance actually loaded can be requested; bible_server_info lists them.	SLT

Output Schema

ParametersJSON Schema

Name	Required	Description
`text`	Yes
`hinweis`	No
`kurzref`	Yes	Same reference in the short German citation form ("2Kor 8,9.13-15"). Copy this into prose; `reference` spells the book out and is not the citation form.
`quellen`	Yes
`gekuerzt`	No
`fussnoten`	No
`reference`	Yes
`translation`	Yes

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses additional behavioral traits: footnotes are returned in the 'fussnoten' field with provenance, truncation can occur with `hinweis` and `gekuerzt`, and error responses name the nearest known book and canon coverage. This goes well 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 front-loads the core purpose and then adds high-value usage rules and edge-case handling. While slightly verbose, every sentence earns its place—no filler or repetition. It could be tightened slightly, but it remains 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 moderate complexity, the description covers footnotes, truncation, error behavior, canon questions, and memory-safety. With a rich output schema and readOnly/openWorld annotations, the description fully equips an agent to use the tool appropriately across normal and edge-case scenarios.

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 all parameters have detailed descriptions, so the schema carries the heavy lifting. The description adds minimal param-specific value beyond referencing the default translation and hinting that translation availability is instance-dependent, but this does not materially enhance the schema's meaning.

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

Purpose5/5

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

The description opens with a specific verb and resource: 'Look up Bible verses by reference.' It clearly differentiates from sibling tools by stating it is for ALL Bible quotes and never to quote from memory, positioning it as the canonical lookup 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?

Explicit when-to-use guidance is given: 'Use this for ALL Bible quotes — never quote from memory.' It also instructs to call the tool when a reference looks unfamiliar or before answering canon questions, and explicitly warns against skipping the tool for seemingly wrong references. This provides strong contextual usage direction.

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

bible_originalA

Read-only

Inspect

Return one Bible verse word-by-word in the ORIGINAL language with lemma, Strong's number and full morphology. Use this to verify what the original text says — e.g. whether a noun is singular or plural — instead of inferring it from a translation. Covers the whole Bible: the OT (book 1–39) is served from the Hebrew/Aramaic Westminster Leningrad Codex; the NT (40–66) from a Greek text type chosen via texttyp — "byzantine" (Majority Text, default), "sblgnt" (critical), or "tr" (Textus Receptus, the only one with the Comma Johanneum). Edition and text type are labelled in the output.

ParametersJSON Schema

Name	Required	Description	Default
`book`	Yes	Book name in German (e.g. "1. Mose", "Jesaja", "Römer", "Galater")
`verse`	Yes	Single verse number
`chapter`	Yes	Chapter number
`texttyp`	No	NT text edition: "byzantine" (Majority Text, default), "sblgnt" (critical SBL), or "tr" (Textus Receptus). Ignored for the OT (always Hebrew WLC). Compare byzantine vs. tr to see TR-only readings such as the Comma Johanneum (1Joh 5,7).	byzantine

Output Schema

ParametersJSON Schema

Name	Required	Description
`edition`	Yes
`hinweis`	Yes
`kurzref`	Yes	Same reference in the short German citation form ("2Kor 8,9.13-15"). Copy this into prose; `reference` spells the book out and is not the citation form.
`quellen`	Yes
`sprache`	Yes
`texttyp`	Yes
`woerter`	Yes
`reference`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, but the description adds substantial behavioral detail: coverage of the whole Bible, OT vs NT source texts, text-type options, the Comma Johanneum caveat, and the fact that output labels the edition. This goes well beyond the annotation baseline.

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 long but well-structured: purpose, use case, coverage, and text-type details are ordered logically. Every sentence contributes critical information, and the front-loaded opening gives immediate clarity.

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 complexity (original language, morphology, OT/NT text types), the description covers all essential aspects: what is returned, how to choose text types, coverage scope, and output labeling. The presence of an output schema means return-value details are not required, and nothing important is missing.

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 the baseline is 3. The description adds significant meaning beyond the schema: it explains the OT/NT source difference, notes that texttyp is ignored for the OT, and highlights that 'tr' is the only text type with the Comma Johanneum, plus a comparison use case. This enriches parameter understanding usefully.

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 names a specific verb ('Return') and resource ('one Bible verse word-by-word in the ORIGINAL language with lemma, Strong's number and full morphology'), clearly differentiating it from translation-focused tools. The contrast with inferring from a translation reinforces a distinct purpose.

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 states when to use it ('verify what the original text says — e.g. whether a noun is singular or plural') and implicitly contrasts with translation-based inference. It does not name sibling tools but provides a clear use case and text-type selection guidance, making the intended context unambiguous.

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

bible_searchA

Read-only

Inspect

Full-text search over the German Bible text. Finds verses containing ALL given words (exact word forms; umlauts/accents are folded, so 'fuhrt' matches "führt"). Quote phrases ("Gnade um Gnade"); a trailing * makes a prefix search (lieb* finds liebe/lieben/liebet …). Use this to locate a passage when the wording is known but the reference is not. Optionally restrict to one book.

ParametersJSON Schema

Name	Required	Description	Default
`book`	No	Optional: restrict to one book (German name, e.g. "Psalmen", "Röm")
`limit`	No	Maximum verses to return (default 10, max 50); the total count is always exact
`query`	Yes	Words or "phrases" to search for, e.g. 'Hirte mangeln' or '"Gnade um Gnade"'
`translation`	No	Translation to search: "LUT" (Luther 1912), "SCH" (Schlachter 1951), "ELB" (Elberfelder 1871), "MB" (Menge 1939), "SLT" (Schlachter 2000). Default: "SLT" (Schlachter 2000). Aliases like "luther", "schlachter" accepted. Only editions this instance actually loaded can be requested; bible_server_info lists them.	SLT

Output Schema

ParametersJSON Schema

Name	Required	Description
`suche`	Yes
`verse`	Yes
`hinweis`	Yes
`quellen`	Yes
`treffer`	Yes	Number of matching VERSES, not of word occurrences: a verse can match several times.
`gekuerzt`	No
`verteilung`	No	Counted over all hits, not over the listed verses. Carries `buch` for a whole-Bible search and `kapitel` when restricted to one book. Take these numbers; do not derive them from the result list.
`uebersetzung`	Yes
`vorkommen_gesamt`	No	Number of word occurrences across all matching verses. Absent when the occurrences were not counted (see `hinweis`); do not estimate it in that case.

TDQS

A4.6/5.0

Behavior5/5

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

The description discloses rich behavioral traits beyond the readOnlyHint annotation: exact word matching, umlaut/accent folding ('fuhrt' matches 'führt'), phrase search, trailing-star prefix search, and optional book restriction. This gives the agent a thorough understanding of how the search behaves.

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?

Four sentences, each earning its place: purpose, syntax rules, use-case, and scope restriction. Information is front-loaded and free of redundancy. The structure flows naturally from what the tool does to how to use it.

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 (full-text search with syntax and translation options), the description covers key aspects: search semantics, use case, and book restriction. Output schema covers return values. A minor gap is the lack of mention of limit behavior or exclusions for sibling tools, but the description is largely 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%, giving the baseline 3. The description adds significant meaning: query syntax examples (e.g., 'Hirte mangeln', '"Gnade um Gnade"'), wildcard semantics, and translation edition details including aliases and instance availability. This enriches parameter 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 opens with 'Full-text search over the German Bible text', a specific verb and resource that clearly defines the tool's function. It further details search features (exact word forms, phrases, prefix wildcard) which distinguishes it from sibling tools like bible_lookup or bible_compare.

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?

Explicit guidance is given: 'Use this to locate a passage when the wording is known but the reference is not.' This states the intended scenario clearly, but it does not mention alternative tools or exclusions, so it falls short of a full comparison with siblings.

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

bible_server_infoA

Read-only

Inspect

Report this server's own release version and which Bible data it has loaded, including each edition's licence, required attribution and how many verses it may quote verbatim per call. Use when asked which version runs, when collecting facts for a bug report, and before planning a longer quotation. Returns no scripture — use bible_lookup for verse text.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`kanon`	No
`server`	Yes
`hinweis`	No
`version`	Yes
`ressourcen`	Yes
`daten_stand`	No	Date of the most recent source download, not a deployment date.
`zusatzdaten`	Yes
`uebersetzungen`	Yes
`voreinstellung`	Yes	Translation code used when a call omits `translation`.
`urtext_editionen`	Yes

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint, but the description adds meaningful behavioral color: it reports 'how many verses it may quote verbatim per call' and explicitly notes 'Returns no scripture.' This is non-obvious, useful context that exceeds the annotations without contradicting them.

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?

Three sentences with zero fluff. Front-loads the main purpose, follows with explicit use cases, and closes with an exclusion that clarifies scope. Every word earns its place.

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

Completeness5/5

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

For a 0-param info tool with no output schema, this description covers all bases: what it reports, when to use it, and what it does not do (return scripture). Nothing is left dangling.

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 tool has 0 parameters and the schema is empty, so per baseline 0 params = 4. The description clarifies what data the tool returns (version, licences, attribution) which helps set expectations even though no params need documenting.

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 'Report' and pins down the resource: server's release version, loaded Bible data, licence, attribution, and per-call quote limits. It differentiates from sibling bible_lookup by explicitly stating 'Returns no scripture — use bible_lookup for verse text,' which leaves no ambiguity about 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 states when to use ('when asked which version runs, when collecting facts for a bug report, and before planning a longer quotation') and names the alternative (bible_lookup) for the opposite case. The condition that selects this tool versus the sibling is crystal clear.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

1 tool updateSep 2, 2026
- Changedbible_crossrefs3 fields changed
  - addedOutput schema / properties / gekuerzt / properties / parallelen_entfallen
```
Added value: +{
+  "type": "integer"
+}
```
  - addedOutput schema / properties / gekuerzt / properties / parallelen_gezeigt
```
Added value: +{
+  "type": "integer"
+}
```
  - addedOutput schema / properties / gekuerzt / properties / parallelen_max
```
Added value: +{
+  "description": "Only when the parallel passages hit their own, smaller budget; the share of verse_max they may use at most.",
+  "type": "integer"
+}
```

2 tool updatesAug 22, 2026

Changedbible_crossrefs1 field changed

addedOutput schema / properties / parallelen

Added value: +{
+  "description": "Present only when the UBS Parallel Passage Database lists this verse. A group is an unordered set with no direction and no ranking, unlike `verweise`; a verse can belong to more than one group.",
+  "properties": {
+    "gruppen": {
+      "items": {
+        "properties": {
+          "stellen": {
+            "items": {
+              "properties": {
+                "locator": {
+                  "description": "The reference exactly as the UBS source writes it (USFM book code). In the Old Testament the source counts verses after the Hebrew Bible while this server follows its German editions; where the two differ, this string is authoritative and `stelle` is the resolved approximation.",
+                  "type": "string"
+                },
+                "sprache": {
+                  "type": "string"
+                },
+                "stelle": {
+                  "type": "string"
+                },
+                "text": {
+                  "description": "Absent once the verbatim quota reserved for parallels is used up, and absent when the verses are missing from this translation.",
+                  "type": "string"
+                },
+                "verse_einzeln": {
+                  "items": {
+                    "properties": {
+                      "nr": {
+                        "type": "integer"
+                      },
+                      "text": {
+                        "type": "string"
+                      }
+                    },
+                    "required": [
+                      "nr",
+                      "text"
+                    ],
+                    "type": "object"
+                  },
+                  "type": "array"
+                },
+                "zaehlung_abweichend": {
+                  "description": "Present and true only where the Hebrew text and the requested edition count this chapter differently, so `stelle` may be off by a verse or more. Absence is not a clearance: it also means the check could not run because the Hebrew text is not loaded.",
+                  "type": "boolean"
+                }
+              },
+              "required": [
+                "stelle",
+                "locator",
+                "sprache"
+              ],
+              "type": "object"
+            },
+            "type": "array"
+          }
+        },
+        "required": [
+          "stellen"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "stellen": {
+      "description": "Number of parallel places across all groups, the queried verse excluded.",
+      "type": "integer"
+    }
+  },
+  "required": [
+    "gruppen",
+    "stellen"
+  ],
+  "type": "object"
+}

Changedbible_server_info2 fields changed

addedOutput schema / properties / zusatzdaten / properties / parallelstellen
```
Added value: +{
+  "type": "boolean"
+}
```

changedOutput schema / properties / zusatzdaten / required

Previous value: -[
-  "strong_lexikon",
-  "strong_lexikon_vollstaendig",
-  "editionsbezeugung",
-  "querverweise",
-  "volltextsuche",
-  "fussnoten"
-]New value: +[
+  "strong_lexikon",
+  "strong_lexikon_vollstaendig",
+  "editionsbezeugung",
+  "querverweise",
+  "parallelstellen",
+  "volltextsuche",
+  "fussnoten"
+]

7 tool updatesAug 17, 2026
- First observedbible_compare
- First observedbible_concordance
- First observedbible_crossrefs
- First observedbible_lookup
- First observedbible_original
- First observedbible_search
- First observedbible_server_info

Frequently Asked Questions

Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.

Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
- GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
- HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
- DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.

The HTTP ownership file has this structure:

{
  "$schema": "https://glama.ai/mcp/schemas/connector.json",
  "claim": "glama_claim_..."
}

Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.

If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.

For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.

Discussions

No comments yet. Be the first to start the discussion!

Related MCP Connectors

Crossload A
org.crossload
Christliche Predigten und Bücher auf Deutsch: Volltextsuche, Transkripte, Bibellexikon
Search
51
DarashOAuth
pro.publifye
Bible research: 59 translations, Hebrew/Greek Strong's, morphology, cross-refs, 13 dictionaries
Research & Data Language Translation Search
1
orthotomeo A
io.github.jrainsberger
Read-only scripture-study engine: complete-or-fail concordance over Greek NT, Hebrew OT, LXX.
Search Research & Data Education & Learning Tools
122
bible-mcp A
io.github.nirajagarwal
Bible corpus MCP server: scripture, Greek/Hebrew interlinear data, cross-refs, semantic search.
Search Knowledge & Memory Open Data
1312

Related MCP Servers

biblical-linguistics-mcp
mpduarte
A
license
B
quality
D
maintenance
Provides Hebrew & Greek word study, full morphological parsing, cross-references, LXX alignment, and more from open-licensed data sources, usable by any MCP-compatible client.
Updated 5 months ago (2026-04-03 21:58 UTC)
9
MIT
SolaGuard MCP Server
Research & Data Documentation Access
jissac
A
license
A
quality
D
maintenance
Provides comprehensive Biblical research tools including scripture lookup, interlinear Greek/Hebrew data, and Strong's concordance within a Protestant theological framework. It enables AI applications to perform full-text biblical searches, topical studies, and cross-referencing using authoritative theological data.
Updated 8 months ago (2026-01-19 03:13 UTC)
4
MIT
bible-cli
Command Line Research & Data
Divine-Creative-Ministries
A
license
Not graded
quality
A
maintenance
Offline command-line toolkit for biblical study, allowing AI agents to access original-language texts, perform morphological searches, cross-references, and more, with all results traceable to queries.
Updated a month ago (2026-07-30 17:17 UTC)
24
3
MIT
Study Bible MCP Server
Education & Learning Tools Research & Data Knowledge & Memory
djayatillake
A
license
A
quality
C
maintenance
Enables deep Bible study through tools for original language lexicons, morphological analysis, cross-references, and contextual notes.
Updated 25 days ago (2026-08-13 13:45 UTC)
21
82
MIT

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0

Disambiguation4/5

The tools are mostly distinct: bible_lookup retrieves text by reference, bible_search finds by words, bible_original gives original-language detail, bible_compare compares Greek editions, bible_concordance does word studies, bible_crossrefs provides cross-references, and bible_server_info reports server data. There is slight potential for confusion between bible_original and bible_compare since both deal with original languages, but their purposes are clearly delineated.

Naming Consistency5/5

All tools follow a consistent 'bible_' prefix followed by a single descriptive verb (lookup, search, original, compare, concordance, crossrefs, server_info). The pattern is uniform and predictable, making it easy to infer tool purpose from the name alone.

Tool Count5/5

Seven tools is well-scoped for a Bible study server. Each tool covers a core function (looking up, searching, original text, comparison, concordance, cross-references, and server info) without redundancy, and the count is in the ideal range for maintainability and clarity.

Completeness4/5

The tool set appears comprehensive for typical Bible study needs: retrieval, search, original-language analysis, textual comparison, concordance, cross-references, and server metadata. Minor gaps exist, such as no direct tool for retrieving full chapter text or parallel reading across translations (though bible_lookup can retrieve multiple verses), and no support for OT textual comparison since only one edition exists; these are acceptable limitations.

Server Details

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Frequently Asked Questions

Discussions

Related MCP Connectors

Related MCP Servers

Glama MCP Gateway

Resources