Saroday MCP Server
@saroday/mcp-server
MCP (Model Context Protocol) Server für Saroday — Koreanische Saju (사주) Berechnung und Myeongni-hak (命理學) Glossar-Suche.
Dieser MCP-Server ermöglicht es Claude Desktop, Cline, Cursor und jedem anderen MCP-kompatiblen KI-Client, präzise koreanische Saju-Berechnungen (Vier Säulen des Schicksals) durchzuführen, indem im Hintergrund die öffentliche Saroday-API aufgerufen wird.
Funktionsweise
Nach der Verbindung erhält der KI-Client Zugriff auf vier Tools:
Tool | Beschreibung |
| Berechnet die vollständige Saju-Analyse (8 Zeichen, Sipseong, Sinsal, Hapchung, 12-Unseong, Yongshin, Daeun) basierend auf Geburtsdatum / Uhrzeit / Geschlecht. |
| Schlägt einen von über 80 Myeongni-hak-Begriffen (도화살, 천을귀인, 식신, 육합 usw.) mit vollständiger koreanischer Erklärung nach. |
| Tageshoroskop für eines der 12 westlichen Sternzeichen oder 12 chinesischen Tierkreiszeichen. Serverseitig zwischengespeichert, schnelle Antwort. |
| Listet verfügbare Saroday-API-Endpunkte und Metadaten auf. |
Warum das wichtig ist: ChatGPT, Claude und andere LLMs berechnen Saju bei direkter Anfrage häufig falsch, da die Suche im Manse-ryeok (萬歲曆) und die Handhabung der 절기 (Jeolgi)-Grenzen präzise Daten erfordern. Dieses MCP delegiert die mathematischen Berechnungen an einen verifizierten Server, während die KI sich auf die Interpretation konzentrieren kann.
Related MCP server: 命盘 Mingpan
Installation
Option A — npx (keine Installation)
npx @saroday/mcp-serverOption B — Globale Installation
npm install -g @saroday/mcp-server
saroday-mcpOption C — Klonen und Ausführen
git clone https://github.com/saroday/mcp-server.git
cd mcp-server
npm install
node index.jsErfordert Node.js 18 oder neuer.
Claude Desktop konfigurieren
Bearbeiten Sie Ihre Claude Desktop-Konfigurationsdatei:
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.json
Fügen Sie Folgendes hinzu (oder führen Sie es zusammen):
{
"mcpServers": {
"saroday": {
"command": "npx",
"args": ["-y", "@saroday/mcp-server"]
}
}
}Starten Sie Claude Desktop neu. Sie sollten "saroday" im Bereich der MCP-Server sehen (das Stecker-Symbol im Eingabebereich).
Lokale Entwicklung (Ausführung aus dem geklonten Repository)
{
"mcpServers": {
"saroday": {
"command": "node",
"args": ["/absolute/path/to/mcp-server/index.js"]
}
}
}Cline / Cursor / andere MCP-Clients konfigurieren
Jeder MCP-Client, der den stdio-Transport unterstützt, funktioniert. Verweisen Sie auf die saroday-mcp-Binärdatei oder node index.js. Informationen zum genauen Konfigurationsformat finden Sie in der Dokumentation Ihres Clients.
Ausprobieren
Fragen Sie Claude nach der Verbindung Dinge wie:
"Mein Geburtstag ist der 15. März 1992 um 10 Uhr morgens. Berechne mein koreanisches Saju."
"Was bedeutet 도화살 (dohwa-sal) in der koreanischen Wahrsagerei?"
"내 사주 봐줘. 1990년 5월 20일 음력 14시 여성."
"제왕(jeokwang) 12-unseong이 뭐야?"
Claude wird automatisch calculate_saju oder lookup_glossary aufrufen und Ihnen eine ausgefeilte Interpretation basierend auf den zurückgegebenen strukturierten Daten liefern.
Umgebungsvariablen
Variable | Standard | Zweck |
|
| Überschreibt die API-Basis-URL (z. B. für selbst gehostete oder Staging-Umgebungen). |
Ratenbegrenzungen
Die öffentliche Saroday-API erlaubt 100 Anfragen pro Stunde und IP für die kostenlose Nutzung. Nutzer mit hohem Aufkommen – Apps, die an viele Endnutzer ausgeliefert werden, oder KI-Agenten, die viele gleichzeitige Benutzer verarbeiten – sollten einen API-Schlüssel (in Kürze verfügbar) für höhere Kontingente anfordern.
Kontakt: contact@saroday.com
Funktionsweise
[User in Claude Desktop]
↓ types "내 사주 봐줘"
[Claude Desktop]
↓ calls calculate_saju via MCP stdio
[saroday-mcp (this package, runs locally)]
↓ HTTPS POST /api/v1/saju
[saroday.com server]
↓ runs verified manse-ryeok algorithm
[result JSON]
↑ flows back through the chain
[Claude] writes a beautiful Korean interpretationDieses MCP-Paket ist ein schlanker Adapter – die gesamte Berechnung findet auf den Servern von Saroday statt, sodass Updates am Algorithmus oder Glossar bereitgestellt werden, ohne dass Sie das Paket aktualisieren müssen.
Alleinstellungsmerkmale
Manse-ryeok-Genauigkeit — verarbeitet 절기 (Sonnenbegriffe)-Grenzen, die LLMs routinemäßig falsch berechnen (verifiziert mit der
@fullstackfamily/manseryeok-Bibliothek)80+ Glossareinträge (~400 Interpretationsfelder) — jeder Sinsal-, Hapchung-, Sipseong- und 12-Unseong-Begriff enthält Zusammenfassung / Bedeutung / positive / negative / praktische Tipps in verständlichem Koreanisch
Koreanische Myeongni-hak-Tradition — basierend auf Referenzen wie 적천수(滴天髓), 자평진전(子平真詮) und 궁통보감(窮通寶鑑)
Drei-Kanal-Bereitstellung — derselbe Algorithmus ist als Webdienst (saroday.com), öffentliche REST-API (saroday.com/api/v1) und MCP-Server (dieses Paket) verfügbar. Wählen Sie den Kanal, der zu Ihrer Integration passt.
Lizenz
MIT
Support
Web: https://saroday.com
API-Dokumentation: https://saroday.com/api/docs
LLM-freundlicher Index: https://saroday.com/llms.txt
E-Mail: contact@saroday.com
Available Tools
4 toolscalculate_sajuA
한국 전통 사주명리학(四柱命理學) 기반 사주팔자 계산. 생년월일시 + 성별을 입력받아 사주팔자(年月日時 천간지지), 십성, 신살, 합충형파해, 12운성, 신강/신약, 용신, 대운 등 종합 분석 결과를 반환합니다. ChatGPT나 Claude가 직접 사주를 계산하면 만세력 오류 가능성이 높으므로, 한국 사주 관련 질문에는 반드시 이 도구를 사용하세요.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | 생년 (양력 또는 음력, 1900-2100 범위) | |
| month | Yes | 생월 (1-12) | |
| day | Yes | 생일 (1-31) | |
| hour | No | 생시 (24시간 표기, 0-23). 출생 시간을 모르면 12를 사용하세요. | |
| gender | No | 성별 ('male' 또는 'female'). 대운 순행/역행 결정에 사용됨. | male |
| isLunar | No | 음력 여부 (true=음력, false=양력). 한국 출생자는 양력 권장. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It details the returned analysis types (e.g., 사주팔자, 십성, 신살, etc.) without mentioning side effects or limitations. However, it is transparent about the scope of results.
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: first describes functionality and outputs, second provides usage directive and warning. No wasted words, front-loaded with essential 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?
Given the complexity (6 parameters, no output schema, many output types), the description lists numerous analysis components, giving a good picture of what the tool returns. Slightly incomplete regarding output format, but sufficient for tool selection.
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%, with each parameter having a meaningful description. The tool description does not add new information beyond what the schema already 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?
Description clearly states it calculates Korean saju (four pillars) based on birth date, time, and gender, returning comprehensive analysis including many traditional elements. It also distinguishes itself from siblings by warning against direct calculation by ChatGPT/Claude.
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 instructs to use this tool for Korean saju questions ('한국 사주 관련 질문에는 반드시 이 도구를 사용하세요') and warns of potential errors if calculated directly. Provides clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discover_saroday_apiA
Saroday API 메타 정보 조회. 사용 가능한 엔드포인트, 문서 링크, 호출 한도 등을 반환합니다. 처음 사용할 때 한 번 호출해서 어떤 도구가 있는지 파악할 수 있습니다.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool returns metadata and implies it is read-only and safe. However, it does not explicitly confirm no destructive effects, auth requirements, or rate limits for this tool itself. This is adequate but could be more explicit.
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 two sentences: the first clearly defines the tool's purpose, and the second provides usage guidance. It is front-loaded, concise, and contains no extraneous 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 parameterless tool with no output schema and a simple metadata purpose, the description fully covers what the tool does, what it returns, and when to use it. Sibling tools are distinct, so the agent can correctly infer its role.
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 has no parameters, and schema description coverage is 100%. The description implicitly indicates that no parameters are needed ('call once'). It does not need to add param details, though it could explicitly state 'no parameters required.'
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 that the tool retrieves metadata (endpoints, docs, rate limits) about the Saroday API. It distinguishes itself from sibling tools like calculate_saju, get_daily_fortune, and lookup_glossary, which are specific application 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?
The description explicitly advises calling this tool once at first use to understand available tools. This provides clear when-to-use guidance, though it does not mention when not to use it or specify alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_daily_fortuneA
오늘의 운세 조회 (별자리 또는 띠). 한국 사용자가 가장 자주 보는 운세 카테고리. 사용자가 '오늘의 운세 봐줘', '내 별자리 오늘 어때?', '말띠 오늘 운세' 같은 질문을 할 때 사용하세요. GPT 기반 자연어 운세지만 사로 서버에서 하루 한 번만 생성하고 캐시하므로 응답 빠름.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | 'zodiac' = 서양 별자리 (12개), 'chinese' = 동양 띠 (12개) | |
| sign | Yes | 별자리 또는 띠 ID. zodiac: aries, taurus, gemini, cancer, leo, virgo, libra, scorpio, sagittarius, capricorn, aquarius, pisces. chinese: rat, ox, tiger, rabbit, dragon, snake, horse, sheep, monkey, rooster, dog, pig. 사용자 생년월일을 받았다면 자체적으로 계산하여 ID 추론 후 호출. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description adds valuable behavioral context: GPT-based but cached daily for fast response. Does not contradict any 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?
Four sentences front-loaded with purpose, then usage examples and technical detail. No redundancy; every sentence earns its place.
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?
No output schema, but description provides enough for an agent to understand purpose and when to call. Missing return format is a minor gap.
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%, baseline 3. Description adds example queries, explains enum values, and mentions automatic sign inference from birth date, surpassing schema alone.
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 clearly states '오늘의 운세 조회 (별자리 또는 띠)' and provides example user queries, making the purpose specific and distinguishing from siblings like calculate_saju.
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?
Describes when to use with example queries and notes the cached nature. Lacks explicit exclusions or alternatives but context from siblings suffices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_glossaryA
명리학 용어 풀이 조회. 십성(비견·겁재·식신·상관·편재·정재·편관·정관·편인·정인), 신살(천을귀인·도화살·역마살·양인살·괴강살 등 28+ 종류), 합충형파해(천간합/충, 육합·삼합·반합·방합, 충/형/파/해/원진), 12운성(장생·목욕·관대·건록·제왕·쇠·병·사·묘·절·태·양) 등 80+개 용어 풀이를 반환합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | 조회할 명리학 용어 (한글). 예: '도화살', '식신', '천을귀인', '육합', '제왕' |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description indicates a read-only lookup returning definitions, but does not disclose whether it is idempotent, any authentication requirements, or rate limits. With no annotations, the description carries the full burden but only states what it does, not behavioral traits.
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 description is front-loaded with the core action, then lists categories. It is informative but somewhat long; could be split for readability. 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?
Given the simple input (1 param, no output schema), the description adequately covers the tool's purpose and scope. It does not mention if the term is case-sensitive or if partial matches are allowed, but the example terms compensate. Reasonably 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 description coverage is 100% (parameter 'term' described in both schema and description). The description adds value by listing example terms and categories, providing context beyond the schema's generic 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 looks up glossary terms for Myeongrihak, listing specific categories (십성, 신살, 합충형파해, 12운성) and over 80 terms. The verb '조회' and resource '명리학 용어 풀이' are specific, distinguishing it from sibling 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?
No explicit guidance on when to use versus alternatives. The context signals show sibling tools like calculate_saju, but the description does not compare them or provide exclusions. Usage is implied: lookup a term when you need its definition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
4 tool updates
v0.1.0- First observed
calculate_saju - First observed
discover_saroday_api - First observed
get_daily_fortune - First observed
lookup_glossary
TDQS
Scored across 4 tools
Each tool has a clearly distinct purpose: calculate_saju computes fortune using traditional methods, discover_saroday_api provides API metadata, get_daily_fortune offers daily horoscopes, and lookup_glossary explains terminology. No overlap in functionality.
All tool names follow a consistent verb_noun pattern using snake_case: calculate_saju, discover_saroday_api, get_daily_fortune, lookup_glossary. No deviation in style.
With 4 tools, the server is well-scoped for its domain of Korean fortune telling. Each tool serves an essential function without redundancy or unnecessary complexity.
The tool set covers the core aspects of the domain: personal fortune calculation (saju), daily fortune, glossary reference, and API discovery. No obvious gaps for the stated purpose.
Maintenance
Related MCP Connectors
- mcpweaveOAuthcom.mcpweave
Korea-native MCP gateway: Korean commerce, payments, messaging, gov & finance APIs for AI agents.
Remote MCP server exposing 330 production AI-agent services for web/data processing, validation, AI utilities, blockchain/crypto utilities, and x402 pay-per-use access.
- UnifAPIOAuthcom.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
Related MCP Servers
- FlicenseNot gradedqualityBmaintenanceEnables traditional Chinese metaphysics tools like Bazi, Ziwei, and Qimen via MCP, integrating AI analysis for divination and fortune-telling.580-
- AlicenseAqualityAmaintenanceProvides traditional Chinese astrology (Bazi, Ziwei) and divination (Liuyao, Meihua, Qimen, etc.) calculations as MCP tools for AI assistants.21772 npm113Apache 2.0
- FlicenseAqualityDmaintenanceEnables MCP clients to compute and interpret Korean Four Pillars of Destiny (Saju) through natural language, including calculation, interpretation, compatibility analysis, and daily fortune.423 npm-
- FlicenseNot gradedqualityDmaintenanceMCP server that calculates saju (four pillars) from birth date/time and provides entertaining interpretations of daily fortune, yearly luck, compatibility, name analysis, and tarot using MIT-licensed manseryeok-js.-