timemap-mcp

by cnick26

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.3.0
Disambiguation5/5
Each tool targets a distinct aspect of Chinese astrology: daily interactions, pillars, quality, hourly pillars, luck pillars, natal chart, solar terms, and hexagrams. There is no overlap in purpose.
Naming Consistency4/5
All tools follow a verb_noun pattern in snake_case, with most using 'get_' and one using 'lookup_'. This minor deviation is still consistent and predictable.
Tool Count5/5
8 tools cover a comprehensive range of BaZi functionalities without being excessive. Each tool serves a clear purpose and contributes to the server's domain.
Completeness4/5
The tool set covers core BaZi operations: chart creation, pillar calculations, daily quality, solar terms, and hexagrams. A minor gap is the lack of a compatibility or relationship analysis tool, but the set is largely complete for individual chart analysis.
Average 3.9/5 across 8 of 8 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 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?
No annotations provided, so description must carry full burden. It mentions calculation but lacks disclosure on computational demands, data source, or any side effects. The output schema exists but description adds no behavioral context beyond the name.
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?
Concise one-line purpose followed by structured args with examples. Front-loaded and efficient, though could be slightly trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values need not be explained. However, with 4 params and no annotations, description omits conceptual background on luck pillars and fails to fully differentiate from peers. Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It provides format examples (ISO 8601, HH:MM, 'male'/'female', IANA timezone) but does not explain what the parameters mean or how they influence the calculation. Partial improvement over bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates the 10-year Luck Pillar timeline with a specific verb and resource. It distinguishes from sibling tools like get_daily_pillars and get_natal_chart by focusing on decades of 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 on when to use this tool vs. alternatives. The description lists sibling tools but provides no comparative context 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?
With no annotations, the description must disclose behavioral traits. It only states the action (get) and input format, omitting whether the operation is read-only, idempotent, or has side effects. The term 'Get' implies reading but is not explicit.
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: two sentences and a parameters line. The purpose is front-loaded, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and existence of an output schema, the description is adequate but minimal. It does not explain what 'pillar blocks' are or how they are returned, which may be insufficient for agents lacking domain knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It provides an ISO 8601 format example ('2026-04-10'), which adds clarity. However, it does not specify timezone or other nuances, so slightly below perfect.
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 retrieves '12 two-hour pillar blocks for any date', with a specific time range. The name 'get_hourly_pillars' aligns with the action, and it distinguishes from siblings like 'get_daily_pillars' by focusing on hourly blocks.
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 siblings. The description does not mention alternatives or conditions for use, leaving the agent to infer from the 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 must carry behavioral disclosure. It only indicates a read operation via 'Get', but does not mention any other behavioral traits (e.g., authentication needs, performance, error conditions). This is minimal.
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 with two sentences, immediately stating the purpose and parameter format. Every sentence is necessary and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema exists), the description is mostly complete. It explains the input format but does not describe output structure or potential date range limitations, though the output schema likely covers the return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'date' has 0% schema coverage, but the description adds format specification (ISO 8601) and an example. This meaningfully assists the agent beyond the raw schema, though it does not cover edge cases.
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 explicitly states the tool gets Year, Month, and Day pillars for any date, with a specific verb ('Get') and resource ('pillars'). It clearly distinguishes from siblings like get_hourly_pillars by specifying the temporal scope.
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 for any date and provides an example format, but it lacks explicit guidance on when to use this tool versus siblings or any exclusions. The 'any date' phrasing is broad but functional.
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 provided. Description only states 'calculate', implying read-only, but lacks details on auth, rate limits, or side effects. Mentions timezone improves accuracy, but overall minimal behavioral disclosure.
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?
Two sentences: one for purpose, then a bulleted Args list with inline examples. No redundant information. Front-loaded with key action and output components.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so description does not need to detail return values. Input parameters are fully covered with examples and notes. Could briefly mention that chart includes all listed components, but otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage. Description adds meaning with examples (e.g., '1994-01-26' for birth_date, '07:11' for birth_time) and clarifies format for timezone.
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?
Clearly states 'Calculate a complete BaZi natal chart with Four Pillars, Luck Pillars, Life Gua, and stars.' Differentiates from siblings like get_daily_pillars or get_luck_pillars which are subcomponents.
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?
Provides parameter descriptions with examples but no explicit when-to-use or when-not-to-use guidance. Context signals indicate siblings are sub-tools, but description does not compare.
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, and the description only says 'check,' which implies a non-destructive read operation. However, it does not disclose if there are side effects, auth requirements, or limitations. The description carries the full burden but offers minimal 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 short and front-loaded with the purpose, then lists arguments with examples. Every sentence is necessary and adds value, achieving high conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (so return values need not be explained) and 3 required parameters, the description adequately covers the tool's purpose and most parameters. It is complete enough for an agent to understand when and how to use it, though more detail on the type of interactions could help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description compensates with clear examples for each parameter (e.g., ISO 8601 date, 'HH:MM' format, IANA timezone). This adds significant meaning beyond the schema's bare property names.
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 checks 'natal chart clashes and combinations for a specific date,' using a specific verb and resource. This distinguishes it from sibling tools like get_daily_pillars or get_day_quality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for using the tool with a date and birth info, but does not explicitly mention when not to use it or alternative tools. However, the examples and sibling names imply the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It correctly implies a read-only lookup operation, but does not disclose any additional behavioral traits such as data sources, performance, or error conditions. It is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with a clear header and bullet-like parameter list. Every sentence serves a purpose, and there is no redundant or unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with only two required parameters and an output schema likely covering return values. The description fully explains the input parameters and the purpose, making it complete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the tool's description provides detailed semantics for both parameters: stem accepts Chinese, pinyin, or index; branch accepts Chinese, pinyin, animal, or index. This adds significant value beyond the schema's empty definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: looking up a Xuan Kong Da Gua hexagram for a stem-branch pillar. It specifies the exact resource (hexagram) and action (look up), and it is easily distinguishable from sibling tools like get_daily_pillars or get_natal_chart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. It lacks information about prerequisites, preferred scenarios, or when not to use it. The sibling tools are listed but no comparisons or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'Instant calculation' which implies speed, but does not disclose any limitations, side effects, or auth requirements. For a simple read tool, this is adequate but lacks depth.
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 very concise: two brief lines explaining purpose and constraints, followed by a structured Args section. Every sentence adds value and is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter and an output schema exists (context signal), the description adequately explains what the tool returns (day quality indicators) and the input format. It is sufficiently complete for a simple lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an Args section with the date parameter described as 'ISO 8601 date, e.g. '2026-04-10''. The schema has one required date string property with no format info, so the description adds meaningful format and example guidance.
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 that it gets Tong Shu day quality indicators, naming specific indicators (Day Officer, 28 Constellation, Flying Star). This is a specific verb+resource and distinguishes from siblings like get_daily_pillars or get_daily_interactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It says 'No natal chart needed. Instant calculation.' which guides the user that this tool is appropriate for quick day quality queries without additional context. While it doesn't explicitly state when not to use, it provides useful context for 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It discloses the tool retrieves an exact date and gives an example (Lichun ~Feb 4). While it does not specify output format or error handling, the simplicity of the tool and presence of an output schema mitigate concerns.
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 brief and well-structured: a clear purpose sentence, an explanatory note about 24 terms, and concise parameter descriptions. Every sentence is informative and no words are wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, the presence of an output schema (which covers return values), and distinct siblings, the description provides sufficient context. It answers what, how, and the range of inputs without missing essential details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates fully by explaining both parameters: year is a year like 2026, term_number is the solar term index 1-24 with examples. This adds significant meaning beyond the raw integer types.
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 retrieves the exact date of a solar term for any year, using specific verbs and resource. It is distinct from siblings like get_daily_pillars or get_natal_chart, which cover different concepts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool's scope (any year, term numbers 1-24) but does not explicitly state when to use it over alternatives. However, the sibling context makes the usage obvious, as other tools serve different purposes.
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:

[![timemap-mcp MCP server](https://glama.ai/mcp/servers/cnick26/timemap-mcp/badges/card.svg)](https://glama.ai/mcp/servers/cnick26/timemap-mcp)

Score Badge

Copy to your README.md:

[![timemap-mcp MCP server](https://glama.ai/mcp/servers/cnick26/timemap-mcp/badges/score.svg)](https://glama.ai/mcp/servers/cnick26/timemap-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/cnick26/timemap-mcp'

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