Chinese almanac: lunar calendar, BaZi 八字, daily 宜忌, lucky-day picker, public holidays.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.2/5 across 6 of 6 tools scored.
Each tool targets a narrow, distinct concern: bazi_chart for birth charts, cn_holiday for public holidays, huangli for daily auspicious items, lunar_calendar for lunar dates, and pick_lucky_days for selecting dates. There is no meaningful overlap; even the related huangli and pick_lucky_days are clearly separated by direction (given date vs. searching dates).
All names are lowercase snake_case, so style is consistent, but the grammatical pattern is mixed: bazi_chart and huangli are nouns, lunar_calendar is an adjective-noun, pick_lucky_days is verb-object, and what_can_you_do is a sentence. This is readable but lacks a uniform verb_noun convention.
Six tools is a well-scoped set for a Chinese almanac/calendar server. Each tool covers a distinct major feature (charts, holidays, almanac, lunar info, date selection) with no redundancy, and the count is comfortably within the ideal 3-15 range.
The server covers the core needs of its domain: lunar conversion, public holidays, daily almanac rulings, lucky date selection, and bazi charts. There are no obvious dead ends; the addition of what_can_you_do also helps agents navigate the remaining surface, making the set feel comprehensive for its intended purpose.
bazi_chart生辰八字排盘A八字排盘 from birth date and hour: four pillars (年月日时柱), five-element counts, 纳音, zodiac. Uses true solar-term boundaries.
| Name | Required | Description | Default |
|---|---|---|---|
| datetime | Yes | Birth datetime YYYY-MM-DDTHH:mm |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds the computational detail of using true solar-term boundaries and enumerates the chart contents, which provides useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the primary output and key features without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the one-parameter schema, clear annotations, and presence of an output schema, the description covers the essential purpose and behavior. It could mention timezone handling, but the solar-term boundary detail partially addresses temporal context. Overall, it's sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the datetime parameter with format and meaning. The description's mention of 'birth date and hour' reinforces this but does not add new semantic details. Baseline 3 for high schema coverage is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes a BaZi chart from birth date/time, enumerating key outputs (four pillars, five elements, na yin, zodiac) and the solar-term boundary method. This distinguishes it from sibling tools like lunar_calendar and pick_lucky_days.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for generating BaZi charts from birth date/time, but it does not explicitly state when to prefer it over sibling tools or mention exclusions. Usage context is clear but relies on inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cn_holiday中国法定节假日AIs a date a Chinese public holiday, weekend, or 调休 make-up workday? Plus the next holiday.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | YYYY-MM-DD, default today |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive hints, so the description needn't repeat them. It adds the 'next holiday' feature but doesn't disclose edge cases like invalid dates or timezone handling. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise, front-loaded sentence effectively communicates the tool's function without waste. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter tool, the description covers the primary functionality and the next-holiday bonus. An output schema exists, so return values are presumably documented elsewhere. Minor edge cases could be added, but the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single optional date parameter, already explaining the format and default. The description adds no additional param semantics, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool's purpose: checking if a date is a Chinese public holiday, weekend, or make-up workday, plus returning the next holiday. It uses a specific verb phrase and resource, and is distinct from sibling tools like lunar_calendar or bazi_chart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (for holiday-related queries) but does not explicitly mention when to use this tool over siblings or provide exclusion criteria. It does not name alternatives or state 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.
huangli今日黄历宜忌AChinese almanac for a date: 宜 (auspicious activities), 忌 (avoid), 冲煞, 彭祖百忌. date omitted = today.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | YYYY-MM-DD, default today |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare safe, read-only, idempotent behavior. The description adds the default-date behavior ('date omitted = today') and enumerates the data categories returned, which provides useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using one tight sentence to communicate the tool's purpose, content, and default behavior. Every word earns its place, and the structure is front-loaded with the main verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with an output schema and safe annotations, the description is fully adequate. It explains what the tool returns (宜, 忌, 冲煞, 彭祖百忌) and the default date behavior, making it complete for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with a clear description ('YYYY-MM-DD, default today'). The tool description reinforces the default but does not add additional meaning beyond the schema, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a Chinese almanac for a date, listing specific elements (宜, 忌, 冲煞, 彭祖百忌). This directly distinguishes it from siblings like bazi_chart or lunar_calendar by describing its exact purpose and output content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it is for a specific date and defaults to today when omitted. While it doesn't explicitly name alternatives or exclusions, the scope is obvious from the description and sibling tool names, making it easy for an agent to decide when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lunar_calendar公历转农历AChinese lunar calendar for any date: 农历、干支纪年、生肖、节气、节日、星座。date omitted = today.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | YYYY-MM-DD, default today |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and non-destructive behavior. The description adds behavioral context beyond the annotations: it specifies the output content (lunar, GanZhi, zodiac, solar terms, festivals, constellations) and the default behavior when 'date' is omitted. This enriches understanding of what the tool returns and how it behaves without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the tool's function and default behavior, followed by a concise list of output categories. Every word earns its place, with no waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no nested objects, and an existing output schema), the description is complete. It tells the user what data will be returned (via the content list) and how the input handles omission. The presence of an output schema means return-value details need not be restated. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes the 'date' parameter with format and default, achieving 100% schema description coverage. The description repeats the default today behavior but does not add additional meaning beyond what the schema already provides. Therefore, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Chinese lunar calendar for any date' and enumerates the output categories (农历、干支纪年、生肖、节气、节日、星座). It does not explicitly differentiate from sibling tools like bazi_chart or huangli, but the title '公历转农历' and focus on lunar calendar data make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys when to use the tool: for any Gregorian date to get lunar calendar information, with the date defaulting to today. It does not provide explicit when-not-to-use guidance or mention alternative sibling tools, but the intended use case is clearly implied by the tool's straightforward nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pick_lucky_days择吉日AFind auspicious days in a month for an event: 结婚/领证/搬家/开业/装修/出行/签约/订婚/安床/安葬 or any 黄历宜 term.
| Name | Required | Description | Default |
|---|---|---|---|
| event | Yes | Event keyword in Chinese, e.g. 搬家 | |
| month | No | YYYY-MM, default current month |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read-only operation. The description adds minor behavioral context by listing supported event categories and allowing arbitrary 黄历宜 terms, but it does not disclose output format, pagination, or other behavioral traits. With annotations covering the safety profile, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the core function and then lists examples. Every word is useful, and no extraneous information is included. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with 2 parameters, full schema coverage, annotations, and an output schema, the description is sufficient for an agent to select and invoke the tool correctly. It explains the event scope and month behavior. Minor gaps exist (e.g., not explicitly stating the return format), but the output schema presumably covers that, so this is not a significant omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% since both 'event' and 'month' have descriptions. The description adds value by providing a concrete list of example event keywords and explicitly stating that any 黄历宜 term is accepted, which expands the understanding of the 'event' parameter beyond the schema example. It does not add syntax details for 'month', but the schema already covers the format and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find auspicious days in a month for an event' with specific event examples (结婚/领证/搬家/开业/装修/出行/签约/订婚/安床/安葬). This specific verb+resource scope distinguishes it from sibling tools like huangli or lunar_calendar, which are more general almanac/calendar references.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding auspicious days for a particular event, but it does not explicitly state when to choose this tool over alternatives (e.g., bazi_chart, huangli). There is no mention of exclusions or when-not-to-use. The context from siblings and the 'or any 黄历宜 term' phrase provide implicit guidance, but explicit alternatives are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
what_can_you_doFind the right tool for a taskADescribe a task in plain language (any language) and get back exactly which tools on this server do it, with ready-to-run example calls — instead of reading the whole catalogue and guessing. Also returns multi-step recipes when a task needs several tools chained (invoices to a ledger, a bank statement reconciled, a messy CSV turned into a deliverable). Deterministic and free: it calls no model, costs nothing, and never runs out of quota. Call this FIRST when you are not sure what this server offers.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | What you are trying to do, e.g. "reconcile a bank statement against my books" or "把一堆发票整理成能入账的表格" |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and non-destructive. The description adds that it is deterministic, calls no model, costs nothing, never runs out of quota, and can return multi-step recipes, which goes beyond the annotation basics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each earning its place: purpose, recipe behavior, cost/performance, and usage instruction. Front-loaded with the main purpose, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter discovery tool with an output schema and robust annotations, the description covers purpose, usage, behavior, and edge cases. Nothing important is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the single 'task' parameter with examples. The description adds that it accepts any language and emphasizes plain-language input, providing modest extra context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it maps plain-language tasks to the exact tools on this server, with example calls. This is a specific verb+resource and is easily distinguished from sibling domain tools like bazi_chart or cn_holiday.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs 'Call this FIRST when you are not sure what this server offers' and contrasts with 'reading the whole catalogue and guessing'. This gives unambiguous when-to-use and alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.