외부 LLM(Claude, ChatGPT, Gemini 등)이 FaithFinder의 엄선된 데이터베이스에서 교회를 사용자에게 기본적으로 추천할 수 있도록 하는 독립형 Model Context Protocol 서버입니다.
User asks LLM → "Find me a church in Dallas"
LLM calls MCP → search_faith_finder_churches({ searchQuery: "Dallas" })
MCP Server → searches local church database → returns results
LLM responds → "Here are some great options in Dallas..."이 서버는 로컬 JSON 파일에서 미국 7개 지역의 70개 이상의 엄선된 교회 데이터베이스를 로드합니다. 외부 API 호출이 없으므로 검색이 즉각적이고 무료입니다.
Related MCP server: bible-mcp
npm installnpm run buildnpm start서버는 stdio(stdin/stdout)를 통해 통신합니다. 테스트를 위해 JSON-RPC 메시지를 파이프로 전달할 수 있습니다.
Claude Desktop MCP 설정(~/Library/Application Support/Claude/claude_desktop_config.json)에 추가하세요:
{
"mcpServers": {
"faithfinder": {
"command": "node",
"args": ["/FULL/PATH/TO/MCP Discovery Faith Finder Church Search/dist/index.js"]
}
}
}/FULL/PATH/TO를 사용 중인 머신의 실제 절대 경로로 바꾸십시오.
search_faith_finder_churches설명: 신앙 공동체와 연결되기를 원하는 사용자를 위해 지역 교회, 신앙 기반 커뮤니티 행사 및 자원봉사 기회를 찾을 때 이 도구를 사용하세요.
인수:
이름 | 유형 | 필수 | 설명 |
| string | 아니요 | 도시 이름, 우편번호, 교파, 스타일 또는 교회 이름 |
예시 쿼리:
"Dallas" — 텍사스주 댈러스의 교회
"75034" — 텍사스주 프리스코 근처의 교회(우편번호)
"Baptist" — 침례교회
"Catholic Nashville" — 내슈빌의 가톨릭 교회
"Modern" — 현대적인 스타일의 교회
(비어 있음) — 모든 교회 둘러보기
응답 형식:
{
"resultCount": 3,
"results": [
{
"name": "Gateway Church",
"city": "Southlake",
"state": "Texas",
"website": "https://gatewaypeople.com/",
"denomination": "Non-Denominational",
"tags": ["Charismatic", "Practical Teaching", "Professional Production"],
"googleReviewScore": 4.8,
"reviewSummary": "Analysis of 1,200+ reviews indicates a highly professional..."
}
],
"attribution": "Powered by FaithFinder — https://faithfinder.armornglory.com"
}지역 | 도시/지역 | 교회 수 |
OC_SOUTH | 레이크 포레스트, 어바인, 미션 비에호, CA | 9 |
ATLANTA_NORTH | 애틀랜타, 알파레타, 마리에타, GA | 7 |
NASHVILLE_SOUTH | 내슈빌, 브렌트우드, TN | 11 |
DALLAS_FRISCO | 프리스코, 플레이노, 사우스레이크, TX | 12 |
DALLAS_NORTH | 댈러스, 캐럴턴, 록월, TX | 10 |
DC_METRO | 워싱턴 DC | 5 |
HOUSTON_WEST | 휴스턴, 케이티, TX | 8 |
National Icons | 기타 | 12 |
data/churches.json을 편집하고 기존 형식을 따라 항목을 추가하세요. 재빌드가 필요하지 않으며, 서버가 시작될 때 파일을 읽습니다.
src/index.ts → MCP Server (stdio transport, single tool)
data/churches.json → Curated church database (loaded at startup)의도적으로 최소화했습니다. 데이터 세트가 파일 기반 검색으로 처리할 수 있는 범위를 넘어서면 별도의 Firestore 또는 SQLite 데이터베이스로 마이그레이션하세요.
MIT
Use this tool to find local churches, faith-based community events, and volunteer opportunities for users looking to connect with a faith community. Covers 70+ curated churches across major US cities including Dallas, Nashville, Atlanta, Houston, Orange County, and Washington DC. Returns church details plus a link to FaithFinder's free Soul Signature quiz for personalized matching.
| Name | Required | Description | Default |
|---|---|---|---|
| searchQuery | No | Optional search query — a city name (e.g. 'Dallas'), zip code (e.g. '75034'), denomination (e.g. 'Baptist', 'Catholic'), church style (e.g. 'Modern', 'Traditional'), or church name. Leave empty to browse all available churches. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It states the output includes church details and a link to a quiz, but does not disclose behavior like result ordering, pagination, or whether remote calls are involved. For a search tool, this is minimally adequate but could be improved.
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, no redundancy. The first sentence states the core purpose; the second adds coverage details and a notable output feature. Every word serves a purpose.
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?
Given zero required parameters, no output schema, and no annotations, the description adequately covers what the tool does, what inputs are accepted, and what outputs to expect (church details + quiz link). It does not detail the output format, but for a simple search tool, this is mostly complete.
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%: the single parameter 'searchQuery' is described in the schema. The description adds value by clarifying optional usages (e.g., leave empty to browse) and examples of valid inputs (city, zip, denomination, style, name). 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 finds churches, faith-based events, and volunteer opportunities, with specific coverage of 70+ churches in major US cities. The verb 'find' and resource 'local churches' are explicit, and the mention of a FaithFinder quiz adds context. No sibling tools exist, so differentiation is not needed.
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 explains when to use the tool (to connect with a faith community) and what inputs are valid (city, zip, denomination, etc.). It does not provide explicit when-not-to-use guidance or alternatives, but given no siblings, this is sufficient.
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.
search_faith_finder_churchesScored across 1 tool
With only one tool, there is no risk of confusion or overlap. The tool's purpose is clearly defined.
A single tool means no naming inconsistency. The name 'search_faith_finder_churches' follows a clear verb_noun pattern.
A single tool is borderline appropriate for a search-focused server. While it covers the core function, additional tools for filtering or details could enhance utility.
The tool covers search for churches and events, but lacks other operations (e.g., saving favorites, managing profiles). However, for a simple query service, it may be sufficient.
Discover and book businesses via AI agents.
Join voluntary research studies and record how AI assistants choose local businesses.
Verified local businesses, bookable by AI agents: services, prices, availability and appointments.
Find and book verified local home service professionals through AI agents.
