Provides Tojeong fortune-telling data for integration with Hermes Agent.
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., "@tojeong-mcp My birthday is 1990-06-15, show my tojeong fortune for 2025."
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 서버. 작괘(作卦)로 3자리 괘(卦)를 산출하고, 그 괘의 총운(總運) 과 12개월 월별운 원문을 그대로 반환한다. 헤르메스(Hermes) 에이전트·텔레그램 연동을 염두에 둔 결정론(deterministic)·외부 API 0·오프라인 서버.
데이터 전용 서버. 해석·조언·페르소나는 이 서버가 만들지 않는다. 결정론적 구조화 데이터만 반환하며, 해석은 상위 레이어(SKILL/LLM)의 몫이다. 시(時)는 사용하지 않는다.
결정론. 같은 생년월일·같은 당년 → 항상 같은 괘·같은 운세. 난수·추정·시각 의존 없음.
외부 API 0. 음양력 변환·간지 산출까지 전부 로컬. 어떤 입력도 외부로 내보내지 않는다.
순수 데이터. 원문(총운·월별운)만 반환하고 의미 부여는 하지 않는다 — 해석은 상위 레이어(AI/SKILL) 몫.
검증 가능. 조견표(수리)는 임의 나열이 아니라 표준 수표에서 산출되며, 테스트가 "생성 표 = 공식 = 공개 대조표"를 강제한다.
Related MCP server: BaZi (Eight Characters) Calculator
괘 | 공식 | 나머지 0 처리 |
상괘(上卦) | (한국나이 + 태세수) % 8 | 0 → 8 |
중괘(中卦) | (당년 생월의 날수 + 월건수) % 6 | 0 → 6 |
하괘(下卦) | (음력 생일 + 일진수) % 3 | 0 → 3 |
중괘의 날수 = 당년 생월의 실제 대소(대월 30 / 소월 29). 전거는 한국민족문화대백과사전(한국학중앙연구원) '토정비결' 항목의 작괘법 원문이다 — "당년 생월수를 놓되 달이 크면 30이요, 달이 적으면 29를 놓고 거기에 다시 생월의 월건수를 놓은 다음 6으로 제하고 남은 수로 중괘를 만든다." 유파에 따라 달리 적는 곳이 있어, 이 서버가 무엇을 따르는지 여기 못 박는다.
2026-08-04 교정 —
lunarMonthDays()가getLunarMonthDays()를 인자 없이 불러 언제나 29 를 냈다. 당년 생월이 대월인 사람은 중괘가 한 칸 어긋난 값을 받고 있었다. 같은 뿌리에서 나온 공개 예시 하나(음1975-07-25 / 2024 → 861)도 함께 교정했다(→ 811). 발견: zeostest 가 이 엔진을 PHP 로 이식하며 세운 등가 게이트.
한국나이 = 당년(當年) − 음력 출생년 + 1 (토정비결은 음력 체계이므로 출생년은 음력 연도 기준. 양력 입력도 음력 변환 후의 연도를 쓴다 — 해 경계 출생자, 예: 양력 1월 초 출생은 음력 전년으로 계산될 수 있다.)
날수 = 당년 음력 생월이 대월(大月)이면 30, 소월(小月)이면 29
태세수·월건수·일진수는 출생 시점이 아니라 당년(當年)의 해당 연·월·일 간지(干支) 기준이다.
괘코드 = 상·중·하 3자리 결합 (예: 2·1·2 → 212), 총 8×6×3 = 144괘.
조견표는 임의 나열이 아니라 두 개의 표준 수표에서 결정론적으로 산출된다. src/ganji.js가 진실 출처이며, npm run build:jogyeonpyo로 data/jogyeonpyo.json(60갑자 완전 표)을 생성한다.
선천수(先天數): 甲己子午=9 · 乙庚丑未=8 · 丙辛寅申=7 · 丁壬卯酉=6 · 戊癸辰戌=5 · 巳亥=4
중천수(中天數): 甲己辰戌丑未=11 · 乙庚申酉=10 · 丙辛亥子=9 · 丁壬寅卯=8 · 戊癸巳午=7
수 | 조합 |
태세수(太歲數) | 中天數(천간) + 中天數(지지) |
월건수(月建數) | 先天數(천간) + 先天數(지지) |
일진수(日辰數) | 先天數(천간) + 中天數(지지) |
출처 (독립 3소스 교차 검증):
badukworld.co.kr — 작괘법 및 선천수·중천수 수표 원문
chunun.com — 60갑자 태세수·월건수·일진수 대조표
myungmundang.net — 계산 예시
테스트(test/calc.test.js)가 "생성 표 = 공식 = 공개 대조표 앵커" 등가를 강제한다.
음양력 변환과 연·월·일 간지 산출은 korean-lunar-calendar를 사용한다.
tojeong_fortune (주력)생년월일로 당년 토정비결 운세를 조회한다.
입력 | 타입 | 기본값 | 설명 |
| string (YYYY-MM-DD) | (필수) | 생년월일 |
|
|
| 입력 달력 종류 |
| boolean |
| 음력 윤달 여부 ( |
| integer | 현재 연도 | 운세를 보는 해(당년) |
출력: gwae_code, gwae{sang,jung,ha}, chongun, months{1..12}, 그리고 계산 감사(audit)용 meta(음/양력 생일, 윤달 정규화 여부, 한국나이, 태세·월건·일진 간지·수, 생월 날수).
윤달생은 평달로 간주하는 통례를 적용하며, 이때
meta.leap_month_normalized: true로 표기한다.당년 생월이 소월(29일)인데 생일이 30일이면 말일(29일)로 당겨 계산하고
meta.day_clamped: true로 표기한다. 이는 문서화된 전통 규칙이 아니라 무음(silent) 오답을 막기 위한 구현 관례다.
tojeong_gwae_lookup (보조)괘코드(111~863, 상1-8·중1-6·하1-3)로 해당 괘의 총운·월별운 원문을 그대로 조회한다. 브라우징·테스트·SKILL 개발용.
npm install
npm test # 픽스처 6종 검증Claude Desktop claude_desktop_config.json 또는 헤르메스 에이전트 MCP 설정:
{
"mcpServers": {
"tojeong": {
"command": "node",
"args": ["/absolute/path/to/mcp-tojeong/src/index.js"]
}
}
}144괘 한글 해석문은 개인 소장 자료(1998)를 기반으로 현대 맞춤법으로 윤문한 것이다. 데이터 구조: { "<괘코드>": { code, chongun, months } }.
토정비결은 조선 후기부터 이어진 세시풍속(歲時風俗)으로, 이 서버가 반환하는 운세는 재미·참고용 전통 텍스트이며 미래를 예측하거나 보장하지 않는다(과학적 사실 아님·운명론 아님). 중요한 의사결정의 근거로 삼지 말 것.
Hermes Agent용 MCP — molpass의 바이브 코딩(vibe coding) 프로젝트.
아이디어·방향: molpass (이정훈) · https://zeolinex.com
기획: Claude (Chat)
개발: Claude Code
같은 모음:
mcp-saju · mcp-qr · mcp-biorhythm · mcp-astrology · mcp-ziwei · mcp-numerology · mcp-liuren · mcp-qimen · mcp-taiyi · mcp-weather · mcp-newsfeed · mcp-bible · mcp-gwansang · mcp-lotto
mcp-tojeong (이 repo)
MIT © molpass (코드·해석문 윤문).
음양력·간지 산출: korean-lunar-calendar (MIT).
조견표 수표는 위 출처의 공개 자료를 교차 검증해 재산출.
생년월일로 해당 연도의 토정비결(土亭祕訣) 운세를 조회한다. 작괘(作卦)로 3자리 괘(卦)를 산출하고 그 괘의 총운(總運)과 12개월 월별운 원문을 그대로 반환한다. 해석·조언은 생성하지 않는 데이터 전용 도구다. 시(時)는 사용하지 않는다.
| Name | Required | Description | Default |
|---|---|---|---|
| calendar | No | 입력 달력 종류 (기본 solar=양력) | solar |
| birth_date | Yes | 생년월일 (YYYY-MM-DD) | |
| target_year | No | 운세를 보는 해(당년). 기본값=현재 연도 | |
| is_leap_month | No | 음력 윤달 여부 (calendar=lunar일 때만 유효) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains the internal procedure (작괘), the output content (총운 and 12-month monthly fortune), the fact that it returns original text unchanged, and that it does not generate interpretations or use the hour. This is a thorough and honest account of the tool's behavior.
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 concise and well-structured: three sentences each serve a distinct purpose—stating the main function, describing the method and return value, and clarifying exclusions. It is front-loaded with the core purpose and contains no redundant words or 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 tool with no output schema and no annotations, the description does a good job of explaining what it returns and what it does not do. It covers the essential behavior and exclusions effectively. However, it does not mention parameter defaults (e.g., target_year defaults to current year) or provide any guidance relative to the sibling tool, which would round out the context. Nevertheless, the description is sufficiently complete for typical use.
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?
Since the schema description coverage is 100%, all parameters (birth_date, calendar, target_year, is_leap_month) already have clear descriptions. The tool description adds minimal extra meaning: it confirms birth_date as the key input and explicitly states that the hour is not used, which is a helpful clarification but does not significantly go beyond the schema. Therefore, 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's purpose: it inquires the annual Tojeong Secret fortune based on birth date, computes a 3-digit hexagram, and returns the overall and monthly fortunes as original text. It distinguishes itself from the sibling tool by specifying its input (birth date) and output (fortune text), making it unambiguous.
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 clear usage context: it is a data-only tool that returns raw original text and does not generate interpretations or advice, which serves as an exclusion criterion. It also notes that the hour is not used, guiding the user on relevant inputs. However, it does not explicitly mention alternatives like the sibling tool tojeong_gwae_lookup, so it falls short of a full 'when-to-use-vs-alternatives' explanation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
괘코드(111~863, 상1-8·중1-6·하1-3)로 해당 괘의 총운·12개월 월별운 원문을 그대로 조회한다. 브라우징·테스트·SKILL 개발용 보조 도구다.
| Name | Required | Description | Default |
|---|---|---|---|
| gwae_code | Yes | 괘코드 (예: 212) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the transparency burden. It discloses that the lookup returns the exact original text ('그대로 조회') and is auxiliary, implying read-only intent. But it does not mention permissions, return format, error behavior, or side effects, leaving some behavioral aspects unspecified.
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 long, front-loading the core functionality and then stating the intended purpose. Every clause contributes meaning without redundant repetition of schema 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 single-parameter lookup with no output schema, the description adequately covers input format, what is returned (yearly and monthly fortune text), and intended usage. It does not detail response structure or the exact relationship with tojeong_fortune, but given the tool's simplicity and auxiliary role, this is sufficient.
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 schema already covers the parameter with a pattern and example (100% coverage), but the description adds valuable meaning by explaining the code structure ('상1-8·중1-6·하1-3') and range (111~863), which is more intuitive than the regex pattern and aids correct parameter construction.
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 states a specific action '조회한다' (retrieves) and a specific resource (the hexagram's total fortune and 12-month monthly fortune original text) using a code format. It also distinguishes itself as an auxiliary tool for browsing/testing/SKILL development, separating it from the sibling tojeong_fortune.
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 clearly identifies intended contexts ('browsing, testing, SKILL development') via '보조 도구다'. However, it does not explicitly state when not to use the tool or name the alternative tojeong_fortune, so it lacks explicit exclusions.
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.0.0tojeong_fortunetojeong_gwae_lookupScored across 2 tools
The two tools have clearly distinct purposes: one takes a birthdate and produces the year's fortune, the other accepts a gwae code for direct retrieval. The descriptions explicitly delineate user-facing use vs. development/testing, so an agent would not confuse them.
Both tools share the 'tojeong_' prefix and use snake_case, which is consistent. However, the second part differs in pattern: 'fortune' is a noun while 'gwae_lookup' is a compound noun+verb, creating a minor inconsistency.
With only two tools, the server feels thin for a fortune service, but the scope is narrow and both tools serve specific purposes. It falls in the borderline range for tool count.
The server covers the core workflow of obtaining a Tojeong fortune from a birthdate, with an additional low-level lookup. It intentionally omits interpretation/advice, so within its data-only scope the surface is sufficient, though a tool to return just the gwae code might be a minor gap.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Korean Four Pillars (Saju/BaZi) calculator: pillars, elements, ten gods, sinsal, luck cycles.
Korean saju fortune MCP: natal chart, today/daily/yearly luck, compatibility, and saved profiles.
Deterministic Korean Saju / BaZi Four Pillars MCP. Day Master, five elements, compatibility.
Destiny Weight reading from birth date — Yuan Tiangang method.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/molpass/mcp-tojeong'
If you have feedback or need assistance with the MCP directory API, please join our Discord server