This MCP server provides comprehensive access to the Korean Bible with tools for retrieving, searching, and comparing biblical content across multiple translations.
Core Features:
Retrieve chapters and verses: Get complete chapters or specific verses/ranges using flexible book identification (English names, Korean names, or book codes)
Search biblical content: Find verses containing specific keywords in Korean or English
Compare translations: Analyze verses across five Korean Bible versions (GAE, GAE1, NIR, KOR, CEV) with GAE as default
Browse books: List all Bible books with optional Old Testament/New Testament filtering
Key Benefits:
Supports multiple Korean Bible translations
Flexible input methods for book identification
Keyword search in both Korean and English
Cross-translation comparison capabilities
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 Korean MCP Server show me John 3:16 in Korean"
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.
MCP (Model Context Protocol) server for accessing the Korean Bible from bskorea.or.kr.
Features:
β‘οΈ In-memory caching with 30-min TTL for fast repeated requests
π Automatic retry with exponential backoff (3 retries, 1sβ2sβ4s) for transient failures
π‘οΈ Robust error handling with try/catch and graceful fallbacks
β Input validation with Zod schemas
π₯ Health check tool for monitoring
π All 66 books with 5 translations supported
π Full-text search across entire Bible
Requires Node.js 20+
Related MCP server: biblebridge-mcp
This MCP server provides tools to:
Get complete chapters from the Korean Bible
Retrieve specific verses or verse ranges
Search for verses containing keywords
List all available books
Compare verses across different Korean translations
The same Korean Bible access is also packaged as a Claude Skill under
skill/ β a token-frugal alternative to the always-on MCP server. A
skill loads into the agent's context only when invoked and shells out to a small
zero-dependency Python CLI, so it costs nothing while idle. Use the MCP server
in MCP clients (Claude Desktop, TypingMind); use the skill in coding agents
(Claude Code, etc.) that already have shell access.
chmod +x skill/bin/bible && export PATH="$PWD/skill/bin:$PATH"
bible verses John 3 16
bible compare John 3 16See skill/README.md for install and the MCP-vs-skill
trade-off. (The industry is steadily shifting routine API access from always-on
MCP servers toward on-demand skills β this repo ships both.)
Install globally via npm:
npm install -g bible-ko-mcpOr use directly with npx (no installation required):
npx -y bible-ko-mcpget-chapterGet all verses from a specific chapter.
Parameters:
book (string, required): Book name in English, Korean, or book code
Examples: "Genesis", "μ°½μΈκΈ°", "gen"
chapter (number, required): Chapter number
version (string, optional): Bible translation version (default: "GAE")
Options: "GAE", "GAE1", "NIR", "KOR", "CEV"
Example:
{
"book": "Genesis",
"chapter": 1,
"version": "GAE"
}get-versesGet specific verse(s) from a chapter.
Parameters:
book (string, required): Book name or code
chapter (number, required): Chapter number
verseStart (number, required): Starting verse number
verseEnd (number, optional): Ending verse number (defaults to verseStart)
version (string, optional): Bible translation version (default: "GAE")
Example:
{
"book": "John",
"chapter": 3,
"verseStart": 16,
"verseEnd": 17,
"version": "GAE"
}search-bibleSearch for verses containing specific keywords.
Parameters:
query (string, required): Search query in Korean or English
version (string, optional): Bible translation version (default: "GAE")
Note: Search covers all 66 books of the Bible with fallback results.
Example:
{
"query": "μ¬λ",
"version": "GAE"
}list-booksList all available books in the Bible.
Parameters:
testament (string, optional): Filter by testament ("OT" or "NT")
Example:
{
"testament": "NT"
}compare-translationsCompare a verse across different Korean translations.
Parameters:
book (string, required): Book name or code
chapter (number, required): Chapter number
verse (number, required): Verse number
versions (array, optional): Array of version codes to compare (default: all versions)
Example:
{
"book": "John",
"chapter": 3,
"verse": 16,
"versions": ["GAE", "NIR", "KOR"]
}GAE: κ°μκ°μ (Revised Korean Standard Version)
GAE1: κ°μνκΈ (Korean Revised Version)
NIR: μλ²μμ±κ²½ (New Korean Revised Version)
KOR: 곡λλ²μ (Common Translation)
CEV: CEV (Contemporary English Version)
Genesis (μ°½μΈκΈ°): gen
Exodus (μΆμ κ΅½κΈ°): exo
Leviticus (λ μκΈ°): lev
Numbers (λ―ΌμκΈ°): num
Deuteronomy (μ λͺ
κΈ°): deu
... (see full list in source code)
Matthew (λ§ν볡μ): mat
Mark (λ§κ°λ³΅μ): mrk
Luke (λκ°λ³΅μ): luk
John (μν볡μ): jhn
Acts (μ¬λνμ ): act
... (see full list in source code)
Add to your Claude Desktop configuration:
Edit ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"bible-ko": {
"command": "npx",
"args": [
"-y",
"bible-ko-mcp"
]
}
}
}Edit %APPDATA%\Claude\claude_desktop_config.json with the same configuration above.
After adding the configuration, restart Claude Desktop completely.
For local development:
# Clone the repository
git clone https://github.com/oksure/bible-ko-mcp.git
cd bible-ko-mcp
# Install dependencies
npm install
# Build
npm run build
# Run tests
npm test
# Watch mode (auto-rebuild on changes)
npm run watch
# Run locally
npm startFor testing local changes, use this configuration:
{
"mcpServers": {
"bible-ko": {
"command": "node",
"args": [
"/absolute/path/to/bible-ko-mcp/build/index.js"
]
}
}
}Remember to run npm run build after making changes.
Built with TypeScript and the MCP SDK
Uses cheerio for HTML parsing
Fetches data from bskorea.or.kr with automatic retry (exponential backoff) on transient failures
In-memory cache (30-min TTL, 2000 entries) avoids redundant requests
Supports all 66 books of the Bible
Handles Korean and English book names
Weekly Sunday sermon with the Beatitudes
Ask Claude: "Give me Matthew 5:3-12 in Korean (GAE) with each beatitude on a separate line for my sermon outline."
Tool: get-verses
Book: Matthew, Chapter: 5, Start: 3, End: 12Good Friday β Messianic prophecy from Isaiah
Tool: get-chapter
Book: Isaiah, Chapter: 53, Version: GAEChristmas Eve sermon β The nativity narrative
Tool: get-verses
Book: Luke, Chapter: 2, Start: 1, End: 20Easter Sunday β The resurrection account
Tool: get-chapter
Book: John, Chapter: 20, Version: GAEWedding homily β The Love Chapter
Tool: get-chapter
Book: 1 Corinthians, Chapter: 13, Version: GAEMissions Sunday β The Great Commission
Tool: get-verses
Book: Matthew, Chapter: 28, Start: 18, End: 20Comparing John 3:16 across translations for group discussion
Tool: compare-translations
Book: John, Chapter: 3, Verse: 16
Versions: ["GAE", "GAE1", "NIR", "KOR"]Topical study: Living Faith (μΌκ³ 보μμ λ―Ώμ)
Tool: get-verses
Book: James, Chapter: 2, Start: 14, End: 26Fruit of the Spirit study
Tool: get-verses
Book: Galatians, Chapter: 5, Start: 22, End: 23Hebrews 11 "Faith Hall of Fame" β full chapter
Tool: get-chapter
Book: Hebrews, Chapter: 11, Version: GAESpiritual warfare β full armor of God passage
Tool: get-verses
Book: Ephesians, Chapter: 6, Start: 10, End: 18Psalm 23 for comfort (funeral message, hospital visits)
Tool: get-chapter
Book: Psalms, Chapter: 23, Version: GAERomans 8:28-39 β Assurance of God's love
Tool: get-verses
Book: Romans, Chapter: 8, Start: 28, End: 39Daily scripture memory verse
Tool: get-verses
Book: Philippians, Chapter: 4, Start: 13, End: 13Advent devotional β The Word became flesh
Tool: get-verses
Book: John, Chapter: 1, Start: 1, End: 14All tools accept Korean book names, making it natural to reference Scripture in Korean:
Tool: get-chapter
Book: μνΈ (Psalms), Chapter: 23Tool: get-verses
Book: μ μΈ (Proverbs), Chapter: 3, Start: 5, End: 6Tool: search-bible
Query: νλλμ μ¬λ (God's love)The HTML parsing may need adjustment based on website updates
Search functionality is limited for demo purposes to avoid excessive requests
Some translations may not be available for all books
This package is automatically published to NPM when a new GitHub release is created. See PUBLISHING.md for detailed instructions.
Contributions are welcome! Please feel free to submit a Pull Request.
MIT
Compare a verse across different Korean translations
| Name | Required | Description | Default |
|---|---|---|---|
| book | Yes | Book name (English or Korean) or code (e.g., 'Genesis', 'μ°½μΈκΈ°', 'gen') | |
| verse | Yes | Verse number | |
| chapter | Yes | Chapter number | |
| versions | No | Array of version codes to compare (default: all versions) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the basic function without disclosing any behavioral traits (e.g., read-only, no side effects, auth requirements). The description is too brief for a tool with no 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?
Single sentence, front-loaded, and no wasted words. However, it is slightly under-specified given lack of annotations; could include more useful context without becoming verbose.
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?
With no output schema, the description should explain what the tool returns (e.g., comparison format, translations listed). It only says 'compare', leaving the agent to guess the return structure and behavior. Incomplete for a tool with 4 parameters.
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 input schema already documents all parameters. The description adds no additional meaning beyond 'compare verse across translations'. Baseline 3 is appropriate as schema does the heavy lifting.
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 'Compare a verse across different Korean translations', which is specific about the verb (compare), resource (verse), and scope (Korean translations). It effectively distinguishes from sibling tools like 'get-chapter' or 'get-verses'.
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 implies usage context (when you need to compare translations of a specific verse) but does not explicitly state when not to use it or mention alternatives. The sibling tool names provide context, but no direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all verses from a specific chapter of the Korean Bible
| Name | Required | Description | Default |
|---|---|---|---|
| book | Yes | Book name (English or Korean) or code (e.g., 'Genesis', 'μ°½μΈκΈ°', 'gen') | |
| chapter | Yes | Chapter number | |
| version | No | Bible translation version (default: GAE) | GAE |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the basic retrieval action, omitting details about read-only nature, output format, or any constraints.
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 a single, clear sentence with no unnecessary words or repetition. It is 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?
The description covers the core functionality but lacks context about output format, edge cases, or integration with sibling tools. Given the tool's simplicity, it is mostly complete but could be improved.
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 no additional meaning beyond the schema, simply restating the purpose.
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 'Get' and resource 'all verses from a specific chapter of the Korean Bible', distinguishing it from sibling tools like get-verses (probably individual verses) and search-bible.
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 does not provide explicit guidance on when to use this tool versus alternatives like get-verses or compare-translations. Usage context is implied but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get specific verse(s) from a chapter
| Name | Required | Description | Default |
|---|---|---|---|
| book | Yes | Book name (English or Korean) or code (e.g., 'Genesis', 'μ°½μΈκΈ°', 'gen') | |
| chapter | Yes | Chapter number | |
| version | No | Bible translation version (default: GAE) | GAE |
| verseEnd | No | Ending verse number (optional, defaults to verseStart) | |
| verseStart | Yes | Starting verse number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It fails to mention any behavioral aspects such as read-only nature, error handling, or what happens if verses are missing.
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 a single, brief sentence that gets straight to the point. It is concise, but could benefit from a bit more context without becoming verbose.
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?
The description covers the tool's core purpose but lacks detail on output format, authentication needs, rate limits, or usage scenarios. Given the moderate complexity (5 parameters, 1 enum), more context would help the agent.
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%, meaning the input schema already details each parameter well. The description adds no additional meaning beyond 'specific verse(s)', which is accurate but not enhancing.
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 uses a specific verb ('Get') and resource ('specific verse(s) from a chapter'), making the tool's purpose immediately clear. It distinguishes from sibling 'get-chapter' which retrieves an entire chapter, and 'search-bible' which is for searching.
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?
No guidance is provided on when to use this tool versus alternatives like 'get-chapter' for whole chapters or 'search-bible' for searches. The context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the health status of the Bible Korean MCP server and API connectivity
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It mentions checking health and connectivity but does not describe output format or whether authentication is needed. For a simple tool, this is acceptable but lacks detail.
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?
Single sentence, front-loaded with the action. No extraneous content.
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 health check tool with no parameters and no output schema, the description is sufficiently complete. It conveys purpose and scope, though it omits output details.
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?
No parameters exist; schema coverage is 100%. The description adds no parameter info, which is not needed. Baseline for 0 params is 4.
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 checks health status and API connectivity, a specific verb+resource. It is easily distinguished from siblings which perform Bible data operations.
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?
Implicitly, the tool is for verifying server health before other operations, but no explicit when-to-use or exclusions are provided. For a simple health check, this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available books in the Bible
| Name | Required | Description | Default |
|---|---|---|---|
| testament | No | Filter by testament (OT/NT, optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It does not disclose read-only nature or any side effects, but it is safe for a list operation. Minimal disclosure.
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 a single sentence with no wasted words, but it is minimally informative. Consider adding context about the return format.
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 with one optional parameter, the description is adequate but does not explain return values or behavior when no filter is applied. Slightly incomplete.
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% for the single parameter, but the description adds no additional information beyond what the schema provides. 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 verb 'list' and the resource 'all available books in the Bible', distinguishing it from sibling tools like get-chapter or search-bible.
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 implies usage for listing books but lacks explicit guidance on when to use this tool versus alternatives, such as search-bible or get-verses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for verses containing specific keywords. Searches the first 10 chapters of each book β not a full-Bible search.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (Korean or English) | |
| version | No | Bible translation version (default: GAE) | GAE |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides the key behavioral limitation (not full-Bible search). It adds value beyond schema by disclosing the restricted scope, but does not address other traits like read-only nature or authentication needs.
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 extremely concise with two sentences, each adding distinct value: first states core action, second clarifies critical scope limitation. 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?
The description covers the tool's purpose and limitation but lacks any mention of output format or return value. Since there is no output schema, this gap reduces completeness for an AI agent.
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?
The input schema already fully describes both parameters (query and version) with descriptions and enums. The description adds no additional semantic information about parameters beyond what the schema provides.
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 uses a specific verb ('Search') and resource ('verses containing specific keywords') and clearly distinguishes the tool by stating the limitation (first 10 chapters only), separating it from siblings like get-chapter or get-verses.
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?
It explicitly states the scope (first 10 chapters) and implies this is for quick keyword searches, not a full-Bible search. However, it does not explicitly mention when to use alternatives like get-verses or compare-translations.
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.
v0.2.0compare-translations3 fields changedInput schema / properties / book / descriptionPrevious value: -"Book name (English or Korean) or code"New value: +"Book name (English or Korean) or code (e.g., 'Genesis', 'μ°½μΈκΈ°', 'gen')"Input schema / properties / chapter / minimumAdded value: +1Input schema / properties / verse / minimumAdded value: +1get-chapter1 field changedInput schema / properties / chapter / minimumAdded value: +1get-verses4 fields changedInput schema / properties / book / descriptionPrevious value: -"Book name (English or Korean) or code"New value: +"Book name (English or Korean) or code (e.g., 'Genesis', 'μ°½μΈκΈ°', 'gen')"Input schema / properties / chapter / minimumAdded value: +1Input schema / properties / verseEnd / minimumAdded value: +1Input schema / properties / verseStart / minimumAdded value: +1health-checkcompare-translationsget-chapterget-verseslist-bookssearch-bibleScored across 6 tools
Each tool has a clearly distinct purpose: compare-translations for cross-translation comparison, get-chapter for full chapters, get-verses for specific verses, health-check for server status, list-books for book listing, and search-bible for keyword search. No overlap.
Tool names follow a consistent pattern of lowercase hyphenated verb-noun (compare-translations, get-chapter, get-verses, list-books, search-bible), though health-check is a noun-noun compound, deviating slightly but still readable.
With 6 tools, the server is well-scoped for its domain, covering reading, searching, and comparison without being overly numerous or too sparse.
Core operations are covered (list books, get chapter/verses, search, compare), but notable gaps exist: no tool to list available translations, and the search is limited to the first 10 chapters of each book, which may hinder full-text discovery.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Bible translations, books, chapters, verses, and search
Scripture-cited answers to any Bible question, plus verse text and study pages, for AI agents.
Bible corpus MCP server: scripture, Greek/Hebrew interlinear data, cross-refs, semantic search.
Bible MCP β wraps the Bible API (free, no auth)
