Tu Vi Chart

Cast a Tu Vi birth chart

tuvi_chart

Read-onlyIdempotent

Use this when someone wants their Tu Vi (Zi Wei Dou Shu, 紫微斗数) birth chart or its reading. Pass birth_date (solar, YYYY-MM-DD, 1921 to 2100), birth_time (local HH:MM, 24-hour) and gender. Optional: calendar (vi, the default, or zh), leap_month (split, same or next), late_zi (next_day or same_day for a 23:00 birth), topics. Returns the lunar date, the 12 palaces with the 14 main stars, 14 minor stars, the four transformations and the 10-year periods, in Vietnamese and Chinese, plus readings for births from 1950 to 2026 from an open CC BY dataset, each with citations to the classic 紫微斗数全书. Keep the attribution with any reading you repeat. Readings are cultural, not predictions.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`gender`	Yes	Gender at birth; it sets the direction of the 10-year periods
`topics`	No	Reading topics to return; all 13 when left out
`late_zi`	No	A birth from 23:00 counts as the Tý hour of the next day (next_day, the common rule) or of the same day	next_day
`calendar`	No	Lunar calendar and tradition: vi is the Vietnamese calendar (UTC+7 from 1968, UTC+8 before) with Mệnh chủ by year branch; zh the Chinese one (UTC+8) with 命主 by Life-palace branch	vi
`birth_date`	Yes	Birth date on the solar (Gregorian) calendar, YYYY-MM-DD, from 1921 to 2100
`birth_time`	Yes	Local clock time of birth, HH:MM in 24-hour form. 23:00 to 00:59 is the Tý hour
`leap_month`	No	A birth in a leap month counts as: split, the same month up to day 15 and the next month after it; same; or next	split

Output Schema

TableJSON Schema

Name	Required	Description	Default
`chart`	Yes
`input`	Yes
`readings`	Yes
`disclaimer`	Yes
`attribution`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 21, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare read-only, non-destructive, idempotent, closed-world behavior, and the description adds real context on top: the exact return payload (lunar date, 12 palaces, 14 main + 14 minor stars, four transformations, 10-year periods, bilingual output), the data-availability window for readings (1950-2026, CC BY), the citation requirement, and the cultural-not-predictive framing.

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?

Front-loaded with the usage trigger, then required params, then optional rules, then the return shape and caveats. Dense but every sentence carries information; the sole cost is that parameters and return values are packed into one long block rather than separated.

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

Completeness5/5

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

For a read-only chart tool with a rich output schema, the description still covers what the output schema cannot: date-range bounds, the 23:00 Tý-hour and leap-month edge cases, the reading dataset's coverage window, and the attribution obligation. Nothing needed to invoke or interpret the result is missing.

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 schema already documents every parameter including defaults and the calendar/leap_month/late_zi semantics. The description restates required vs optional and repeats ranges that live in the schema, adding little interpretation beyond it. Baseline 3 is appropriate when structured fields carry the meaning.

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?

States a specific verb (cast) and resource (Tu Vi / Zi Wei Dou Shu birth chart or its reading), plus the aliases an agent might encounter. Siblings (get_feedback_reply, submit_feedback) are unrelated, so no differentiation is needed and none is owed.

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?

Opens with an explicit trigger: 'Use this when someone wants their Tu Vi ... birth chart or its reading.' That is a clear when-to-use condition. There are no viable alternative tools to route against, so the absence of exclusions is acceptable.

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

All Tu Vi Chart tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.