A free, no-auth MCP server providing access to 35+ Bible versions across 9 language families (English, Portuguese, Spanish, Hebrew, Latin, French, Italian, Greek), enabling scripture lookup, search, and comparison without any API keys or signup.
get_verse – Fetch a specific verse or verse range by version, book, chapter, and verse number(s).
get_chapter – Retrieve a full Bible chapter with numbered verses for broader context.
get_passage – Look up scripture using natural-language references like "John 3:16-18" or "Psalm 23".
search_bible – Search for keywords or exact phrases within a version, with optional filtering by book or testament (returns up to 50 results).
compare_passage – View the same passage side-by-side across up to 8 Bible versions for translation study.
list_versions – Discover all available Bible translations, respecting any connection URL language/version filters.
list_books – Get all 66 canonical Bible books with localized names, abbreviations, testament grouping, and chapter counts, optionally filtered by testament or language.
You can also generate custom connection URLs to filter which versions and languages are exposed to the client.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Bible MCP show me John 3:16"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
🌐 English · Português (BR) · Español
Free, no-key Model Context Protocol server for the public Bible API. Read scripture across 35+ Bible versions in 9 language families from any MCP client — Claude, Cursor, and anything else that speaks MCP. Served from Cloudflare's edge. Powers mcp.midvash.com.
No API key, no auth, no signup. Just point your client at the URL.
HTTP Streamable transport (stateless JSON-RPC over POST).
Built on Cloudflare Workers + R2, backed by the same content as api.midvash.com.
Current MCP catalog: Portuguese, English, Spanish, Hebrew, Latin, French, Italian, Greek, and Portuguese (Portugal) versions.
Generate your personal connection URL at mcp.midvash.com and add it to your MCP client. URLs look like:
https://mcp.midvash.com/mcp/{id}?v=nvi,kjv&lang=pt-br,env — comma-separated version slugs to expose (optional; omit for all).
lang — comma-separated languages to expose (optional; omit for all).
Example (Claude Desktop / mcp.json):
{
"mcpServers": {
"bible": {
"url": "https://mcp.midvash.com/mcp/{id}?v=nvi,kjv&lang=pt-br,en"
}
}
}Related MCP server: bible-mcp
Tool | Description |
| Fetch a single verse or a verse range. |
| Fetch a full chapter. |
| Fetch a passage from a free-form reference (e.g. "John 3:16-18") — the most natural way to cite scripture. |
| Search the Bible text for words or an exact phrase, ranked by relevance (BM25) over an FTS5 index. Case- and accent-insensitive, optionally filtered by book or testament. |
| Compare the same passage across multiple Bible versions. |
| List available Bible versions/translations. |
| List the 66 books, optionally filtered by testament. |
| Search the study library — chapter commentaries, Bible characters, dictionary entries and theology articles — in 9 languages. |
| Fetch the commentary for the chapter a reference points to. All 1,189 chapters, in 9 languages. |
| Find other passages that relate to a verse, ranked by how widely the link is attested. 343,546 links. |
| Look up a word in Strong's lexicon by number ("H430") or by the word itself. 14,197 entries, definitions in 9 languages. |
Study tools return a summary of up to 500 characters plus a link to the full
article on midvash.com.
Beyond tools, the server exposes Resources — bible://{version}/{book}/{chapter}
addresses the text directly — and four study Prompts: sermon preparation, a
devotional, a word study, and a translation comparison. Book and version
arguments support autocompletion.
Tools that return data also return structuredContent alongside the Markdown,
so a client does not have to parse formatted text.
The server is public and unauthenticated, so every request is metered:
Limit | Value |
Tool calls per IP | 60 per minute |
JSON-RPC batch size | 5 messages |
Aggregate tool calls | 1,200 per minute per Cloudflare location |
A batch costs one unit per tools/call, so batching cannot raise the per-IP
ceiling. Tool responses are deterministic and public, so they are cached at the
edge for 24 hours — a repeated call costs nothing and returns in a fraction of
the time.
The MCP currently exposes the version catalog compiled in
src/data/versions.ts: 35 versions across the
language codes pt-br, en, es, he, la, fr, it, gr, and pt-pt.
The public URL can narrow that catalog per connection:
https://mcp.midvash.com/mcp/{id}?v=nvi,kjv&lang=pt-br,enStore | Contents |
R2 bucket | Chapter text, |
D1 | FTS5 index: 1,224,921 verses and 18,792 study documents |
The D1 database belongs to this MCP alone. It is a copy, rebuilt by
scripts/seed-mcp-search.sh, and the Worker
only ever reads from it. Keeping it separate means the Cloudflare dashboard
reports this server's usage on its own, and a D1 binding — which grants access
to an entire database — reaches nothing but public Bible content.
Search is ranked per version. The five Hebrew texts (WLC, BHS, ALEPPO, MH,
OSMH) are the exception: SQLite's tokenizer does not strip Hebrew vowel points,
so those versions are scanned per book instead of ranked, and search_bible
asks for a book filter when one of them is used.
The Bible MCP landscape has three useful patterns:
Server | Strengths | What Midvash should learn from it |
Remote-capable lookup, search, navigation, multiple translations, Apocrypha. | Add first-class Bible search and richer navigation helpers. | |
Multi-version lookup, keyword/semantic search, cross-references, word studies, original-language lexicon data. | Add semantic/keyword search, cross-references, and optional study layers. | |
Lexicons, morphology, cross-references, contextual notes, deeper study workflow. | Keep Midvash simple by default, but expose advanced study tools when data is available. | |
Strong Chinese Bible study resources, commentaries, original-language analysis, Apocrypha, topical studies. | Treat language communities as first-class audiences, not just translation filters. |
Midvash's edge is simplicity: remote, no key, no account, fast Cloudflare delivery, and an open ecosystem around the reader, API, apps, plugins, and data. The next improvements should preserve that low-friction experience while adding the discovery and study tools users expect from Bible-focused MCP servers.
Expand the MCP catalog to match the broader Midvash data/API coverage.
Extend the search index to the remaining versions and to the Hebrew, Greek, and Latin texts, which still fall back to a book-scoped scan.
Improve compare_passage with richer formatting for long passages.
Add cross-reference tools powered by
bible-cross-references.
Add study-oriented tools for original-language, lexicon, and morphology data where reliable open data is available.
Add automated tests for reference parsing, catalog filters, and tool calls.
npm install
npm run dev # wrangler dev (local)
npm run typecheck # tsc --noEmitDeploys to the Cloudflare Worker midvash-mcp (custom domain
mcp.midvash.com) via GitHub Actions (.github/workflows/deploy.yml) —
every push to main is type-checked and deployed automatically. Requires the
repository secrets CLOUDFLARE_API_TOKEN and CLOUDFLARE_ACCOUNT_ID. Manual
deploy:
npm run deploy # npx wrangler deployMIT © Midvash
Part of Midvash — a free Bible reading & study platform. Everything is open and interlinks:
📖 Reader (web) | midvash.com — 9 languages |
📱 iOS app | |
🔌 API | |
🤖 MCP server | |
🧩 WordPress plugin | |
🧩 EmDash plugin | |
🌐 Chrome extension | |
📦 Open data |
Free & open, built by Midvash · midvash.com · midvash.app
Compares the same Bible passage across multiple Bible versions and returns a Markdown side-by-side style comparison. Use this for translation comparison, sermon preparation, or study questions. For a single version, use get_passage.
| Name | Required | Description | Default |
|---|---|---|---|
| versions | No | Optional list of Bible version slugs to compare. If omitted, uses versions enabled by the connection URL, or a small default set. Maximum 8 versions. | |
| reference | Yes | Free-form Bible reference to compare. Accepts supported localized book names, abbreviations, whole chapters, and verse ranges. Examples: "John 3:16", "João 3:16-18", "Psalm 23". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false, indicating safe, idempotent behavior. The description adds transparency by specifying the output format (Markdown) and default version behavior. It is consistent with annotations and provides useful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at three sentences, front-loaded with the primary purpose, and contains no filler or redundant information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description specifies the return format (Markdown comparison). It also distinguishes from 6 sibling tools. The tool's behavior is fully covered: what it does, when to use, parameter constraints, and result format. Complete for a comparison tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters have descriptions in the schema (100% coverage). The description adds extra semantic info: for 'versions', it explains the default behavior (connection URL or small set) and the maximum of 8. This goes beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it compares the same Bible passage across multiple versions and returns a Markdown side-by-side comparison. It also explicitly distinguishes from sibling tool get_passage: 'For a single version, use get_passage.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases (translation comparison, sermon preparation, study questions) and clearly states when not to use it (single version -> get_passage). It also mentions the maximum of 8 versions, guiding proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches a full Bible chapter from a specific version, formatted in Markdown with numbered verses. Use this when the user needs chapter-level context instead of an isolated verse.
| Name | Required | Description | Default |
|---|---|---|---|
| book | Yes | Bible book name, slug, or abbreviation. Accepts supported localized names such as "John", "João", "Salmos", or "1 Sm". | |
| chapter | Yes | Chapter number within the selected book. Must be 1 or greater. | |
| version | Yes | Bible version slug to read from, such as "nvi", "kjv", "ara", or "rvr1960". Must be enabled by the connection URL filters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the agent knows it's a safe read. The description adds that output is formatted in Markdown with numbered verses, providing 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states what the tool does, second gives usage guidance. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with three fully described parameters, the description is complete. It explains the output format (Markdown with numbered verses) and usage context. No output schema is needed given the clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a description. The tool description does not add extra parameter semantics beyond what the schema 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a full Bible chapter from a specific version, and distinguishes it from get_verse by noting it provides chapter-level context rather than an isolated verse. This is a specific verb+resource pair that differentiates from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when the user needs chapter-level context instead of an isolated verse,' providing clear guidance for when to use. It implies not to use for isolated verses (use get_verse) but does not mention other siblings like get_passage for ranges.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches a Bible passage from a natural-language reference such as "John 3:16-18", "João 3:16", "Romans 8:1-11", or "Psalm 23". This is the primary lookup tool when the user gives a citation instead of structured book/chapter/verse fields.
| Name | Required | Description | Default |
|---|---|---|---|
| version | No | Optional Bible version slug. If omitted, uses the first version enabled by the connection URL, or "nvi" when no version filter exists. | |
| reference | Yes | Free-form Bible reference. Accepts supported localized book names, abbreviations, numeric prefixes, whole chapters, and verse ranges. Examples: "John 3:16", "1 Coríntios 13", "Sl 23:1-6". |
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 that the tool fetches a passage from a natural-language reference, consistent with annotations but not providing additional behavioral details beyond the safe read nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place. First sentence states action and examples, second sentence clarifies when to use. No superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only 2 parameters, 100% schema coverage, and helpful annotations (readOnlyHint, idempotentHint, destructiveHint), the description is complete. It explains the tool's role among siblings and handles input format adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but description adds value by providing natural-language example inputs and explaining default behavior for the optional 'version' parameter. The 'reference' parameter description includes acceptable formats beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Fetches' with resource 'Bible passage', gives concrete examples, and explicitly distinguishes from structured-field tools. Sibling tools like get_chapter and get_verse further clarify scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States this is 'the primary lookup tool when the user gives a citation', providing clear context for when to use it. Does not explicitly exclude other tools but implies the alternative (structured fields) and mentions other tools like search_bible exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches one exact Bible verse or a contiguous verse range from a specific version. Use this when the book, chapter, verse, and version are already known. For natural references such as "John 3:16-18", prefer get_passage.
| Name | Required | Description | Default |
|---|---|---|---|
| book | Yes | Bible book name, slug, or abbreviation. Accepts supported localized names such as "John", "João", "Salmos", or "1 Sm". | |
| verse | Yes | Starting verse number. Must exist in the selected chapter. | |
| chapter | Yes | Chapter number within the selected book. Must be 1 or greater. | |
| version | Yes | Bible version slug to read from, such as "nvi", "kjv", "ara", or "rvr1960". Must be enabled by the connection URL filters. | |
| verse_end | No | Optional ending verse number for a range. Must be greater than or equal to verse and within the same chapter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral context by specifying it fetches exact verse/range and is idempotent, consistent 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each essential: first defines action, second provides usage guidance. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Schema covers all parameters, annotations cover safety, and description adds purpose and alternatives. For a simple fetch tool, this is sufficient; no output schema needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The tool description does not add significant meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches one exact verse or contiguous range from a specific version. It differentiates from sibling get_passage by specifying it's for when book, chapter, verse, and version are already known.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (book, chapter, verse, version known) and when to use alternative (natural references like 'John 3:16-18' prefer get_passage).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the 66 canonical Bible books with localized names, slugs, abbreviations, testament grouping, and chapter counts. Use this when an agent needs valid book identifiers or localized display names before calling lookup tools.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Optional locale for book names, slugs, and abbreviations. Supported values: en, pt-br, es, fr, de, it, zh, ru, ko. Defaults to en. | |
| testament | No | Optional testament filter. Use "old" for Old Testament books or "new" for New Testament books. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the agent knows it's safe. The description adds context that it returns 66 canonical books and specific fields (names, slugs, etc.), which is 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first describes what the tool does, second gives usage guidance. No unnecessary words, front-loaded with key information. Every sentence is essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two optional parameters and no output schema, the description is complete. It explains the returned fields and the tool's role in the workflow (providing identifiers before lookups). The annotations cover safety and idempotency, so no additional behavioral context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining that 'language' affects localization of names, slugs, and abbreviations, and 'testament' allows filtering, reinforcing the purpose of the parameters beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Lists' and the resource '66 canonical Bible books'. It specifies the returned data: localized names, slugs, abbreviations, testament grouping, and chapter counts. It also distinguishes from sibling lookup tools by saying 'before calling lookup tools'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this when an agent needs valid book identifiers or localized display names before calling lookup tools.' This indicates when to use. Although it doesn't explicitly state when not to use, the context of sibling tools like get_chapter and search_bible implies the tool is for enumeration and identifier retrieval, not direct lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists Bible versions available to the current MCP connection, automatically respecting URL filters such as ?v=nvi,kjv and ?lang=pt-br,en. Use this before lookup, search, or comparison when the user has not specified a version.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Optional language filter for version metadata. Examples: "pt-br", "pt", "en", "es", "he", "la", "fr", "it", "gr". The value "pt" includes pt-br and pt-pt. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent. Description adds context about automatic URL filtering, providing additional behavioral 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first explains function and behavior, the second gives usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and good annotations, the description is complete: purpose, filtering behavior, and usage context are all covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear description of the 'language' parameter. Description does not add new parameter information but references URL filters, not specific parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists available Bible versions, with specific behavior about respecting URL filters. It distinguishes from sibling tools like lookup, search, or comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use before lookup, search, or comparison when version is not specified. Provides clear context, though does not explicitly mention when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches for a keyword or exact phrase in one Bible version and returns matching verse references in Markdown. Use this for discovery questions like "find verses about love in KJV". For direct citation lookup, use get_passage or get_verse.
| Name | Required | Description | Default |
|---|---|---|---|
| book | No | Optional book name, slug, or abbreviation in any supported book locale (ex.: "John", "João", "Salmos"). | |
| limit | No | Maximum number of matches to return. Default: 20; max: 50. | |
| query | Yes | Keyword or exact phrase to search for. Matching is case-insensitive and accent-insensitive; it is not semantic search. | |
| version | Yes | Single Bible version slug to search, such as "nvi", "kjv", "ara", or "rvr1960". Must be enabled by the connection URL filters. | |
| testament | No | Optional testament filter. Use "old" for Old Testament or "new" for New Testament. Ignored when book is provided. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds information about the output format (Markdown) and the nature of matching (case-insensitive, accent-insensitive). It does not disclose other behaviors like rate limits, but the safety profile is covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no unnecessary words. The first sentence states purpose and output format; the second gives usage guidance and sibling differentiation. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Considering the tool has 5 parameters and no output schema, the description does a good job explaining purpose and usage guidance. It could be more specific about what a verse reference includes (e.g., book chapter:verse), but sibling tools and schema descriptions round out the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes all parameters. The tool description adds minimal extra meaning beyond saying 'keyword or exact phrase' which is already in the query description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for a keyword or exact phrase in one Bible version and returns matching verse references in Markdown. It distinguishes from sibling tools like get_passage and get_verse by specifying it is for discovery, not direct citation lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use: 'Use this for discovery questions like...' and when not to: 'For direct citation lookup, use get_passage or get_verse.' This gives clear guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.1.0compare_passageget_chapterget_passageget_verselist_bookslist_versionssearch_bibleEach tool has a clearly distinct purpose: compare_passage compares multiple versions, get_chapter retrieves a full chapter, get_passage handles natural-language references, get_verse requires structured fields, list_books and list_versions provide metadata, and search_bible performs keyword search. No overlapping functionality.
All tools follow a consistent verb_noun pattern in snake_case: compare_passage, get_chapter, get_passage, get_verse, list_books, list_versions, search_bible. Naming is uniform and predictable.
With 7 tools, the server is well-scoped for Bible study—covering lookup, comparison, listing, and search. The count is neither too sparse (causing gaps) nor excessive (leading to confusion), and each tool earns its place.
The tool set fully covers the core domain: discovering books and versions, retrieving passages by reference (verse, chapter, or natural language), comparing translations, and searching. No obvious gaps for typical Bible study workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Bible MCP — wraps the Bible API (free, no auth)
Bible corpus MCP server: scripture, Greek/Hebrew interlinear data, cross-refs, semantic search.
Free, open MCP server for The Urantia Papers. 197 papers, 14,500+ paragraphs, 4,400+ entities.
MCP server for Project Gutenberg — 75,000+ public-domain ebooks with full plain-text retrieval.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/midvash/bible-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
