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

Cinco motores de metafísica china como herramientas MCP para Claude Desktop y cualquier cliente compatible con MCP.

vs `bazi-mcp` de Cantian

Dimensión	`bazi-mcp` de Cantian	Ming `ming-metaphysics-mcp`
Artes cubiertas	Solo BaZi	Las cinco — BaZi + QMDJ + ZWDS + Feng Shui + I Ching
Profundidad del motor	Buena implementación de BaZi	9.0–9.5/10 verificado por expertos en los cinco motores
Fuentes clásicas	No documentadas	子平真詮, 淵海子平, 紫微斗數全書 + biblioteca de 108 títulos citados
Calidad de salida	Lecturas competentes	Validado por académicos, bilingüe (EN/ZH), profundidad de nivel de informe
Embudo de consulta	Ninguno	Lectura de maestro disponible vía Ming Bot (enlace por anunciar)
Kua + Ocho Mansiones	❌	✅
Tiempo QMDJ	❌	✅ (cálculo sxtwl Ju)
I Ching (Liu Yao)	❌	✅ (clásico 納甲法)

Related MCP server: 命盘 Mingpan

Herramientas

Herramienta	Motor	Descripción
`ming_bazi_analyze`	BaZi 八字	Carta de los Cuatro Pilares — Maestro del Día, patrón, pilares de la suerte
`ming_qmdj_direction`	QMDJ 奇門	Dirección óptima + ventana de tiempo para una fecha
`ming_zwds_chart`	ZWDS 紫微	Carta natal de doce palacios con transformaciones 四化
`ming_fengshui_flying_stars`	Feng Shui 風水	Número Kua + análisis direccional de las Ocho Mansiones
`ming_iching_cast`	I Ching 易經	Hexagrama mediante el método clásico 納甲法 (Liu Yao)
`ming_full_forecast`	Los cuatro motores de datos de nacimiento	Pronóstico integrado de cinco motores con puntuación de confianza

Requisito del motor

Este paquete es un contenedor (wrapper) MCP. No contiene lógica de cálculo de metafísica; reenvía las llamadas de herramientas a un punto final del motor Ming a través de HTTP. Para usarlo, apunte MING_API_URL a un motor en ejecución.

Dos formas de obtener un motor:

Punto final alojado (preferido, cuando esté disponible). Se anunciará un punto final público de Ming; una vez disponible, configure MING_API_URL para apuntar a él y listo.
Autoalojamiento. El motor Ming en sí es actualmente una implementación de referencia de código cerrado. Si tiene acceso al código base de Ming, ejecute uvicorn api.main:app --port 8000 y apunte este MCP a localhost:8000.

Sin un motor accesible, el servidor MCP se inicia y enumera las herramientas, pero las llamadas a las herramientas devuelven un error HTTP.

Instalación

Paso 1 — Asegúrese de que el motor sea accesible

Consulte "Requisito del motor" arriba.

Paso 2 — Instale el servidor MCP

npm install -g ming-metaphysics-mcp

Paso 3 — Añada a `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"
      }
    }
  }
}

Reinicie Claude Desktop. Las herramientas de Ming aparecerán en la lista de herramientas.

Verificación

En Claude Desktop:

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

Debería obtener una lectura completa de BaZi. Si la herramienta da error, verifique que el motor de Python se esté ejecutando en el puerto 8000.

Brechas en el punto final

Las siguientes capacidades requieren una expansión de FastAPI antes de que funcionen completamente según lo especificado. Cada una está marcada con una nota en la respuesta de la herramienta — no hay fallos silenciosos.

Brecha	Herramienta afectada	Cambio requerido en FastAPI
Mapa de estrellas voladoras anual para un año específico	`ming_fengshui_flying_stars`	`/consult` necesita un parámetro de consulta `year` para calcular las estrellas anuales para años distintos al actual
Parámetro `forecast_year`	`ming_full_forecast`	`/consult` calcula el análisis anual contra el año actual internamente; no acepta un año objetivo
`casting_timestamp` ISO completo	`ming_iching_cast`	`/iching-cast` acepta `date` (YYYY-MM-DD) y `hour_branch` por separado, no una marca de tiempo ISO 8601; solo se reenvía la parte de la fecha
Enrutamiento `goal: "bazi"/"qmdj"/"zwds"`	Todas las herramientas individuales	La especificación asumía que `/consult` aceptaría objetivos de nombre de motor, pero el punto final real utiliza objetivos de propósito (`wealth/career/health/relationship/general`). Las herramientas individuales enrutan a puntos finales dedicados por motor en su lugar (`/analyze`, `/zwds`, `/qmdj`, `/iching-cast`)

Para implementar estrellas voladoras específicas por año o soporte para forecast_year, añada esos parámetros a /consult en api/main.py y actualice los manejadores de herramientas correspondientes aquí.

Desarrollo

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

Variables de entorno

Variable	Predeterminado	Descripción
`MING_API_URL`	`http://localhost:8000`	URL base del motor FastAPI de Ming

Objetivos de latencia

Herramienta	Objetivo
`ming_bazi_analyze`	< 3s
`ming_qmdj_direction`	< 3s
`ming_fengshui_flying_stars`	< 3s
`ming_zwds_chart`	< 5s
`ming_full_forecast`	< 5s
`ming_iching_cast`	< 3s

Si alguna herramienta supera los 5s de forma consistente, verifique el cuello de botella del motor y considere añadir timeout: 10000 a la configuración de MCP.

Autenticación

Ninguna a nivel de contenedor — este servidor es de código abierto y gratuito (licencia MIT). La autenticación, si existe, es aplicada por cualquier punto final al que apunte MING_API_URL.

Para una lectura completa de cinco motores

Una consulta guiada de cinco motores (BaZi + ZWDS + QMDJ + Feng Shui + I Ching sintetizados por el Maestro Chen) está disponible a través del bot de Telegram de Ming. El enlace se publicará una vez que el bot esté en versión beta pública.

Privacidad

Este contenedor MCP en sí no recopila datos. Reenvía los argumentos de su herramienta (fecha de nacimiento, hora, género, texto de la pregunta) a cualquier MING_API_URL que haya configurado. Si apunta a un punto final alojado, ese punto final recibe los datos — lea su política de privacidad. Si se autoaloja, nada sale de su red.

Los datos de nacimiento son sensibles. Si está configurando esto para usuarios finales, sea explícito sobre qué punto final recibe sus entradas.

Estado del proyecto

Este paquete está en la versión 1.0.0. La superficie del protocolo MCP (6 herramientas, esquemas JSON, formas de respuesta) es estable. El motor Ming subyacente evoluciona más rápido — los cambios numéricos menores en las respuestas de las herramientas son normales.

Las contribuciones son bienvenidas — consulte CONTRIBUTING.md.

Licencia

MIT — consulte 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 de Cantian

Herramientas

Requisito del motor

Instalación

Paso 1 — Asegúrese de que el motor sea accesible

Paso 2 — Instale el servidor MCP

Paso 3 — Añada a claude_desktop_config.json

Verificación

Brechas en el punto final

Desarrollo

Variables de entorno

Objetivos de latencia

Autenticación

Para una lectura completa de cinco motores

Privacidad

Estado del proyecto

Licencia

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches

vs `bazi-mcp` de Cantian

Paso 3 — Añada a `claude_desktop_config.json`