de en es ja ko ru zh

ming-metaphysics-mcp

Name: ming-metaphysics-mcp
Author: Espivc

by Espivc

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

ming-metaphysics-mcp

Пять движков китайской метафизики в качестве инструментов MCP для Claude Desktop и любого клиента, совместимого с MCP.

vs `bazi-mcp` от Cantian

Измерение	Cantian `bazi-mcp`	Ming `ming-metaphysics-mcp`
Охват искусств	Только Ба-цзы	Все пять — Ба-цзы + Ци Мэнь + Цзы Вэй + Фэн-шуй + И Цзин
Глубина движка	Хорошая реализация Ба-цзы	9.0–9.5/10, подтверждено экспертами по всем пяти движкам
Классические источники	Не задокументированы	子平真詮, 淵海子平, 紫微斗數全書 + цитируется библиотека из 108 наименований
Качество вывода	Компетентные чтения	Проверено учеными, двуязычный (EN/ZH), глубина уровня отчета
Воронка консультаций	Нет	Доступно чтение у мастера через Ming Bot (ссылка будет позже)
Гуа + Восемь дворцов	❌	✅
Тайминг Ци Мэнь	❌	✅ (вычисление sxtwl Ju)
И Цзин (Лю Яо)	❌	✅ (классический метод 納甲法)

Related MCP server: 命盘 Mingpan

Инструменты

Инструмент	Движок	Описание
`ming_bazi_analyze`	Ба-цзы 八字	Карта четырех столпов — Господин дня, структура, столпы удачи
`ming_qmdj_direction`	Ци Мэнь 奇門	Оптимальное направление + временное окно для даты
`ming_zwds_chart`	Цзы Вэй 紫微	Натальная карта из двенадцати дворцов с трансформациями 四化
`ming_fengshui_flying_stars`	Фэн-шуй 風水	Число Гуа + анализ направлений Восьми дворцов
`ming_iching_cast`	И Цзин 易經	Гексаграмма через классический метод 納甲法 (Лю Яо)
`ming_full_forecast`	Все четыре движка данных рождения	Комплексный прогноз по пяти движкам с оценкой достоверности

Требования к движку

Этот пакет является оберткой MCP. Он не содержит логики вычислений метафизики — он перенаправляет вызовы инструментов на конечную точку движка Ming по HTTP. Чтобы использовать его, укажите MING_API_URL на запущенный движок.

Два способа получить движок:

Хостинговая конечная точка (предпочтительно, когда доступна). Публичная конечная точка Ming будет анонсирована; как только она станет доступна, настройте MING_API_URL, чтобы указывать на нее, и все готово.
Самостоятельный хостинг. Сам движок Ming в настоящее время является эталонной реализацией с закрытым исходным кодом. Если у вас есть доступ к кодовой базе Ming, запустите uvicorn api.main:app --port 8000 и укажите этот MCP на localhost:8000.

Без доступного движка сервер MCP запускается и перечисляет инструменты, но вызовы инструментов возвращают ошибку HTTP.

Установка

Шаг 1 — Убедитесь, что движок доступен

См. «Требования к движку» выше.

Шаг 2 — Установите сервер MCP

npm install -g ming-metaphysics-mcp

Шаг 3 — Добавьте в `claude_desktop_config.json`

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "ming": {
      "command": "ming-metaphysics-mcp",
      "args": [],
      "env": {
        "MING_API_URL": "http://localhost:8000"
      }
    }
  }
}

Перезапустите Claude Desktop. Инструменты Ming появятся в списке инструментов.

Проверка

В Claude Desktop:

Using the ming_bazi_analyze tool, analyze the chart for someone born 1990-03-15, male, in Singapore.

Вы должны получить полное чтение Ба-цзы. Если инструмент выдает ошибку, проверьте, запущен ли движок Python на порту 8000.

Пробелы в конечных точках

Следующие возможности требуют расширения FastAPI, прежде чем они будут полностью функционировать, как указано. Каждая из них помечена примечанием в ответе инструмента — никаких скрытых сбоев.

Пробел	Затронутый инструмент	Требуемое изменение FastAPI
Карта летящих звезд на конкретный год	`ming_fengshui_flying_stars`	`/consult` требует параметр запроса `year` для вычисления годовых звезд для лет, отличных от текущего
Параметр `forecast_year`	`ming_full_forecast`	`/consult` вычисляет годовой анализ относительно текущего года внутри системы; он не принимает целевой год
Полная метка времени ISO `casting_timestamp`	`ming_iching_cast`	`/iching-cast` принимает `date` (ГГГГ-ММ-ДД) и `hour_branch` отдельно, а не метку времени ISO 8601; пересылается только часть даты
Маршрутизация `goal: "bazi"/"qmdj"/"zwds"`	Все отдельные инструменты	Спецификация предполагала, что `/consult` будет принимать цели с именами движков, но реальная конечная точка использует цели по назначению (`wealth/career/health/relationship/general`). Вместо этого отдельные инструменты направляются на выделенные конечные точки для каждого движка (`/analyze`, `/zwds`, `/qmdj`, `/iching-cast`)

Чтобы реализовать поддержку летящих звезд для конкретного года или forecast_year, добавьте эти параметры в /consult в api/main.py и обновите соответствующие обработчики инструментов здесь.

Разработка

git clone <this-repo>
cd ming-metaphysics-mcp
npm install
npm run build          # compile TypeScript → dist/
npm test               # smoke tests (no engine required)

# With engine running at localhost:8000:
npx ts-node scripts/benchmark.ts --tool all --iterations 5

Переменные окружения

Переменная	По умолчанию	Описание
`MING_API_URL`	`http://localhost:8000`	Базовый URL движка Ming FastAPI

Целевые показатели задержки

Инструмент	Цель
`ming_bazi_analyze`	< 3с
`ming_qmdj_direction`	< 3с
`ming_fengshui_flying_stars`	< 3с
`ming_zwds_chart`	< 5с
`ming_full_forecast`	< 5с
`ming_iching_cast`	< 3с

Если какой-либо инструмент постоянно превышает 5 секунд, проверьте узкое место движка и рассмотрите возможность добавления timeout: 10000 в конфигурацию MCP.

Аутентификация

На уровне обертки отсутствует — этот сервер является открытым и бесплатным (лицензия MIT). Аутентификация, если она есть, обеспечивается любой конечной точкой, на которую указывает MING_API_URL.

Для полного чтения по пяти движкам

Управляемая консультация по пяти движкам (Ба-цзы + Цзы Вэй + Ци Мэнь + Фэн-шуй + И Цзин, синтезированные мастером Ченом) доступна через Telegram-бота Ming. Ссылка будет опубликована, как только бот перейдет в стадию публичного бета-тестирования.

Конфиденциальность

Сама эта обертка MCP не собирает данные. Она пересылает аргументы вашего инструмента (дата рождения, час, пол, текст вопроса) на любой MING_API_URL, который вы настроили. Если вы указываете на хостинговую конечную точку, эта конечная точка получает данные — ознакомьтесь с ее политикой конфиденциальности. Если вы используете собственный хостинг, данные не покидают вашу сеть.

Данные о рождении являются конфиденциальными. Если вы настраиваете это для конечных пользователей, четко укажите, какая конечная точка получает их данные.

Статус проекта

Этот пакет имеет версию 1.0.0. Поверхность протокола MCP (6 инструментов, схемы JSON, формы ответов) стабильна. Базовый движок Ming развивается быстрее — незначительные числовые изменения в ответах инструментов являются нормальными.

Вклад приветствуется — см. CONTRIBUTING.md.

Лицензия

MIT — см. LICENSE.

Available Tools

6 tools

ming_bazi_analyzeA

Compute a full BaZi (Four Pillars of Destiny 八字) chart. Returns Day Master analysis, pattern classification (格局), decade luck pillars (大运), and annual outlook. Engine verified against 子平真詮 and 淵海子平. Requires Ming engine running at MING_API_URL.

ParametersJSON Schema

Name	Required	Description
`birth_date`	Yes	Date of birth in YYYY-MM-DD format. Must be after 1900-01-01.
`birth_hour`	No	Hour of birth in 24-hour format (0–23). If unknown, omit — analysis will note the limitation.
`birth_location`	No	City and country of birth (e.g. 'Singapore, Singapore'). Provides timezone context.
`gender`	Yes	Gender determines luck pillar direction (forward for males in yang years, backward for females).
`question`	No	Optional. Specific question to orient the reading (e.g. 'Is 2026 good for a career change?').

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries full burden. It discloses the compute behavior, output types, and engine verification. It does not mention destructive actions or permissions, but for a read-only computation tool, the behavioral transparency is adequate and adds value beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences (∼50 words), each serving a purpose: stating the main action and outputs, verifying accuracy, and noting a requirement. No redundant or extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 5 parameters (2 required) and no output schema. The description provides high-level output categories and verification context, which is helpful. However, it does not detail the output structure or error handling, so completeness is slightly lacking.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description does not add significant meaning beyond what the schema already provides for each parameter. It mentions the engine requirement but not parameter-specific details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Compute' with a clear resource 'BaZi chart'. It lists exact outputs and references verification against authoritative sources. Sibling tools are distinct (fengshui, forecast, iching, etc.), so differentiation is clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states it requires the Ming engine running at MING_API_URL, providing a prerequisite. It does not explicitly state when not to use or compare with siblings, but given the distinct domains of siblings, the usage context is clear and no explicit exclusions are critical.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ming_fengshui_flying_starsA

Compute the Kua number (卦命), directional analysis, and annual Flying Star map (年飛星) for a person. Returns Kua group, favorable/unfavorable directions per Eight Mansions (八宅法), the nine-palace annual star chart for the requested year, and a five-engine directional synthesis.

ParametersJSON Schema

Name	Required	Description
`year`	Yes	Year for the annual Flying Star map (年飛星). Range 1700–2100. Defaults to current year when omitted.
`birth_date`	Yes	Date of birth in YYYY-MM-DD format — used to compute the Kua number.
`gender`	Yes	Gender is required for Kua number calculation.
`location_description`	No	Optional. Description of the property (e.g. 'apartment, front door faces North').

TDQS

A3.9/5.0

Behavior3/5

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 describes the computational outputs but does not disclose behavioral traits such as accuracy assumptions, required expertise, or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loading the main purpose. It lists outputs efficiently, though a more structured format (e.g., bullet points) could improve clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description must hint at return format. It lists all major outputs (Kua group, directions, chart, synthesis), which is adequate for an agent to understand the return value, though format details are missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining the purpose of each parameter (e.g., year for annual star map, birth_date for Kua calculation), which is beyond the schema's type and format details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool computes Kua number, directional analysis, and annual Flying Star map, listing specific outputs (Kua group, directions, chart, synthesis). This distinguishes it from siblings like ming_bazi_analyze and ming_qmdj_direction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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. While the listed outputs imply a feng shui context, no direct comparison or exclusion is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ming_full_forecastA

Run all four birth-data engines (BaZi + ZWDS + Feng Shui + QMDJ) for a birth profile and return an integrated Master-tier forecast. I Ching is excluded from bulk forecasts (it requires a specific question — use ming_iching_cast separately).

ParametersJSON Schema

Name	Required	Description	Default
`birth_date`	Yes	Date of birth in YYYY-MM-DD format.
`birth_hour`	No	Hour of birth in 24-hour format (0–23).
`birth_location`	No	City and country of birth (e.g. 'Singapore, Singapore').
`gender`	Yes
`forecast_year`	No	The year to forecast for. Range 1900–2200, defaults to current year. Affects BaZi luck pillar selection and ZWDS 流年四化 annual chart.
`question`	No	Primary question to orient the synthesis (e.g. 'Is 2026 the right year to start a business?').
`goal`	No	Focus domain for the synthesis. Maps to the /consult 'goal' parameter. Defaults to 'general'.	general

TDQS

A3.6/5.0

Behavior2/5

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 only states it 'runs' the engines, without disclosing behavioral traits like read-only status, side effects, or permissions. Minimal transparency for a complex tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the main purpose, and the second sentence adds a crucial usage note. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool integrating four engines without an output schema, the description is too minimal. It does not explain what 'integrated Master-tier forecast' includes, nor any behavioral assumptions or expected output structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is high (86%), so the schema already documents all parameters. The description adds context about I Ching exclusion but does not significantly enhance parameter meaning. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it runs four engines (BaZi, ZWDS, Feng Shui, QMDJ) and returns an integrated forecast. It distinguishes from siblings by explicitly excluding I Ching and directing to ming_iching_cast.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides clear context for when to use (integrated forecast) and explicitly excludes I Ching, directing to a sibling. However, it lacks guidance on when to use this versus individual engine tools like ming_bazi_analyze.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ming_iching_castA

Cast an I Ching (易經) hexagram using the classical 納甲法 (Liu Yao method). Returns the hexagram, changing lines, transformed hexagram, and interpretation. The casting derives from the current date/time (SGT) by default.

ParametersJSON Schema

Name	Required	Description	Default
`question`	Yes	The specific question to cast for. Must be a genuine question about a real situation. Example: 'Should I accept the offer from Company X?' — not 'What will happen to the economy?'
`casting_timestamp`	No	Optional. ISO 8601 timestamp of the casting moment (e.g. '2026-04-18T14:30:00'). When provided, the date and time are both forwarded to the engine — the time component determines the hour branch (地支) used for 納甲 analysis. If omitted, uses the server's current SGT time.

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It mentions that casting derives from current date/time by default and that the optional timestamp affects the hour branch. However, it does not explicitly state that the operation is read-only (non-destructive) or any limitations. Adequate but not thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is only two sentences, gets straight to the point, and front-loads the main purpose. Every sentence adds essential information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 2 parameters and no output schema, the description covers the return elements (hexagram, changing lines, etc.) and the default behavior with date/time. It could elaborate on the interpretation output, but overall it provides sufficient context for a divination tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already has good descriptions (100% coverage). The description adds value by emphasizing that the question must be genuine and about a real situation, and by explaining how the timestamp's time component affects the analysis. This enhances the schema's information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool casts an I Ching hexagram using the classical nàjiǎ method, and specifies the output includes hexagram, changing lines, transformed hexagram, and interpretation. This is specific and distinguishes it from sibling tools like bazi or fengshui.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives like ming_bazi_analyze or ming_fengshui_flying_stars. The description gives an example of question format but does not explain when I Ching is appropriate compared to other divination systems.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ming_qmdj_directionA

Compute a Qi Men Dun Jia (奇門遁甲) reading for a specific date. Returns the optimal direction, best timing windows, lead star, and strategic framing. Ju number computed via sxtwl solar term library for classical accuracy.

ParametersJSON Schema

Name	Required	Description
`date`	No	Date for the QMDJ reading in YYYY-MM-DD format. Defaults to today (SGT) if omitted.
`hour`	No	Optional hour for hour-level resolution. If omitted, returns the best hour block for the day.
`question`	Yes	The specific intention (e.g. 'Best direction for a job interview', 'Is today favourable for signing a contract?').

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must convey behavioral traits. It mentions the use of 'sxtwl solar term library for classical accuracy', adding technical transparency. However, it does not disclose whether the operation is idempotent, safe (read-only), or any error conditions. The description is adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no wasted words. The first sentence states purpose and outputs, the second adds technical detail. Information is front-loaded and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description covers the key return values (optimal direction, timing windows, lead star, strategic framing). For a complex divination tool, this provides a good overview. Minor gap: no mention of error handling or edge cases (e.g., invalid date), but overall sufficient for an agent to understand the output.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% description coverage, so the schema itself documents the parameters well. The description provides minimal additional meaning beyond the schema, only reiterating that omitted hour returns best hour block. Since schema coverage is high, baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool computes a Qi Men Dun Jia reading for a specific date and lists specific outputs (optimal direction, best timing windows, lead star, strategic framing). The verb 'Compute' and resource 'reading' are specific, and the tool name 'direction' aligns with the main output, differentiating it from sibling tools that focus on other Ming methods.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use when a QMDJ reading is needed for a date, but lacks explicit guidance on when to use this tool versus siblings like 'ming_bazi_analyze' or 'ming_fengshui_flying_stars'. No exclusions or alternatives are mentioned, leaving the agent to infer context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ming_zwds_chartB

Compute a Zi Wei Dou Shu (紫微斗數) twelve-palace natal chart. Returns palace highlights, starred positions, 四化 transformations, and synthesis for a specific question domain. Verified against 紫微斗數全書.

ParametersJSON Schema

Name	Required	Description
`birth_date`	Yes	Date of birth in YYYY-MM-DD format.
`birth_hour`	Yes	Hour of birth (0–23). Required for accurate palace placement — Zi Wei palace positions shift by birth hour.
`birth_location`	No	City and country of birth. Used for timezone context.
`gender`	Yes	Gender affects 四化 (sihua) transformation assignments.
`focus_palace`	No	Optional. Focus the narrative on this palace. If omitted, returns highlights across all twelve.

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description should clarify behavioral traits. It states the tool 'computes' and 'returns' data, implying no side effects, but does not explicitly state read-only status, auth requirements, or limitations. The verification claim adds trust but not behavioral transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is highly concise (two sentences) and front-loaded with the core action. Every word adds value: computes, returns specific items, verification.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite the complexity of ZWDS, the description outlines key output categories but does not specify output format or structure. Without an output schema, more detail on the return value (e.g., narrative vs. structured data) would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All five parameters have descriptions in the input schema (100% coverage), so the description adds no extra semantic value. The tool description mentions 'specific question domain' which vaguely relates to the optional focus_palace parameter but does not elaborate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool computes a ZWDS natal chart and lists specific outputs (palace highlights, starred positions, 四化). The mention of verification against 紫微斗數全書 adds credibility. While sibling tool names are diverse, the description does not explicitly contrast with them, but the technical specificity makes its purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to choose this tool over sibling tools. It does not state prerequisites, exclusions, or complementary use cases.

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.

6 tool updatesv1.0.0May 2, 2026
- First observedming_bazi_analyze
- First observedming_fengshui_flying_stars
- First observedming_full_forecast
- First observedming_iching_cast
- First observedming_qmdj_direction
- First observedming_zwds_chart

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored 2026-05-02 01:45 across 6 tools

Disambiguation5/5

Each tool covers a distinct metaphysical system (BaZi, Feng Shui, I Ching, QMDJ, ZWDS) plus a combined forecast, with no overlapping purposes.

Naming Consistency5/5

All tools follow a consistent 'ming_system_action' pattern in snake_case, e.g., ming_bazi_analyze, ming_iching_cast.

Tool Count5/5

With 6 tools covering the main systems of Chinese metaphysics, the count is well-scoped and appropriate for the server's purpose.

Completeness5/5

The tool set covers all major Chinese metaphysical systems (BaZi, ZWDS, QMDJ, Feng Shui, I Ching) and includes a combined forecast, leaving no obvious gaps.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

BaZi Fortune Hub
io.github.tchen6500
BaZi MCP gateway: 14 tools (6 fortune / 5 forum / 3 meta). API key required. Entertainment only.
Art & Culture
2
Wenbu · 问卜 A
app.wenbu
Free BaZi, I Ching, tarot, Zi Wei and bilingual learning tools with transparent methods. No API key.
Games & Gamification Art & Culture Entertainment & Media
61
asktian A
io.github.douglasgan
Chinese metaphysics (bazi, qimen, 5-element) as decision-support tools for AI agents.
AI & Machine Learning
621
Chinese Astrology MCP Server by RoxyAPI A
com.roxyapi
BaZi four pillars, Chinese zodiac, lunisolar calendar and almanac days for AI agents.
Art & Culture
161

Related MCP Servers

taibu
AI & Machine Learning
hhszzzz
F
license
Not graded
quality
B
maintenance
Enables traditional Chinese metaphysics tools like Bazi, Ziwei, and Qimen via MCP, integrating AI analysis for divination and fortune-telling.
Updated 2 days ago (2026-10-14 14:14 UTC)
641
-
命盘 Mingpan
Art & Culture
ChesterRa
A
license
A
quality
A
maintenance
Provides traditional Chinese astrology (Bazi, Ziwei) and divination (Liuyao, Meihua, Qimen, etc.) calculations as MCP tools for AI assistants.
Updated 17 days ago (2026-09-29 16:03 UTC)
2
18
133 npm
118
Apache 2.0
asktian MCP Server
Art & Culture Developer Tools
douglasgan
A
license
A
quality
C
maintenance
Provides Chinese metaphysical tools (bazi, qimen, five elements) as MCP tools for AI agents to give personalized advice on timing, compatibility, and daily energy.
Updated 4 months ago (2026-06-20 09:43 UTC)
5
73 npm
1
MIT
知耘排盘 MCP Server
AI & Machine Learning
whaizaixiang
A
license
A
quality
B
maintenance
Provides MCP tools for Chinese metaphysics, including BaZi (Four Pillars) charting, Liu Yao hexagram casting, lunar conversion, and AI-powered destiny analysis.
Updated 2 months ago (2026-08-17 12:14 UTC)
10
21 npm
MIT

Appeared in Searches

A server for finding information about the Eight Trigrams (八卦) - Chinese philosophy, divination, and Bagua concepts

ming-metaphysics-mcp

vs bazi-mcp от Cantian

Инструменты

Требования к движку

Установка

Шаг 1 — Убедитесь, что движок доступен

Шаг 2 — Установите сервер MCP

Шаг 3 — Добавьте в claude_desktop_config.json

Проверка

Пробелы в конечных точках

Разработка

Переменные окружения

Целевые показатели задержки

Аутентификация

Для полного чтения по пяти движкам

Конфиденциальность

Статус проекта

Лицензия

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches

vs `bazi-mcp` от Cantian

Шаг 3 — Добавьте в `claude_desktop_config.json`