Yijing Bazi MCP Server

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.0
Disambiguation3/5
The tools have some clear distinctions, such as between bazi_analyze (analyzing a birth chart) and yijing_interpret (interpreting hexagrams), but there is overlap in purpose. For example, bazi_forecast (predicting future luck) and destiny_consult (providing destiny consultation) could be confused as both involve future-oriented advice, and case_study (analyzing case studies) might overlap with combined_analysis (comprehensive analysis). Descriptions help differentiate, but ambiguity exists in the broader advisory functions.
Naming Consistency4/5
The naming is mostly consistent with a clear pattern: most tools use a prefix like 'bazi_' or 'yijing_' followed by a verb_noun structure (e.g., bazi_analyze, yijing_generate_hexagram). However, there are minor deviations: case_study and knowledge_learn lack the prefix, and combined_analysis uses a different structure. Overall, the naming is readable and follows a predictable convention with only slight inconsistencies.
Tool Count5/5
With 10 tools, the count is well-scoped for the server's purpose of Yijing and Bazi analysis. Each tool appears to serve a distinct role in the domain, such as chart generation, interpretation, forecasting, and learning. This number allows comprehensive coverage without being overwhelming, fitting typical expectations for a specialized server.
Completeness4/5
The tool set covers key aspects of Yijing and Bazi analysis, including generation (bazi_generate_chart, yijing_generate_hexagram), interpretation (bazi_analyze, yijing_interpret), forecasting (bazi_forecast), and advisory functions (yijing_advise, destiny_consult). Minor gaps might exist, such as lack of tools for historical data or advanced customization, but core workflows are well-covered, allowing agents to perform most essential tasks in this domain.
Average 2.6/5 across 10 of 10 tools scored.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. '学习' (learn) suggests an educational/instructional function but doesn't clarify whether this retrieves existing knowledge, generates new explanations, provides interactive lessons, or something else. No information about output format, authentication needs, rate limits, or what constitutes successful learning.
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?
Extremely concise - a single 6-character Chinese phrase. While under-specified, every character earns its place by establishing the domain. No redundant information or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no annotations and no output schema, the description is inadequate. It doesn't explain what the tool returns (text explanations? interactive lessons? visual diagrams?), how learning is structured, or what distinguishes this from the 9 sibling tools. The agent lacks sufficient context to use this tool effectively versus alternatives.
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 parameters are well-documented in the schema itself. The description adds no parameter-specific information beyond implying the domains (Yijing/Bazi) which map to the 'system' enum. No additional context about how parameters interact or what constitutes valid 'topic' inputs for these systems.
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 '学习易经和八字知识' (Learn Yijing and Bazi knowledge) is a tautology that essentially restates the tool name 'knowledge_learn' in Chinese. It mentions the domains (Yijing/Bazi) but doesn't specify what the tool actually does - whether it retrieves, explains, teaches, or generates content about these topics. It doesn't distinguish from siblings like 'yijing_advise' or 'bazi_analyze' which suggest more specific actions.
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 the 9 sibling tools. There's no mention of alternatives, prerequisites, or specific contexts where this learning tool is appropriate versus analysis, forecasting, or interpretation tools. The agent must guess based on tool names alone.
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. It only states 'analyze' without explaining what the analysis entails, whether it's read-only or modifies data, what permissions are needed, or how results are returned. This is inadequate for a tool with 4 parameters and no output schema, leaving key behavioral traits unspecified.
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, efficient phrase in Chinese, front-loaded with the core action. There is no wasted verbiage or redundancy, making it highly concise. However, this conciseness comes at the cost of detail, which is reflected in lower scores for other dimensions.
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 complexity (4 parameters, no annotations, no output schema) and sibling tools, the description is incomplete. It doesn't explain the tool's behavior, output format, or differentiation from alternatives. The schema covers parameters well, but the description fails to provide necessary context for effective use, especially without annotations or output schema.
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 clear descriptions for all parameters (e.g., 'case_id' specifies optional retrieval, 'system' defines case types). The description adds no additional meaning beyond the schema, such as explaining how 'analysis_focus' interacts with 'system' or providing examples. Baseline 3 is appropriate since the schema does the heavy lifting.
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 '分析易经和八字案例' (analyze Yijing and Bazi case studies) states a general purpose but is vague about what 'analyze' entails. It doesn't specify if this tool retrieves, processes, or interprets case studies, nor does it distinguish itself from sibling tools like 'bazi_analyze', 'combined_analysis', or 'yijing_interpret'. The description restates the tool name's concept without adding specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or exclusions. Given sibling tools like 'bazi_analyze' and 'yijing_interpret', the lack of differentiation leaves the agent uncertain about when this tool is appropriate, relying solely on the input schema for hints.
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. It mentions '多层次解读' (multi-level interpretation) but doesn't explain what that entails—such as output format, depth, or any limitations like rate limits or authentication needs. This leaves significant gaps in understanding 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, efficient sentence that states the core function without unnecessary words. It's front-loaded and to the point, though it could be more informative without sacrificing brevity.
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's complexity (5 parameters, nested objects, no output schema) and lack of annotations, the description is inadequate. It doesn't explain what '多层次解读' outputs, how interpretations vary by context, or any behavioral traits, making it incomplete for effective agent use.
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 meaning beyond the schema, such as explaining how parameters interact or providing examples. Baseline 3 is appropriate as the schema handles the heavy lifting.
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 '对卦象进行多层次解读' (interpret hexagrams at multiple levels) states the tool's purpose with a verb ('interpret') and resource ('hexagrams'), but it's vague about what 'multiple levels' means and doesn't distinguish it from sibling tools like yijing_advise or yijing_generate_hexagram. It provides a basic function but lacks specificity.
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 on when to use this tool versus alternatives like yijing_advise or combined_analysis. The description implies interpretation but doesn't specify contexts, prerequisites, or exclusions, leaving the agent without clear usage instructions.
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 full burden but only states the action ('分析') without disclosing behavioral traits such as computational requirements, output format, error handling, or any side effects. It's minimal and lacks necessary context for safe invocation.
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, efficient phrase ('分析八字命盘') that is front-loaded and wastes no words. It's appropriately sized for its purpose, though brevity contributes to gaps in other dimensions.
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's complexity (3 parameters, nested objects, no output schema, and no annotations), the description is incomplete. It doesn't explain what analysis produces, how results are structured, or any prerequisites, making it inadequate for informed use by an AI agent.
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 meaning beyond the schema, as it doesn't explain parameter interactions or usage examples. Baseline score of 3 applies since the schema handles parameter documentation adequately.
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 '分析八字命盘' (analyze bazi birth chart) states the tool's purpose with a clear verb ('分析') and resource ('八字命盘'), but it's vague about what analysis entails and doesn't differentiate from sibling tools like 'bazi_forecast' or 'combined_analysis'. It provides basic function but lacks specificity.
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 doesn't mention sibling tools like 'bazi_forecast' for predictions or 'combined_analysis' for broader insights, leaving the agent without context for tool selection.
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 full burden but only states the basic function without disclosing behavioral traits. It doesn't mention whether this is a read-only operation, what the output format might be, potential rate limits, authentication needs, or how results are structured (e.g., textual predictions vs. data). For a tool with 5 parameters and no output schema, this is inadequate.
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, efficient phrase ('预测未来运势') that directly states the tool's function without unnecessary words. It's appropriately sized for a simple declaration, though its brevity contributes to gaps in other dimensions.
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 5 parameters (including nested objects), no annotations, and no output schema, the description is incomplete. It doesn't explain what the forecast output looks like, how to interpret results, or the tool's scope relative to siblings. For a forecasting tool with multiple aspects and resolution options, more context is needed to guide effective use.
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%, providing clear documentation for all parameters. The description adds no additional parameter semantics beyond implying forecasting, which is already evident from the tool name and schema. Baseline score of 3 is appropriate since the schema does the heavy lifting, but the description doesn't compensate with extra context like example usage or parameter interactions.
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 '预测未来运势' (predict future fortune) states a general purpose but lacks specificity about what resource it operates on and how it differs from siblings. It mentions 'future fortune' which suggests forecasting, but doesn't specify it's for BaZi (八字) charts or differentiate from tools like 'destiny_consult' or 'combined_analysis' that might also provide fortune-related insights.
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 on when to use this tool versus alternatives is provided. The description doesn't mention prerequisites (e.g., needing a chart from 'bazi_generate_chart'), exclusions, or comparisons to siblings like 'bazi_analyze' or 'destiny_consult', leaving the agent to infer usage context from tool names alone.
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 full burden for behavioral disclosure. '生成八字命盘' only states what the tool does, not how it behaves. It doesn't mention whether this is a read-only operation, what permissions might be needed, whether it has rate limits, what format the output takes, or any error conditions. For a tool with 4 parameters and no annotations, this is a significant gap in 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 extremely concise at just four Chinese characters ('生成八字命盘'), which directly states the tool's function with zero wasted words. It's appropriately sized for what it communicates and is front-loaded with the essential information. Every character 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 the tool's complexity (4 parameters including nested objects, no output schema, and no annotations), the description is insufficiently complete. It doesn't explain what a Bazi chart is for users unfamiliar with Chinese metaphysics, doesn't describe the output format, and provides no behavioral context. For a tool that likely produces complex astrological calculations, more explanatory context would be helpful.
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 all parameters well-documented in the schema itself. The description adds no additional parameter information beyond what's already in the schema. According to scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
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 '生成八字命盘' (Generate Bazi chart) clearly states the tool's function with a specific verb ('生成' - generate) and resource ('八字命盘' - Bazi chart). However, it doesn't differentiate this tool from its siblings like 'bazi_analyze' or 'bazi_forecast' - all could involve Bazi chart generation or analysis. The purpose is clear but lacks sibling differentiation.
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. With siblings like 'bazi_analyze' and 'bazi_forecast' that likely work with Bazi charts, there's no indication whether this tool generates the foundational chart while others analyze it, or whether they overlap. No explicit when/when-not instructions or alternative recommendations are provided.
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 provides minimal information. It mentions the tool performs 'comprehensive analysis' but doesn't describe what that entails, how long it takes, whether it requires specific permissions, what format the analysis takes, or any limitations. For a tool with complex inputs and no output schema, this represents a significant transparency gap.
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 at just one sentence with no wasted words. It's front-loaded with the core purpose and doesn't contain any unnecessary information. While this conciseness comes at the cost of detail, the structure itself is efficient and focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex analysis tool with four parameters (including nested objects), no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what kind of analysis results to expect, how the I Ching and Bazi integration works, what format the output takes, or any prerequisites for meaningful analysis. The user is left with significant unanswered questions about how to effectively use this 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?
The description adds no parameter information beyond what's already in the schema, which has 100% description coverage. While the schema adequately documents the four parameters (bazi_chart, hexagram, question, analysis_aspects), the description doesn't provide additional context about how these parameters interact or what constitutes valid values. With complete schema coverage, 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool performs 'comprehensive analysis combining I Ching and Bazi' which gives a general purpose, but it's vague about what specific analysis it performs. It doesn't distinguish itself from sibling tools like 'destiny_consult' or 'yijing_advise' which likely offer similar consultation services. The description lacks a specific verb and resource combination that clearly defines its unique function.
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. With multiple sibling tools like 'bazi_analyze', 'yijing_advise', and 'destiny_consult' that appear to offer related services, the description gives no indication of when this combined analysis approach is preferred over using individual tools or other consultation methods. The user must infer usage from the tool name alone.
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. The description only states it provides consultation services without mentioning any behavioral traits such as whether it's read-only or mutative, if it requires authentication, rate limits, or what the output format might be. For a tool with 4 parameters and no output schema, this leaves significant gaps in understanding how it behaves.
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, efficient sentence in Chinese that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly. Every word earns its place, adhering to best practices for conciseness.
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 complexity (4 parameters including nested objects, no output schema, and no annotations), the description is incomplete. It doesn't explain what the consultation entails, how results are returned, or any prerequisites. With sibling tools offering similar services, more context is needed to differentiate and guide usage. The description is too minimal for effective tool selection and invocation.
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 clear descriptions for all parameters (e.g., user_profile, question, context, consultation_type with enum values). The description adds no additional meaning beyond what the schema provides, such as explaining how parameters interact or providing examples. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, but there's no extra value from the description.
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 '提供命理咨询服务' (provides destiny consultation services) states a general purpose but is vague about what specific action the tool performs. It doesn't specify whether it analyzes, predicts, advises, or synthesizes information, nor does it distinguish itself from sibling tools like bazi_analyze, bazi_forecast, or yijing_advise that likely offer similar services. The description is functional but lacks specificity.
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. With multiple sibling tools related to bazi (八字) and yijing (易经) analysis, there's no indication of whether this tool is a general-purpose consultation that combines methods, a specific type of analysis, or when it should be preferred over more specialized tools like bazi_analyze or yijing_advise. Usage is implied only by the tool name and vague description.
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 states the tool provides advice but doesn't disclose behavioral traits such as whether it's deterministic, requires specific hexagram formats, has limitations on question types, or how it handles the optional 'options' parameter. This leaves gaps for an agent to understand how to invoke it effectively.
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, efficient sentence in Chinese that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 complexity (4 parameters including a nested object and enum, no output schema, and no annotations), the description is incomplete. It doesn't explain what the advice output looks like, how hexagram data should be structured, or the tool's limitations, leaving significant gaps for an agent to rely on.
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 (hexagram, question, options, time_frame). The description adds no meaning beyond the schema, as it doesn't explain parameter interactions or usage nuances. Baseline 3 is appropriate since the schema does the heavy lifting.
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 '基于卦象提供决策建议' (provides decision advice based on hexagrams) states a general purpose but lacks specificity about what kind of advice or how it differs from siblings like 'yijing_interpret' or 'combined_analysis'. It mentions the resource (hexagrams) but doesn't clarify the verb beyond 'advise'.
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 on when to use this tool versus alternatives like 'yijing_interpret' (which might interpret hexagrams without advice) or 'combined_analysis' (which could integrate multiple methods). The description implies it's for decision-making but doesn't specify contexts or exclusions.
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 states what the tool does (generates hexagrams) but lacks critical behavioral details: it doesn't mention whether this is a read-only operation, what the output format might be, potential side effects, or any limitations (e.g., rate limits or authentication needs). For a tool with no annotations, this leaves significant gaps in understanding its behavior.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse. Every part of the sentence contributes to understanding the tool's function, earning 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 the tool has no annotations and no output schema, the description is incomplete. It adequately states the purpose but fails to address behavioral aspects, output expectations, or usage context relative to siblings. For a tool with three parameters and no structured support, the description should provide more guidance on how to interpret results or when to apply different methods, but it doesn't.
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 with descriptions. The description adds minimal value beyond the schema by implying parameter usage ('指定方法' hints at the 'method' parameter), but it doesn't provide additional context about parameter interactions or meaning. With high schema coverage, the baseline of 3 is appropriate as the description doesn't significantly 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?
The description clearly states the action ('生成' - generate) and resource ('六爻卦象' - hexagram), making the purpose understandable. It doesn't explicitly differentiate from sibling tools like 'yijing_advise' or 'yijing_interpret', but the specific focus on hexagram generation is apparent. The description avoids tautology by not just restating the tool name.
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 like 'yijing_advise' or 'yijing_interpret'. It mentions '指定方法' (specified method) which hints at the 'method' parameter but doesn't offer context about appropriate scenarios or prerequisites for hexagram generation versus other Yijing-related tools.
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:

[![yijing-bazi-mcp-server MCP server](https://glama.ai/mcp/servers/SiwuXue/yijing-bazi-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/SiwuXue/yijing-bazi-mcp-server)

Score Badge

Copy to your README.md:

[![yijing-bazi-mcp-server MCP server](https://glama.ai/mcp/servers/SiwuXue/yijing-bazi-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/SiwuXue/yijing-bazi-mcp-server)

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/yijing-bazi-mcp-server'

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