命盘 Mingpan

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.3
Disambiguation5/5
Each tool targets a distinct function within its respective divination system (e.g., basic charting vs. yearly/monthly/daily analysis). The systematic prefix (bazi_, ziwei_, qimen_, etc.) ensures clear differentiation across systems, with no overlapping purposes.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern using snake_case: system prefix + descriptive suffix (e.g., bazi_basic, qimen_zeri). No mixing of conventions; the pattern is uniform across 17 tools.
Tool Count5/5
With 17 tools covering six different divination systems, the count is well-scoped for the server's purpose. Each system has a core set of tools (basic + lifecycle analysis), and no excessive or trivial tools exist.
Completeness4/5
The tool set provides comprehensive coverage for bazi and ziwei (including yearly, monthly, daily, and decade luck), and qimen (basic, use-spirit analysis, and date selection). However, daliuren, liuyao, and meihua have only basic charting tools, leaving some advanced analysis gaps.
Average 3.9/5 across 17 of 17 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on December 30, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose all behavioral traits. It does not mention return format, error handling, mutability, or side effects. The tool likely returns a list, but no output schema or description of response is given, leaving behavior opaque.
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?
Description is well-structured with bullet points, concise at about 10 lines, and front-loaded with a clear definition. Every sentence adds value except perhaps some redundancy in the calculation comparison.
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?
Given 11 parameters and no output schema, the description is incomplete. It explains the concept well but lacks details on output structure, pagination, or how results are returned. For a complex tool, more completeness is needed, especially about the response.
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 100%, so baseline is 3. Description adds no further parameter-specific details beyond what the schema provides. The general explanation of 小限 adds context but does not enhance parameter understanding.
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?
Description clearly states tool lists '紫微小限' (minor limit) and defines it as an annual fortune unit with specific attributes. It distinguishes from '流年' (yearly flow) and mentions hierarchy, but does not explicitly differentiate from sibling tools like 'ziwei_daxian' or 'ziwei_liunian', which hampers precise purpose clarity.
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?
Description provides context on what 小限 is and contrasts it with 流年, implying when to use. However, it lacks explicit guidance on when to use this tool versus other Zi Wei tools (e.g., for major limits or daily flow), and no prerequisites or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes return fields but does not disclose any side effects, limitations (e.g., maximum year range), or required external context (e.g., that birth data is used to compute the base chart). The tool appears to be read-only, but this is not explicitly stated.
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 extremely concise: a single sentence stating purpose, followed by a bullet list of returned fields. Every element adds value, and there is no extraneous information. It is front-loaded with the main action.
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?
Given the complexity of 11 parameters and no output schema, the description covers the basic output but lacks context on how to interpret the results (e.g., meaning of 流年四化) or how this tool fits into the larger Zi Wei Dou Shu workflow. It is adequate but not thorough.
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% for all 11 parameters, so the baseline is 3. The description adds no extra meaning to parameters beyond what is already in the schema; it only lists output fields. Therefore, it does not improve parameter understanding.
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 it returns a '紫微流年列表' (Ziwei annual flow list) for a specified year range, listing specific fields like year, Gan-Zhi, and stars. This distinguishes it from sibling tools focused on daily (liuri), monthly (liuyue), or decade (daxian) periods, though it doesn't explicitly name them.
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 states it is '用于分析多年运势趋势' (used for analyzing multi-year fortune trends), implying its use for trend analysis. However, it does not explicitly indicate when to use this tool versus alternatives like ziwei_liuri or ziwei_liuyue, or any prerequisites like needing a natal chart first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses performance targets and the general workflow (scoring, filtering), but does not explicitly state if the tool is read-only, side-effect free, or any authorization requirements. Behavioral traits are partially covered.
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 well-structured with clear sections (Input, Scoring, Filters, Output, Performance). It is relatively concise given the complexity, though some details like scoring dimensions could be streamlined. No redundant statements.
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 16 parameters and no output schema, the description covers input, scoring dimensions, filter conditions, output structure, and performance goals. It is comprehensive for a specialized tool, though return value details could be more formal.
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 baseline is 3. The description groups parameters and explains scoring dimensions and filters, adding some context. However, it does not provide new syntax or meaning beyond what the schema already offers.
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's function as '奇門遁甲擇日功能' (Qi Men Dun Jia date selection) and '在指定日期範圍內篩選吉時' (filter auspicious times within a date range). It distinguishes from sibling tools like qimen_basic and qimen_yongshen by focusing specifically on date selection for various event types.
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 does not provide explicit guidance on when to use this tool versus alternatives. It lists inputs and outputs but lacks scenarios or exclusions. Context suggests it is for date selection, but no comparison to sibling tools is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It describes the output structure and input requirements, but lacks details on side effects, error handling, or limitations. For a calculation tool, this is moderately transparent 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two paragraphs, front-loading the purpose. It uses clear language and lists output items. Minor improvement could be using bullet points, but it is still efficient.
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?
No output schema exists, but the description partially compensates by listing output components. However, it omits exact output format or field details, which is important for a complex tool. Given the 11 parameters, the description is adequate but not fully complete.
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%; each parameter already has a clear description. The tool description adds context about output content and the necessity of gender, but does not significantly enhance understanding beyond the schema.
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 calculates a Ziwei Doushu natal chart (基础排盘) and lists specific output components (12 palaces, stars, brightness, auxiliary stars, etc.). It is distinct from sibling tools like ziwei_daxian or ziwei_liunian, which focus on different time periods.
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 explains what the tool does but provides no explicit guidance on when to use it vs. alternatives. It implies it is for obtaining the basic natal chart, but does not mention when to use siblings for detailed fortune analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It describes the output but does not disclose behavioral traits such as whether it is read-only, requires authentication, or has rate limits. The description does not warn about any side effects.
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 concise with a brief introductory sentence followed by a bullet list of output fields. It is front-loaded with the purpose and uses minimal words.
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 no output schema, the description adequately explains what the tool returns (list of decade periods with specific attributes). It covers the key output elements, though it does not specify the exact data structure (e.g., JSON format). Still, it is sufficient for understanding the return value.
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%, with each parameter described in the schema. The description does not add new meaning beyond the schema; it focuses on the output, not the parameters.
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 lists the lifelong decade periods (大限周期) with specific fields (starting virtual age, Gregorian years, palace name, main stars, four transformations). This distinguishes it from sibling tools that cover yearly, monthly, or daily fortunes.
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 it is used for understanding the overall framework of life stages, but it does not explicitly state when to use this tool versus alternatives (e.g., ziwei_basic, ziwei_liunian). No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 clearly explains the output includes current periods (大限, 小限, 流年, 流月, 流日), calendar conversion, ganzhi days, and the complete four-transformation system. It also notes the special representation of leap months with negative numbers. This provides good behavioral context beyond just stating it lists daily fortunes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph with bullet points, making it somewhat structured. However, it is a bit verbose with excessive punctuation and line breaks. Each sentence serves a purpose, but the formatting is not ideal for quick scanning. It could be more concise by removing redundant phrasing.
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 11 parameters, no output schema, and no annotations, the description is fairly complete. It explains the output content (daily fortunes, calendar data, transformations) and a special behavior (leap month representation). It does not explain the return format or pagination, but the listed items give a good understanding of what to expect. For a complex tool, this is adequate.
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 100%, so every parameter has a description in the schema. The description itself adds minimal extra semantic value beyond what the schema already provides. It reiterates the leap month convention, which is already in the schema's description for 'lunarMonth'. There is no significant additional detail about parameter relationships or formatting.
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 states the tool provides a list of daily fortunes for a specified lunar month, including various calendar and astrological details. It clearly identifies the resource (daily flow) and verb (list). While it distinguishes from siblings like 'ziwei_liunian' and 'ziwei_liuyue' by focusing on '流日', it does not explicitly compare with all siblings, leaving some ambiguity.
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 mentions '用于精细的日期选择' (used for fine date selection), implying usage context. However, it does not provide explicit guidance on when to use this tool versus alternatives like 'ziwei_basic' or 'bazi_liuri', nor does it mention any prerequisites or limitations. The context is implied but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral transparency. It describes the output but does not disclose any potential side effects, authentication needs, or rate limits. For a read-only calculation tool, this is adequate but not exceptional.
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 concise, front-loaded with the title, and uses bullet points for clarity. Every sentence adds value, and there is no wasted text.
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 complexity of the tool (10 parameters, no output schema), the description provides a useful overview of the output structure. It lacks details on data types or exact format, but is sufficient for an agent to call the tool and understand the response.
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?
The input schema has 100% description coverage, so each parameter is already explained. The description adds marginal value by listing output fields, but does not enhance parameter understanding beyond the schema. 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's purpose: to list the Da Yun (great fortune) cycles of a person's life. It specifies the output fields (stem-branch, starting age, years, direction, start age), making it distinct from other Bazi tools.
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 includes a usage context: '用于了解人生各阶段的运势大框架' (used to understand the general framework of life stages). However, it does not specify when not to use this tool or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the algorithm for time-based gua, the return format (Markdown), and components. However, it does not mention safety, side effects, or error handling, but the tool is inherently read-only and non-destructive.
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 well-structured with a clear introduction, method list, output details, and algorithm. It is efficient with no superfluous content, though a slightly more concise algorithm description could improve readability.
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 9 parameters and no output schema, the description adequately covers input methods, required parameters, and output components. However, it omits mention of the isLunar parameter and the number method algorithm is vague; still, it is reasonably complete for the domain.
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% with all parameters described individually. The tool description adds context about the two methods and algorithm but does not significantly enhance per-parameter meaning beyond the schema. 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 identifies the tool as generating Meihua Yishu basic chart, specifying two methods (time and number) and listing output components. This differentiates it from other Chinese divination siblings (e.g., bazi, liuyao) as a distinct system.
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 explains the two available methods and what the tool returns, but does not explicitly state when to use this tool versus alternatives. It assumes domain knowledge that Meihua Yishu is for certain scenarios, but lacks direct guidance on exclusion or comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the output (list of daily fortunes with context) but does not mention whether it modifies state, requires prior setup, or performance characteristics. It is adequate for a read-only retrieval 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?
A concise paragraph with key points in bullet form. Front-loaded with the tool's purpose. No unnecessary words.
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 11 parameters and no output schema, the description provides a useful summary of output fields (bullets) and a usage hint. It lacks explanation of how to interpret the context fields, but is otherwise complete enough for an AI to invoke correctly.
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 all parameters well. The description adds no additional parameter meaning beyond listing output fields, which is baseline acceptable.
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 returns daily fortune (运势) for a month with context (大运、流年、流月、日期、干支), using a specific verb '返回' (returns). It distinguishes from siblings like bazi_liunian (yearly) and bazi_liuyue (monthly) by specifying it's daily (流日).
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 says it's '用于精细的日期选择' (for fine date selection), indicating when to use. It does not explicitly state when to avoid or name alternatives, but the context of siblings makes the usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it returns 12 monthly fortunes, uses solar terms (not lunar), and describes output fields (stem-branch month, solar term start/end, Gregorian date range). This adequately informs the agent about the tool's behavior, though it omits details like error handling or rate limits, which are less critical for a read-only 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?
The description is concise and well-structured: a brief header, a bulleted list of key points, and a summary of output. Every sentence is informative with no fluff. It front-loads the critical distinction (solar vs lunar month) and provides essential context efficiently.
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?
The description explains the core concept of solar terms and output format, but it does not clarify how input parameters (birth date, gender, etc.) relate to the query year (ganzhiYear). An agent might not understand why birth data is needed for a monthly fortune tool. The output schema is absent, but the description partially compensates. Some context about the computation is missing, making it adequate but not fully complete.
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 100%, so baseline is 3. The description does not add significant parameter-specific meaning beyond the schema. It mentions '指定年份' but does not elaborate on the 'ganzhiYear' parameter's dual type (string or integer) or other inputs. The output format description is useful but not parameter semantics. No extra value added.
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 returns a list of 12 monthly fortunes for a given year, using solar terms (节气月) instead of lunar months. It distinguishes from sibling tools like bazi_liunian (yearly) and bazi_liuri (daily) by specifying the monthly scope and output details like stem-branch months and solar term boundaries.
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 explicitly warns that the tool uses solar terms, not lunar months, and provides concrete examples of boundaries (e.g., 立春, 寅月). This clarifies when to use it. However, it does not explicitly state alternatives or when not to use it, such as comparing with bazi_liunian or bazi_liuri, leaving room for improvement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 discloses key behaviors: uses lunar months, returns specific items like current year, month, and fortune details. However, it does not mention permissions, rate limits, or side effects.
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 fairly concise and organized with bullet points, front-loading the key point about lunar months. Minor redundancy could be trimmed, but overall good.
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 complexity (10 params, no output schema), the description provides a good overview of what the tool does and returns. It could explain some parameters like longitude and the output format more, but it's adequate.
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 100%, so baseline is 3. The description does not add significant meaning beyond the schema; it focuses on output rather than parameter 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 clearly states the tool returns '流月运势' (monthly fortunes) for a given year, using lunar months. It distinguishes from sibling tools by specifying it's about monthly fortunes, while siblings cover basic, day, hour, etc.
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 mentions '用于规划年度活动时机' (used for planning annual activity timing) and emphasizes using lunar months. However, it does not explicitly state when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description details inputs like longitude for true solar time and lunar calendar conversion, and lists comprehensive output. It does not mention safety traits but the tool is inherently read-only.
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 concise, with a clear opening sentence and bullet-pointed output list. Every sentence adds value 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 complexity of Bazi and no output schema, the description adequately covers input adjustments and output components. It could mention error handling or validation, but is sufficient for typical use.
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%, and the description adds value by explaining the purpose of gender (for DaYun direction) and longitude (true solar time), which are not fully detailed in the schema descriptions.
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 '计算八字命盘（基础排盘）' and lists all output components, distinguishing it from sibling tools like bazi_dayun and bazi_liunian which focus on specific aspects.
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 this is the primary tool for basic Bazi calculation, but lacks explicit guidance on when to use alternatives or preconditions such as requiring accurate birth time.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
无注释，描述承担全部负担，清楚说明工具只排盘不解读，输出Markdown格式，但未提及可能的错误处理或性能特征，整体足够。
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?
描述较长但信息丰富，结构清晰（介绍->输出列表->注意事项），每句话有贡献，但可稍作精简以提升可读性。
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?
对于复杂的大六壬排盘工具，描述覆盖了所需输入、详细输出格式（Markdown）、注意事项，无输出模式但描述弥补，满足使用需求。
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?
输入模式覆盖100%参数，描述重复主要参数但未增加超出模式的语义细节（如guirenMethod仅说明“貴人起法”），与schema一致。
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?
描述明确说明工具执行大六壬基础排盘，列出详细输出内容（天地盘、四课、三传等），与兄弟姐妹工具（八字、六爻等）明显区分，动词“排盤”具体明确。
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?
描述了输入需求（节气、完整干支）和工具局限（仅排盘不解读），提供了使用上下文，但未明确排除其他工具或说明何时选择大六壬而非其他占卜方法。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the tool's behavior: it takes yao values and date/time, returns a Markdown chart with many elements. It explains the meaning of yao values (6=old yin moving, etc.) and input order (bottom to top). No contradictions or omissions regarding side effects, but it doesn't mention error handling or performance constraints.
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 well-structured with bullet points listing output components and yao value explanations. It is concise enough, though the enum values are repeated from the schema. The front-loaded purpose sentence is clear.
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?
Given there is no output schema, the description thoroughly explains the return values (all chart components) and input semantics. It covers the yao values, order, and date parameters. This is comprehensive for a complex 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?
Schema coverage is 100%, providing baseline 3. The description adds value by explaining the yao value meanings (6/7/8/9) and the bottom-to-top order beyond the schema descriptions. It also notes the output format (Markdown), which aids understanding.
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's purpose: '六爻排盤（基礎排盤）' (Six Yao Charting - Basic). It lists the specific components returned (本卦/變卦, 六親, 六神, etc.), distinguishing it from sibling tools like bazi, ziwei, etc., which are different Chinese divination systems.
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 explains that the tool is used to generate a complete Six Yao chart from yao values and a starting time. However, it does not explicitly state when not to use it or provide direct alternatives. The sibling tools list implies differentiation, but no clear guidance on choosing between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It comprehensively lists the analysis components: identification of main/auxiliary yong shen, status (旺相休囚死), empty/grave/torture, relationship with day stem, pattern effects, host-guest analysis, optional year stem and gods information, and a scoring system. It also notes output as structured Markdown. No side effects are mentioned, but the tool is likely read-only.
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 well-structured with bullet points and clear sections. It is informative without being overly verbose. While somewhat lengthy, the complexity of the topic justifies the length.
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 complexity of the tool and the absence of an output schema, the description adequately covers the analysis process, parameters, and output format. It mentions the prerequisite of a basic pan, but could explicitly reference the sibling tool qimen_basic. The scoring system is noted but not detailed, which is acceptable.
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 value by explaining the purpose of key parameters like shiLei (the 14 affair types are listed), nianGan (year stem for optional analysis), and includeShenSha. This context goes beyond the schema descriptions.
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 is for '奇門遁甲用神分析' (Qi Men Dun Jia Yong Shen analysis), specifying it operates on top of a basic pan and supports 14 specific affair types. This distinguishes it from sibling tools like qimen_basic (which likely handles the basic pan) and qimen_zeri (day selection).
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 provides a clear context: it should be used after obtaining a basic pan ('在基礎排盤基礎上'). It also lists 14 affair types for which it is intended. However, it does not explicitly state when not to use it or provide direct comparisons to sibling tools, though the specialization is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses what the tool does: it returns a list of annual data with specified fields for a given year range. There are no side effects or destructive actions implied, and the output structure is clearly outlined. This meets the burden for 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 extremely concise, using a short paragraph with a bullet list for output fields. Every sentence adds value, and the key information is front-loaded. No unnecessary verbosity.
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 there is no output schema, the description adequately explains what is returned (year, gan-zhi, age, dayun). It covers the core functionality for analyzing yearly trends. However, it omits details about how optional parameters like longitude or isLunar affect the output, which could be added for 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?
Schema coverage is 100%, so baseline is 3. The description does not add new meaning beyond the schema; it only summarizes the input (e.g., 'startYear/endYear' are mentioned). No extra detail on how parameters affect computation is provided.
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 returns '流年信息' (annual fortune info) for a year range, listing specific fields (公历年份, 干支年, 虚岁, 所属大运). This distinguishes it from siblings like bazi_dayun (period luck) and bazi_liuri (daily luck) by focusing on yearly analysis over a range.
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 explicitly says '用于分析多年运势趋势' (used for analyzing multi-year trends), indicating when to use it. However, it does not mention when not to use it or compare with alternatives like bazi_dayun, leaving some ambiguity for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It explains the output format (Markdown with ASCII 9-grid), lists all components, and describes options. No contradictions, and no destructive behavior is implied.
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 well-structured with sections and bullet points, making it easy to parse. It is fairly long but every part contributes necessary context for a complex tool. Could be slightly more concise, but front-loaded with purpose.
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?
Given the complexity of Qi Men Dun Jia, the description covers input parameters, output contents, optional settings, and even background context. No output schema exists, but the description compensates by enumerating output elements. It is complete for an agent to use correctly.
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 description coverage is 100%, so baseline is 3. The description adds value by explaining the purpose of each pan type, pan style, and zhiRunMethod in detail, beyond what the schema provides. This enriches the agent's understanding.
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's function: '奇門遁甲排盤（基礎排盤）' and provides a detailed list of outputs and supported options. It distinguishes itself from siblings implicitly by being the basic chart-casting tool, while siblings like 'qimen_yongshen' and 'qimen_zeri' are specialized.
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 provides clear guidance on when to use different pan types (時盤, 日盤, etc.) and pan styles, but does not explicitly contrast with sibling tools or specify when not to use this tool. The context is sufficient for an agent to infer usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mingpan MCP server](https://glama.ai/mcp/servers/ChesterRa/mingpan/badges/card.svg)](https://glama.ai/mcp/servers/ChesterRa/mingpan)

Score Badge

Copy to your README.md:

[![mingpan MCP server](https://glama.ai/mcp/servers/ChesterRa/mingpan/badges/score.svg)](https://glama.ai/mcp/servers/ChesterRa/mingpan)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ChesterRa/mingpan'

If you have feedback or need assistance with the MCP directory API, please join our Discord server