Lunar Calendar MCP Server

Server Quality Checklist

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

Latest release: v1.2.1
Disambiguation4/5
Most tools have distinct purposes, such as date analysis, zodiac compatibility, and moon phase calculations, with clear boundaries. However, some overlap exists between tools like 'check_auspicious_date' and 'find_good_dates', which both assess date favorability, and 'get_lunar_festivals' and 'get_festival_details', which both provide festival information, potentially causing minor confusion.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, such as 'calculate_bazi', 'check_auspicious_date', and 'get_moon_phase'. All names use snake_case uniformly, with clear verbs like 'calculate', 'check', 'get', 'find', and 'predict', making the set predictable and easy to navigate.
Tool Count3/5
With 20 tools, the count is borderline high for a lunar calendar server, as it may feel heavy and slightly overwhelming. While the tools cover diverse aspects like dates, zodiacs, festivals, and moon phases, some consolidation could improve focus without losing functionality, such as merging overlapping festival tools.
Completeness5/5
The tool set comprehensively covers the lunar calendar domain, including date conversion (lunar_to_solar, solar_to_lunar), auspiciousness analysis, zodiac and BaZi calculations, festival details, moon phase information, and compatibility checks. There are no obvious gaps, providing full lifecycle coverage for planning and analysis in traditional Chinese metaphysics.
Average 3.9/5 across 20 of 20 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 11 commits in the last 12 weeks
- Last stable release on August 1, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

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 using 'astronomical algorithms' and being 'location-aware', but does not disclose potential error conditions, side effects, or any specific behavioral traits beyond a basic calculation. It is adequate but not thorough.
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 two sentences: the first states the core purpose, the second enumerates outputs. It is concise, front-loaded, and every sentence adds value without unnecessary detail.
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?
With no output schema, the description lists return fields (phase name, illumination, etc.), making it fairly complete. However, it omits error handling or edge cases (e.g., invalid date format), slightly reducing completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema documentation covers both parameters (date and location) with descriptions, so baseline is 3. The description adds a general note about location-aware calculations but does not provide additional semantic details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it calculates moon phase for a specific date and location, listing outputs like phase name, illumination, etc. However, it does not explicitly differentiate from sibling tools like 'get_moon_calendar' or 'predict_moon_phases', so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or when not to use it. The sibling list includes similar tools, but the description offers no selection criteria.
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, so description needed to disclose behavior. It mentions 'traditional Chinese calendar principles' but lacks specifics about data sources, determinism, limitations, or what happens on invalid dates. The output description is good but behavioral traits are vague.
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?
Single sentence covering purpose, inputs, and outputs efficiently. No wasted words, but could be slightly more structured by splitting output details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains return values (score, level, analysis). Mentions cultural factors and activity suitability. Lacks error handling or edge case descriptions, but sufficient for typical 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 coverage is 100%, so the schema already documents parameters. Description adds minimal extra meaning beyond what schema provides, such as listing example activities (wedding, business_opening). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool analyzes a date for auspiciousness based on traditional Chinese calendar principles, and specifies output format including score, level, and analysis. Distinguishes itself from siblings like find_good_dates or batch_check_dates by focusing on a single date with a specific activity.
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?
Implies usage for single-date activity analysis, but does not explicitly state when to use this tool versus siblings like find_good_dates or batch_check_dates. No when-not-to-use guidance or alternatives mentioned.
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. It states that the tool returns festival names, significance, customs, and cultural importance, but does not disclose any limitations (e.g., supported cultures beyond Chinese, date range constraints, or whether the list is exhaustive). This leaves ambiguity about behavior for non-Chinese cultures.
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 focused sentences: the first defines the primary function, the second provides illustrative examples. No redundant or filler content. Information is front-loaded.
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 no output schema, the description partially explains return content (names, significance, customs, cultural importance), but omits structural details, error handling, or completeness guarantees. For a tool with multiple siblings, this is adequate but not thoroughly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description adds context for the 'culture' parameter by associating it with Chinese traditions, but does not provide additional technical details beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieves' and the resource 'traditional festivals and cultural celebrations' for a specific date. It provides examples like Spring Festival, Mid-Autumn Festival, which distinguish it from sibling tools like get_annual_festivals (lists all festivals across year) and get_festival_details (for a single festival).
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 a specific date and Chinese culture via examples and default parameter, but does not explicitly state when to use this tool over siblings like get_festival_details or get_annual_festivals. No exclusions or alternative tools are mentioned.
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?
Annotations are absent, so the description must fully disclose behavior. It describes outputs but uses 'Creates' which may misleadingly imply mutation for a 'get' tool. It does not state that the tool is read-only, does not modify data, or lacks side effects. No safety or authorization context is provided.
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 three sentences with no wasted words. The first sentence states the primary purpose, the second details the output, and the third provides use cases. It is front-loaded and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately explains the tool's output for a calendar (phases, illumination, events) and lists use cases. However, it lacks behavioral transparency and usage guidelines, making it sufficient but not comprehensive. There is no output schema, but the description covers return expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for each parameter. The description does not add additional meaning beyond the schema, such as explaining the default location '0,0' or any parameter constraints. Baseline score of 3 is appropriate since schema does the heavy lifting.
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 'Creates a comprehensive monthly calendar showing moon phases for each day of the month.' It specifies the output (daily phases, illumination, events) and distinguishes itself from sibling tools like get_moon_phase (single day) and predict_moon_phases (future predictions) by focusing on the full month view.
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 provides context with 'Perfect for gardening, fishing, photography planning, or any activities influenced by lunar cycles,' which implies use cases but does not explicitly state when to use this tool over alternatives or when not to use it. No exclusions or sibling tool comparisons are given.
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, so description must disclose behavioral traits. It only describes output (score, analysis, recommendations) but does not mention any side effects, auth needs, rate limits, or whether it's read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should detail return values. It mentions 'compatibility score, detailed analysis, and recommendations' but lacks structure or format. Adequate for a straightforward analysis tool but not fully detailed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented. Description adds context ('based on Chinese zodiac animals and five elements') but does not elaborate on the 'culture' parameter beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool analyzes compatibility between two dates based on Chinese zodiac and five elements. Differentiates from siblings like calculate_bazi_compatibility (BaZi) and check_auspicious_date (auspiciousness).
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?
Provides context for use: 'traditionally used for checking compatibility between birth dates for relationships, partnerships, or selecting compatible dates for joint ventures.' Does not explicitly exclude alternatives but gives clear application domains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It explains the evaluation method (traditional Chinese calendar) and output (ranked dates with score), but omits behavioral traits like whether it's read-only, any side effects, or authentication needs. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences covering purpose, method, use cases, and optional parameters. Content is front-loaded and every sentence adds value, though could be slightly more structured (e.g., bullet points for parameters).
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 5 parameters, no output schema, and many siblings, the description provides sufficient context: explains input range, activity, culture (default Chinese), and output as ranked dates. It lacks explicit output format details but 'top favorable dates ranked by their auspiciousness score' is adequate for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description adds context about 'auspiciousness score' and ranking, but does not significantly augment the schema's built-in descriptions. Baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches for auspicious dates within a range using traditional Chinese calendar methods, returning top favorable dates ranked by score. This distinguishes it from siblings like check_auspicious_date (single date) or batch_check_dates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions ideal use cases (weddings, business openings, travel) and hints at limiting results, but does not explicitly state when to use this tool over siblings (e.g., for range vs single date) or provide 'when not to use' guidance.
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 discloses the return fields (name, date, days remaining, significance) and the input date reference, but does not mention any side effects, authorization needs, or limitations (e.g., supported cultures beyond Chinese). The description 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the main action and purpose. The second and third sentences add context and output details. No wasted words, though the second sentence ('Useful for planning...') is slightly redundant given the first.
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 (2 parameters, no output schema), the description explains what is returned (name, date, days remaining, significance). This is sufficient for an AI agent to understand the output. However, it lacks details like date format or if the result is singular. Still, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both 'date' and 'culture' have descriptions. The description adds context that the festival is found 'after a given reference date' and is 'traditional,' but does not elaborate on the 'culture' parameter (e.g., valid values). Thus, it adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Finds' and the specific resource 'next upcoming traditional festival after a given reference date.' It distinguishes itself from siblings like 'get_annual_festivals' and 'get_festival_details' by focusing on the immediate next festival, not a list or details of a known festival.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'useful for planning ahead,' implying a temporal context, but does not explicitly specify when to use this tool versus alternatives (e.g., 'get_festival_details' for detailed info on a known festival, or 'get_annual_festivals' for a yearly list). No when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It describes the output format (chronological list with dates, names, descriptions) but does not mention any side effects, authentication needs, rate limits, or potential limitations. It 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with no redundancy. The first sentence clearly states the core function, and the second adds value and use cases. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return structure (chronological order, solar/lunar dates, names, descriptions). It also provides use cases and implies the scope. It could mention that culture defaults to Chinese but otherwise is complete for a simple data generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described in the schema. The description adds no further meaning about parameters; it does not mention that 'culture' defaults to 'chinese' or how it affects results. At baseline, the score is 3 since the schema is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('generates') and resource ('complete calendar of all traditional festivals for an entire year'), and clearly distinguishes from siblings like 'get_festival_details' or 'get_lunar_festivals' by emphasizing the year-long comprehensive 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 lists appropriate use cases ('creating cultural event calendars, planning year-round celebrations, understanding annual rhythm') but does not explicitly state when not to use this tool or mention alternatives like 'get_festival_details' or 'get_next_festival'. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it provides exact dates and times and mentions astronomical accuracy, but does not disclose timezone, output format, or any assumptions or limitations. This is adequate but not thorough.
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 four sentences, well-structured: first states purpose, second details output, third gives use cases, fourth adds quality note. It is concise but could be slightly more efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 simple params, no output schema), the description covers purpose and use cases but lacks details on output format, timezone, precision, or validity constraints. It is not fully complete for an agent to understand all implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds that the tool returns exact dates and times but does not provide additional semantics beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool predicts and lists major moon phase transitions within a date range, using verbs 'predicts' and 'lists' with a specific resource. It distinguishes itself from sibling tools like get_moon_phase or get_moon_calendar by focusing on all transitions over a range.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use the tool (planning activities, scheduling observations, understanding lunar cycle) but does not explicitly mention when not to use it or compare to alternatives like get_moon_phase or get_moon_calendar. The context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes what information is returned (general energy, lucky directions, favorable colors, suitable/avoid activities, overall predictions), which gives a good sense of behavior. However, it does not mention side effects, resource consumption, or that it is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads the key purpose and lists outputs efficiently. It could be slightly more concise but is well-structured for an AI agent.
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?
No output schema is provided, so the description must explain return values. It does so by listing several categories of information (general energy, lucky directions, etc.), which is fairly complete. However, it lacks details on the exact structure or format of the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters ('date' and 'culture') have descriptions. The description adds minimal extra context beyond the schema, but reemphasizes the cultural context. Baseline 3 is appropriate given high coverage.
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 provides comprehensive daily fortune analysis based on traditional Chinese almanac and lists specific outputs like general energy, lucky directions, and favorable colors. It distinguishes from sibling tools that focus on specific activities or time slots, such as check_auspicious_date and get_lucky_hours.
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 a holistic view of the day's auspiciousness (e.g., 'beyond specific activities'), but does not explicitly state when to use or when not to use this tool versus alternatives. No explicit exclusions 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?
No annotations are provided, so the description must fully disclose behavioral traits. While it lists output dimensions (auspiciousness, moon phase, etc.) and the effect of specifying activity, it does not mention whether the tool is read-only, any prerequisites, error handling, or rate limits. For a tool with no annotations, this is insufficient.
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, front-loaded with the core purpose. Every sentence adds value without redundancy. No fluff or unnecessary details.
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?
Despite no output schema, the description covers the main return dimensions (auspiciousness, moon phase, festivals, zodiac) and the optional recommendation. It is complete for a comparison tool, though it omits error scenarios or edge cases like invalid dates.
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 100% coverage, but the description adds meaning: it specifies the maximum array size (up to 10), notes that activity yields a recommendation, and implies culture defaults to 'chinese'. These details go beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it compares multiple dates (up to 10) across dimensions like auspiciousness, moon phase, festivals, and zodiac. It distinguishes from siblings like check_auspicious_date (single date) and batch_check_dates (batch but not comparative). The verb 'compare' and resource 'dates' are specific and unambiguous.
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 suggests use for 'final decision-making between several good options', which provides context. It does not explicitly state when not to use or mention alternatives, but the context implies it is for comparing multiple options, distinct from single-date checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adequately covers the tool's behavior: it provides recommendations and detailed explanations based on traditional beliefs, and is non-destructive. However, it could be more explicit about read-only nature and absence of side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and informative with four sentences, each adding value. A slight reduction in redundancy (e.g., mentioning 'detailed explanations' twice) could improve conciseness.
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?
For a tool with no output schema, the description fully explains what the tool returns (recommendations and detailed explanations) and covers the complexity of lunar influence. It provides enough context for an agent to decide if it's the right tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented. The description adds some context (date format, activity type examples) but does not significantly enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it analyzes moon phase influence on activities with specific examples (e.g., new moons for beginnings, full moons for completion). It distinguishes from sibling tools like get_moon_phase by focusing on recommendations and detailed explanations.
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 clearly indicates when to use the tool (to get lunar influence for activities) but does not explicitly state when not to use it or mention alternative tools. The context of siblings implies usage for decision support rather than just phase retrieval.
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?
Given no annotations, the description explains behavior: handles leap months, provides exact solar date, includes validation. This adds transparency, though it lacks details on supported date ranges or cultural options beyond Chinese.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four sentences, front-loading the main action. Every sentence adds value without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not specify the return format. For a conversion tool, hinting at the output structure would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description adds context about leap month handling and validation but does not significantly enhance parameter semantics beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Converts traditional lunar calendar dates to Gregorian (solar) calendar dates', specifying the verb and resource. It distinguishes from sibling tools like solar_to_lunar by focusing on lunar-to-solar conversion.
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 provides clear use cases (lunar festivals, birth dates, event scheduling) and implies when to use. However, it does not explicitly mention alternatives or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral burden. It describes the process (comparing pillars and elements), outputs (score, level, analysis), and cultural context. While it doesn't mention side effects or authentication, it adequately sets expectations for a safe read-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that is moderately concise. It front-loads the core purpose and then adds detail. Every sentence adds value, though minor trimming could improve conciseness without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of BaZi compatibility and the absence of an output schema, the description adequately explains what the tool returns (score range, levels, element analysis, insights). It covers the essential aspects for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with well-described parameters. The description adds context about two people's birth dates but does not add significant detail about the timezone_offset parameter beyond the schema. The output is explained in summary but lacks structural details, which is acceptable given no output 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 analyzes BaZi compatibility between two people, specifies what it compares (four pillars and elemental compositions), and lists specific outputs (score, level, element analysis). It distinguishes itself from siblings like check_zodiac_compatibility which likely uses simpler zodiac signs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions traditional uses (marriage, business partnerships, relationships), providing context for when to use. However, it does not explicitly state when not to use or contrast with alternative tools like check_zodiac_compatibility, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the output comprehensively and implies a read-only calculation with no side effects, which is sufficient for a non-destructive tool.
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 moderately concise, front-loaded with purpose, and provides detailed output information. Slightly verbose but every sentence adds value.
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 no output schema, the description thoroughly explains all return elements (eight characters, day master, etc.), making it complete for the tool's purpose. Complexity is well-addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds context about China Standard Time default but does not significantly enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it calculates BaZi based on birth date and time, explains what BaZi is, and lists the output components. It distinguishes from sibling tools like calculate_bazi_compatibility by focusing on individual calculation.
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 implies usage for individual destiny analysis but does not explicitly state when to use this tool vs alternatives like check_zodiac_compatibility. However, the context of sibling tool names provides implicit guidance.
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 must fully convey behavioral traits. It describes the tool as providing information but does not disclose whether it is read-only, any rate limits, or if it involves external API calls. The lack of explicit behavioral details is a 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?
Two sentences: first defines the action and scope, second suggests use cases. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists the categories of information returned (origins, customs, foods, etc.), which is fairly complete for a festival details tool. It does not specify format or structure but covers main content areas.
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 100% description coverage for both parameters (festival_name, culture). The description adds significant meaning beyond the schema by detailing the kind of information returned (origins, customs, foods, etc.), which helps the agent understand what details will be provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'in-depth information about a specific traditional festival' and enumerates specific aspects like historical origins, cultural significance, customs, etc. This verb+resource specification distinguishes it from sibling tools such as get_annual_festivals and get_next_festival.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Perfect for learning about cultural traditions or planning authentic festival celebrations,' which implies suitable use cases. However, it does not explicitly state when not to use it or compare with alternatives like get_annual_festivals or get_next_festival.
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?
Without annotations, the description fully conveys that the tool analyzes and scores time periods, returning detailed information including names, animals, scores, and recommendations. It does not disclose limitations or scoring methodology, but covers core behavior well.
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 focused four-sentence paragraph that immediately states the purpose. It contains no redundant or filler content, though it could be slightly more concise.
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?
With no output schema, the description explicitly lists the fields returned for each time period (name, zodiac animal, score, suitable activities, recommendations). This sufficiently informs the agent of the output structure, though it could mention the list/array type explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds context by linking the activity parameter to activity-specific suitability and clarifying the culture default. This goes beyond the schema's minimal descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as determining auspicious hours within a specific day using traditional Chinese time divisions. It distinguishes itself from date-focused sibling tools by emphasizing hourly analysis and returning period-level details.
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 states it is 'perfect for timing important activities, meetings, ceremonies, or decisions within a chosen date,' providing clear use cases. However, it does not explicitly list when not to use or mention alternative tools among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It describes the output comprehensively (animal, element, traits, etc.) and mentions yearly/daily info based on heavenly stems. It does not cover edge cases or other cultures, but for the primary Chinese zodiac case, it is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear front-loaded first sentence summarizing the purpose. Every sentence adds value: the second sentence enumerates output components, and the third specifies the system used. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is fairly complete for Chinese zodiac, but it lacks explanation for other culture values and does not differentiate from overlapping sibling tools like get_daily_fortune or calculate_bazi. Without an output schema, the description should cover the return format for all cases, which it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value beyond the schema by detailing what is returned for the 'chinese' culture, including the list of 12 animals and five elements. However, it does not explain the 'culture' parameter for other possible values, which is a minor gap.
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 comprehensive zodiac information for a specific date, explicitly listing the components for Chinese zodiac. The verb 'retrieves' and resource 'zodiac information' are specific, and the detail distinguishes it from sibling tools that focus on compatibility, auspicious dates, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool when you need zodiac info for a date, especially Chinese zodiac. It does not explicitly mention alternatives or when not to use, but the context is clear enough for an agent to infer the primary 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?
With no annotations provided, the description carries full burden. It states the output includes leap month info 'if applicable' and mentions Chinese calendar specifics. However, it does not disclose potential limitations like date range validity, error handling, or performance characteristics.
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 four sentences, front-loaded with the core purpose. Each sentence adds distinct information: conversion, return fields, Chinese-specific fields, and use cases. No redundant or extraneous 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?
Given the tool has only 2 parameters, no output schema, and no annotations, the description sufficiently explains input and output. It covers the return structure and typical use cases, making it complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by explaining that the 'culture' parameter defaults to 'chinese' and that for Chinese calendar additional zodiac and stem-branch info is returned. This goes beyond the schema's simple descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts Gregorian dates to lunar dates, listing returned fields including lunar year, month, day, leap month, and for Chinese calendar also zodiac and stem-branch. It distinguishes from sibling lunar_to_solar by its direction of conversion.
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 usage context: 'Essential for finding lunar dates for traditional festivals, birth dates, or cultural events.' It implies the tool is for conversion but does not explicitly state when not to use it or mention alternatives like lunar_to_solar or other calendar tools.
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?
Without annotations, description discloses batch limit (30 dates), output structure (scores/levels, best/worst). Missing details on error behavior or response format but sufficient for a read-only analysis tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, each sentence adds value. No redundant or vague language.
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?
Despite no output schema, description fully explains return values and scope. Covers input constraints, batch limit, and purpose. No critical gaps.
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?
Adds context beyond schema: dates are multiple, up to 30, activity and culture are required for analysis. Complements schema with usage constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it analyzes multiple dates for auspiciousness, returns scores/levels, and highlights best/worst. It distinguishes from single-date siblings like check_auspicious_date.
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?
Explicitly describes use cases: bulk analysis, comparing options, evaluating non-continuous ranges. Lacks explicit when-not-to-use but strongly implies single-date tools are alternatives.
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:

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

Score Badge

Copy to your README.md:

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

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