ziwei-mcp

by SiwuXue

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v1.0.4
Disambiguation2/5
Several tools have overlapping scopes. `interpret_chart` and `intelligent_interpretation` both provide chart interpretation, while `analyze_fortune` and `analyze_life_timeline` both cover time-based luck analysis. `career_guidance` also overlaps with `interpret_chart`'s career analysis, creating ambiguity.
Naming Consistency3/5
The majority of tools follow a verb_noun pattern (e.g., `analyze_fortune`, `generate_chart`), but four tools are noun phrases (`intelligent_interpretation`, `career_guidance`, `health_analysis`, `educational_guidance`), which breaks consistency. The pattern is still readable overall.
Tool Count5/5
12 tools is well-scoped for a specialized astrology server, covering chart generation, interpretation, fortune analysis, compatibility, date selection, and life guidance without being excessive. Each tool appears to address a distinct aspect of the domain.
Completeness4/5
The tool set covers the core lifecycle of a Zi Wei Dou Shu reading: generate chart, interpret, analyze time dimensions, and provide domain-specific guidance. Minor gaps exist (e.g., no explicit wealth-specific tool, but `interpret_chart` covers wealth), but overall coverage is strong.
Average 2.7/5 across 12 of 12 tools scored. Lowest: 1.7/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
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral context. It only states 'guidance and decision support' without disclosing what the tool does internally, what kind of results it produces, or how it uses inputs like chartId and currentAge. No limitations or side effects are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified rather than concise. It provides no substantive details, making it a placeholder that does not effectively inform the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters (3 required, 2 enums) and no output schema or annotations. The description does not explain the tool's behavior, return format, or how parameters are used, making it completely inadequate for a tool of this complexity.
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. The description adds no parameter-specific meaning, but per the baseline rule for high schema coverage, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '职业发展指导和决策支持' (career development guidance and decision support) essentially restates the tool name without specifying a concrete action, input, or output. It does not distinguish from siblings like educational_guidance or analyze_fortune.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of specific scenarios, user goals, exclusions, or comparisons to other tools, leaving the agent without any selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Education and learning guidance' with no information about what the tool does, what inputs affect, what output is produced, or any side effects. This is essentially a label, not a behavioral description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but under-specification is not conciseness. A single vague phrase without structure or detail does not earn efficiency credit; it is under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters (3 required), enums, and no output schema, this description is completely inadequate. It provides no information about expected behavior, return values, or how parameters relate to the tool's function.
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 5 parameters, so per rubric baseline is 3. The description adds no additional parameter semantics, but the schema already provides short descriptions for each field, so no deduction is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description '教育和学习指导' (Education and learning guidance) essentially restates the tool name 'educational_guidance' without specifying concrete action or output. It fails to distinguish from sibling tools like career_guidance or health_analysis, providing no actionable detail about what kind of guidance is delivered.
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 usage context is provided. The description does not indicate when to use this tool versus alternative guidance tools, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 of disclosing behavior. It only states a vague purpose and gives no information about side effects, required permissions, return values, or any constraints. This is a significant gap for a tool with health-related parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (one phrase), but this is under-specification rather than effective conciseness. It lacks structure, such as separating purpose from usage details, and fails to convey necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, an enum with 3 analysis types, an array of health concerns, and no output schema or annotations. The description gives no context about what the health analysis entails, what advice is provided, or how the input parameters affect the result. It is completely inadequate for the tool's complexity.
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 schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds no parameter-specific information beyond what the schema provides. It doesn't clarify the meaning of 'chartId', 'currentAge', 'analysisType', or 'healthConcerns' beyond their literal names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '健康分析和养生建议' (health analysis and wellness advice) indicates the tool's subject matter but not a specific action or scope. It is a bit tautological with the name 'health_analysis' but adds 'wellness advice.' It does not clearly distinguish it from sibling tools like 'analyze_life_timeline' or 'career_guidance.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 use this tool versus alternatives. There is no mention of appropriate contexts, prerequisites, or exclusions. Sibling tools exist, but the description doesn't position this tool among them.
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 the full burden of behavioral disclosure. It only states what the tool does without mentioning what the output looks like, whether it performs any side effects, or how the analysisDepth parameter affects behavior. It does not state whether the operation is read-only or irreversible, though 'analyze' implies a read operation.
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 a single, extremely concise sentence with no wasted words. It front-loads the core function clearly. However, it is so brief that it borders on under-specification, though this is more a completeness issue than conciseness – the sentence structure itself is efficient.
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 the tool takes two complex nested chart objects and has an analysisDepth parameter, the description is incomplete. There is no output schema, no annotations, and no mention of what the analysis will provide (e.g., a score, a report, explanations). It also does not explain the difference between 'basic' and 'comprehensive' depth. The description is minimal even for a straightforward analysis tool.
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 three parameters (chart1, chart2, analysisDepth) described. The description adds slight clarity by specifying '两人的' (two people's) charts, reinforcing what chart1 and chart2 represent, but it does not provide additional syntax, format, or deeper meaning beyond the schema. This aligns with the baseline of 3.
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's purpose: '合婚分析' (marriage compatibility analysis) and '分析两人的紫微斗数命盘匹配度' (analyze the compatibility of two people's Zi Wei Dou Shu charts). It specifies the action (analyze) and resource (chart compatibility), distinguishing it from generic chart generation or interpretation tools. However, it does not explicitly differentiate from the sibling tool 'analyze_relationships', which could be seen as overlapping.
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 usage guidance is provided. The description does not specify when to use this tool instead of alternatives like 'analyze_relationships' or other analysis tools. It lacks any mention of prerequisites, typical use cases, or scenarios where this tool should not be used.
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?
由于没有任何注释，描述需完全承担行为透明度的责任，但描述仅是一句概括，未说明分析的具体过程、所需的输入条件、返回结果的性质，也未提及是否受限于某些前提（如需要对方命盘）。
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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
该工具具有4个参数、枚举类型和多个兄弟工具，且无输出schema和注释，描述仅一句概述，未能说明分析结果的返回形式、何时需要提供对方命盘ID、各关系类型的区别，以及与其他分析工具的差异，信息严重不足。
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覆盖了所有参数，且说明清晰，描述本身没有为参数添加额外语义。根据规则，当schema覆盖率高时，基线为3分。
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?
描述明确说明该工具用于分析人际关系，并列举了家庭、朋友、同事等示例，具有明确的动词和资源。但没有与兄弟工具（如analyze_compatibility）进行显式区分，因此未达到最高分。
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?
描述中未提供任何关于何时使用此工具、何时使用其他工具（如analyze_compatibility）的指导，也没有提及任何替代方案或前置条件。
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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only restates the core action of generating a chart. It does not disclose any side effects, special requirements, output format, or potential edge cases (e.g., invalid birth time). This is minimal and insufficient for a tool with no annotation support.
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 a single, compact sentence with no wasted words. It front-loads the primary action and is appropriately sized for a straightforward tool. Every word earns its place.
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 no output schema and no annotations, the description should explain what the tool returns, how it fits into the larger workflow (e.g., for subsequent interpretation), and any relevant context. It does none of these. The tool has many siblings, but the description does not position it relative to them, leaving the agent without enough context to plan a multi-step flow.
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% (all parameters have descriptions in the input schema). The description adds no extra parameter information beyond what the schema already provides. This aligns with the baseline of 3 for high schema coverage.
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's function clearly: '生成紫微斗数命盘，根据出生信息排盘' which means 'Generate Zi Wei Dou Shu chart, arrange chart based on birth information.' This is a specific verb+resource combination. It distinguishes from siblings like interpret_chart and generate_visualization, though it does not explicitly name them or delineate boundaries, so it falls short of a 5.
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 guidance is provided on when to use this tool versus alternatives. The description does not mention any prerequisites, limitations, or scenarios where another tool (e.g., interpret_chart) would be more appropriate. The agent is left to infer usage from the name and context.
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?
With no annotations, the description carries the full burden for behavioral disclosure, yet it only says 'generate visualization chart' without explaining side effects, output format, dependencies, or error behavior. It does not reveal whether the operation is read-only, what happens on invalid input, or what the return artifact looks like. This is a significant gap.
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 a single short sentence that is front-loaded with the main action. It avoids unnecessary fluff and is appropriately concise, though it could have included a bit more detail without losing efficiency.
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?
Without output schema or annotations, and with 5 parameters, the description is under-specified. It does not explain return values, output delivery (e.g., file path, base64, URL), required sequence with generate_chart, or any limitations. The tool's complexity is not matched by the description's brevity.
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 description provides no parameter-level details, but the input schema covers 100% of parameters with clear descriptions and enums (e.g., colorScheme, outputFormat). The phrase 'supports multiple styles and formats' loosely references these options but adds no specific meaning beyond the schema, so the baseline of 3 applies.
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 action (generate) and resource (命盘 visualization chart), and mentions support for multiple styles and formats. It does not explicitly differentiate from sibling tools like generate_chart, but the term '可视化' (visualization) implies a distinct output-focused purpose.
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?
There is no guidance on when to use this tool versus alternatives. The description lacks context such as prerequisites, ordering with generate_chart, or cases where other tools would be more appropriate. The schema hints that chartId comes from generate_chart, but the description itself provides no usage direction.
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?
With no annotations provided, the description must carry the burden of behavioral disclosure. It fails to mention that the tool is read-only, what output format to expect, or any side effects. It simply restates the high-level purpose without deeper behavioral context.
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 a single sentence, front-loaded with the core purpose, and contains no filler. Every word contributes to stating what the tool does.
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?
The description is minimal for a complex interpretation tool. It does not explain the output format, the role of focusAreas, or how it differs from sibling tools. With no annotations and no output schema, the description leaves the agent without enough context to use the tool effectively.
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 schema description coverage is 100%, with both chartId and focusAreas having meaningful descriptions. The tool description adds no extra parameter details, so the baseline of 3 is appropriate.
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 interprets a Zi Wei Dou Shu chart and provides personality, career, and wealth analysis. However, it does not differentiate from sibling tools like intelligent_interpretation or analyze_life_timeline, so it's clear but lacks sibling distinction.
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 guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or comparison with similar analysis tools among the siblings.
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?
With no annotations, the description must explain behavioral traits itself. It only delivers a high-level promise of AI-powered analysis, without disclosing whether the operation is read-only, what format the analysis takes, or any side effects. This is insufficient for an agent to predict the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no filler words, earning high marks for brevity. While concise, it omits necessary detail for a tool with 4 parameters and nested objects, but the conciseness dimension rewards efficiency.
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?
The tool has a complex required 'chart' object and no output schema, so the description should clarify what analysis is produced and how to interpret the response. It does not, and it also fails to address the close relationship with sibling interpretation tools, making the description contextually incomplete.
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 four parameters (chart, lifeStage, focusAreas, currentConcerns) have detailed descriptions in the schema, including enums for lifeStage and focusAreas. The description adds no additional semantic context, so it relies entirely on the schema to convey parameter meaning.
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 'AI智能解盘' (AI intelligent interpretation) and '个性化深度命盘解析' (personalized in-depth destiny chart analysis), clearly identifying the tool as an interpretation tool for natal charts. However, it offers no differentiation from the sibling tool 'interpret_chart', so it cannot help an agent choose among overlapping options.
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 phrase '个性化深度' implies the tool is suited for personalized, deep analysis, but the description does not explicitly state when to prefer this over siblings like 'analyze_fortune' or 'interpret_chart'. There is no guidance on exclusions or prerequisites, leaving usage context ambiguous.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it offers no details about output format, limitations, or side effects. It only mentions that it selects dates, without explaining the selection process or result structure.
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 a single, direct sentence with no redundant wording. It front-loads the main function ('择日功能') and is appropriately sized for a clear purpose.
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 the tool has 4 parameters, nested objects, and no output schema or annotations, the description is under-specified. It does not explain expected return values, how different event types affect selection, or how the date range is used, making it incomplete for an agent to invoke confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds little beyond the schema. It mentions 'personal birth chart' and 'auspicious days,' which loosely maps to chart and dateRange, but it does not clarify eventType, timePreference, or the dateRange constraints. With 75% schema coverage, the missing top-level dateRange description is not compensated.
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: '择日功能，根据个人命盘选择适合的吉日良辰' (date selection function, selects auspicious days/times based on personal birth chart). It has a specific verb (select) and resource (auspicious dates), and it distinguishes itself from sibling tools like analyze_fortune or generate_chart by its focus on date selection.
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 use this tool versus alternatives, no prerequisites, and no exclusions. It only states what the tool does, leaving the agent to infer usage context.
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?
With no annotations, the description carries the full burden for behavioral disclosure, but it does not mention whether the operation is read-only, what output format to expect, or any limitations. It only names the analysis scope, which is insufficient for an un-annotated 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 a single sentence, front-loaded with the primary verb and resource, and followed by a specific detail about the analysis content. There is no wasted wording or redundancy.
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?
There is no output schema and no annotations, so the description should clarify what the analysis returns and how to interpret it, but it does not. The schema covers parameter meanings, but tool-level context such as usage scenarios, return values, and behavioral expectations 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% — all four parameters (chartId, startAge, endAge, analysisGranularity) have concise descriptions. The tool description adds no parameter-level information beyond what the schema already provides, so the baseline score of 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 analyzes a life timeline ('分析人生时间轴') and specifies the analysis scope as major-period and annual fortune ('大运流年详细分析'). This specific verb+resource combination distinguishes it from siblings like analyze_fortune.
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 guidance is given about when to use this tool versus alternatives, no exclusions, and no mention of prerequisites. The description only states what the tool does, leaving the agent to infer usage from the name.
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?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only states the core function without explaining prerequisites (e.g., chartId must exist from generate_chart), expected output format, or any limitations. No ambiguity or contradiction, but it is too thin to be transparent.
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 a single, concise sentence that fronts the verb and resource, then specifies relevant time dimensions. Every word earns its place, with no fluff or repetition, making it highly efficient.
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 no output schema, the description should clarify what the tool returns, but it only states the general action. It also does not mention that a valid chartId is required or that includeMonthly defaults to false, though these are in the schema. The description leaves the agent guessing about output structure and usage context.
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%, with each parameter having a description in Chinese. The tool description adds some context by mentioning 大运/流年/流月, which relates to year and includeMonthly, but this is marginal beyond what the schema already conveys. Thus 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 uses a specific verb '分析' (analyze) with a clear resource ('运势', fortune) and explicitly lists temporal dimensions like 大运 (major luck), 流年 (annual), and 流月 (monthly). This distinguishes it from sibling tools such as interpret_chart or analyze_compatibility, which focus on different aspects of divination.
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 usage when temporal fortune analysis is needed (yearly, monthly, major luck periods) but does not explicitly state when to use it instead of alternatives. There is no mention of exclusions or direct comparisons with sibling tools, so guidance is only implicit.
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

ziwei-mcp MCP server — quality and maintenance score on Glama

Copy to your README.md:

[![ziwei-mcp MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/SiwuXue/ziwei-mcp/badges/card.svg)](https://glama.ai/mcp/servers/SiwuXue/ziwei-mcp)

Score Badge

Copy to your README.md:

[![ziwei-mcp MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/SiwuXue/ziwei-mcp/badges/score.svg)](https://glama.ai/mcp/servers/SiwuXue/ziwei-mcp)

shields.io Endpoint

For READMEs with an existing badge row. Append &style=flat-square (or any other shields.io style) to match the rest, and &metric=tools, &metric=maintenance or &metric=claim to badge a different dimension.

[![ziwei-mcp MCP server — quality and maintenance score on Glama](https://img.shields.io/endpoint?url=https%3A%2F%2Fglama.ai%2Fmcp%2Fservers%2FSiwuXue%2Fziwei-mcp%2Fbadges%2Fshields.json)](https://glama.ai/mcp/servers/SiwuXue/ziwei-mcp)

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/SiwuXue/ziwei-mcp'

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