bskorea.or.kr의 한국어 성경에 접근하기 위한 MCP(Model Context Protocol) 서버입니다.
주요 기능:
⚡️ 인메모리 캐싱: 30분 TTL을 적용하여 반복적인 요청을 빠르게 처리
🔄 자동 재시도: 일시적인 오류 발생 시 지수 백오프(3회 재시도, 1초→2초→4초) 적용
🛡️ 강력한 오류 처리: try/catch 및 우아한 폴백(fallback) 처리
✅ 입력 검증: Zod 스키마를 통한 입력값 검증
🏥 상태 확인: 모니터링을 위한 헬스 체크 도구
📚 전체 66권: 5가지 번역본 지원
🔍 전체 텍스트 검색: 성경 전체 검색 기능
**Node.js 20+**가 필요합니다.
Related MCP server: biblebridge-mcp
이 MCP 서버는 다음과 같은 도구를 제공합니다:
한국어 성경의 전체 장 가져오기
특정 절 또는 절 범위 가져오기
키워드가 포함된 절 검색
사용 가능한 모든 성경 목록 확인
다양한 한국어 번역본 간의 절 비교
npm을 통해 전역으로 설치:
npm install -g bible-ko-mcp또는 npx를 통해 직접 사용 (설치 불필요):
npx -y bible-ko-mcpget-chapter특정 장의 모든 절을 가져옵니다.
매개변수:
book (문자열, 필수): 영어, 한국어 또는 성경 코드 형식의 책 이름
예시: "Genesis", "창세기", "gen"
chapter (숫자, 필수): 장 번호
version (문자열, 선택): 성경 번역 버전 (기본값: "GAE")
옵션: "GAE", "GAE1", "NIR", "KOR", "CEV"
예시:
{
"book": "Genesis",
"chapter": 1,
"version": "GAE"
}get-verses특정 장에서 특정 절(들)을 가져옵니다.
매개변수:
book (문자열, 필수): 책 이름 또는 코드
chapter (숫자, 필수): 장 번호
verseStart (숫자, 필수): 시작 절 번호
verseEnd (숫자, 선택): 끝 절 번호 (기본값: verseStart)
version (문자열, 선택): 성경 번역 버전 (기본값: "GAE")
예시:
{
"book": "John",
"chapter": 3,
"verseStart": 16,
"verseEnd": 17,
"version": "GAE"
}search-bible특정 키워드가 포함된 절을 검색합니다.
매개변수:
query (문자열, 필수): 한국어 또는 영어 검색어
version (문자열, 선택): 성경 번역 버전 (기본값: "GAE")
참고: 검색은 성경 66권 전체를 대상으로 하며 폴백 결과를 포함합니다.
예시:
{
"query": "사랑",
"version": "GAE"
}list-books성경의 모든 책 목록을 나열합니다.
매개변수:
testament (문자열, 선택): 성경 구분 필터 ("OT" 또는 "NT")
예시:
{
"testament": "NT"
}compare-translations다양한 한국어 번역본 간의 절을 비교합니다.
매개변수:
book (문자열, 필수): 책 이름 또는 코드
chapter (숫자, 필수): 장 번호
verse (숫자, 필수): 절 번호
versions (배열, 선택): 비교할 버전 코드 배열 (기본값: 모든 버전)
예시:
{
"book": "John",
"chapter": 3,
"verse": 16,
"versions": ["GAE", "NIR", "KOR"]
}GAE: 개역개정
GAE1: 개역한글
NIR: 새번역성경
KOR: 공동번역
CEV: CEV (현대어 영어 성경)
Genesis (창세기): gen
Exodus (출애굽기): exo
Leviticus (레위기): lev
Numbers (민수기): num
Deuteronomy (신명기): deu
... (소스 코드에서 전체 목록 확인)
Matthew (마태복음): mat
Mark (마가복음): mrk
Luke (누가복음): luk
John (요한복음): jhn
Acts (사도행전): act
... (소스 코드에서 전체 목록 확인)
Claude Desktop 설정에 추가하세요:
~/Library/Application Support/Claude/claude_desktop_config.json 파일을 편집하세요:
{
"mcpServers": {
"bible-ko": {
"command": "npx",
"args": [
"-y",
"bible-ko-mcp"
]
}
}
}%APPDATA%\Claude\claude_desktop_config.json 파일을 위와 동일한 설정으로 편집하세요.
설정을 추가한 후 Claude Desktop을 완전히 재시작하세요.
로컬 개발을 위한 방법:
# 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 start로컬 변경 사항을 테스트하려면 다음 설정을 사용하세요:
{
"mcpServers": {
"bible-ko": {
"command": "node",
"args": [
"/absolute/path/to/bible-ko-mcp/build/index.js"
]
}
}
}변경 사항을 적용한 후에는 반드시 npm run build를 실행하세요.
TypeScript 및 MCP SDK로 구축
HTML 파싱을 위해 cheerio 사용
일시적인 오류 발생 시 자동 재시도(지수 백오프)를 통해 bskorea.or.kr에서 데이터 가져오기
인메모리 캐시(30분 TTL, 2000개 항목)를 통해 중복 요청 방지
성경 66권 전체 지원
한국어 및 영어 책 이름 처리
팔복에 관한 주일 설교
Claude에게 요청: "설교 개요를 위해 마태복음 5장 3-12절을 한국어(GAE)로 가져와서 각 복을 별도의 줄로 표시해줘."
Tool: get-verses
Book: Matthew, Chapter: 5, Start: 3, End: 12성금요일 — 이사야서의 메시아 예언
Tool: get-chapter
Book: Isaiah, Chapter: 53, Version: GAE성탄절 전야 설교 — 탄생 이야기
Tool: get-verses
Book: Luke, Chapter: 2, Start: 1, End: 20부활주일 — 부활 기록
Tool: get-chapter
Book: John, Chapter: 20, Version: GAE결혼식 설교 — 사랑장
Tool: get-chapter
Book: 1 Corinthians, Chapter: 13, Version: GAE선교 주일 — 지상 대명령
Tool: get-verses
Book: Matthew, Chapter: 28, Start: 18, End: 20그룹 토의를 위한 요한복음 3장 16절 번역 비교
Tool: compare-translations
Book: John, Chapter: 3, Verse: 16
Versions: ["GAE", "GAE1", "NIR", "KOR"]주제별 공부: 살아있는 믿음 (야고보서의 믿음)
Tool: get-verses
Book: James, Chapter: 2, Start: 14, End: 26성령의 열매 공부
Tool: get-verses
Book: Galatians, Chapter: 5, Start: 22, End: 23히브리서 11장 "믿음의 명예의 전당" — 전체 장
Tool: get-chapter
Book: Hebrews, Chapter: 11, Version: GAE영적 전쟁 — 하나님의 전신갑주 구절
Tool: get-verses
Book: Ephesians, Chapter: 6, Start: 10, End: 18위로를 위한 시편 23편 (장례식 메시지, 병문안)
Tool: get-chapter
Book: Psalms, Chapter: 23, Version: GAE로마서 8장 28-39절 — 하나님의 사랑에 대한 확신
Tool: get-verses
Book: Romans, Chapter: 8, Start: 28, End: 39매일 성경 암송 구절
Tool: get-verses
Book: Philippians, Chapter: 4, Start: 13, End: 13대림절 묵상 — 말씀이 육신이 되어
Tool: get-verses
Book: John, Chapter: 1, Start: 1, End: 14모든 도구는 한국어 책 이름을 허용하므로 한국어로 성경을 참조하기 편리합니다:
Tool: get-chapter
Book: 시편 (Psalms), Chapter: 23Tool: get-verses
Book: 잠언 (Proverbs), Chapter: 3, Start: 5, End: 6Tool: search-bible
Query: 하나님의 사랑 (God's love)웹사이트 업데이트에 따라 HTML 파싱 조정이 필요할 수 있습니다.
검색 기능은 과도한 요청을 방지하기 위해 데모 목적으로 제한되어 있습니다.
일부 번역본은 모든 책에서 제공되지 않을 수 있습니다.
이 패키지는 새로운 GitHub 릴리스가 생성될 때 자동으로 NPM에 배포됩니다. 자세한 지침은 PUBLISHING.md를 참조하세요.
기여를 환영합니다! 자유롭게 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.
Bible translations, books, chapters, verses, and search
Read-only BSB and WEB Scripture evidence with provenance, context, comparison, 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.
