astro-cosmic-weather-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose: current moon state, phase events, sign ingress events, void-of-course windows, natal computation, Mercury retrogrades, solar terms, sabbats, a merged feed, and health check. The flagship cosmic_weather tool is explicitly presented as an aggregation, reducing overlap.
Naming Consistency4/5
Tool names use a consistent lowercase snake_case style with descriptive noun phrases (moon_phases, solar_terms, sabbats). Minor inconsistency: natal_moon breaks the moon_ prefix pattern used by other moon tools, and there is no verb_noun pattern, but the naming is still predictable.
Tool Count5/5
10 tools is well-scoped for an astro-cosmic weather server, covering the moon, Mercury, solar terms, sabbats, and a combined feed. Each tool adds distinct value without redundancy.
Completeness4/5
The set covers current and natal moon states, future/past event lists, windows, retrogrades, solar terms, and sabbats, plus a health check. Gaps include lack of other planetary retrograde tools and no direct 'moon at date' tool, but inferring from ingresses is possible.
Average 4.6/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clarifies the 'current' nature and the timezone handling, but it does not mention potential edge cases (e.g., invalid timezone), side effects, or affirm read-only safety. The description is adequate but not rich in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose sentence, usage examples, and a labeled Args section. Every sentence adds value; there is no filler or repetition.
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 simplicity (one optional parameter) and the presence of an output schema, the description provides sufficient contextual coverage. It explains what the tool returns, when to use it, and the one parameter's meaning, leaving 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?
The schema only provides the parameter name, type, and default value. The description adds a detailed explanation of tz, including its purpose for timestamps, concrete timezone examples, and the default 'UTC'. This fully compensates for the 0% schema description 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 opens with a specific verb and resource: 'Get the Moon's CURRENT (right-now) position and phase', and enumerates the exact data fields (zodiac sign, ecliptic longitude, phase name, illumination percentage). It clearly distinguishes from sibling tools by emphasizing 'right-now' and contrasting with future/past dates.
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 explicitly states when to use the tool with sample user queries and adds the exclusion 'not a future/past date'. However, it does not name a specific alternative tool, so it lacks the full 'alternatives' component required for a 5.
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, the description carries the burden of behavioral disclosure. It reveals that the tool lists events (read-only), defaults to now through +90 days, and returns timestamps localized to an IANA timezone. It doesn't mention pagination, rate limits, or authentication, but for a simple read-only list tool this is adequate.
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 front-loaded with the core purpose and usage trigger, followed by a concise Args block. Every sentence adds value, and the format is easy to scan for an 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?
For a tool with 3 params, an output schema, no required params, and clear defaults, this description is nearly complete. It could briefly contrast with the 'sabbats' tool to prevent confusion, but the core information needed for correct selection and invocation is present.
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?
Schema description coverage is 0%, so the description must fully compensate. It explains each parameter (from_date, to_date, tz) with examples, defaults, and important semantic details like 'Omit for starting now' and 'Omit for 90 days from the start.' This is exemplary parameter documentation.
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 ('List') and identifies the exact resources: solstices, equinoxes, and cross-quarter days. This clearly distinguishes it from sibling tools like moon_phases and sabbats, which cover different astronomical/calendar events.
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 explicit 'Use this when' guidance with concrete user queries ('when is the next equinox?') and describes the default behavior when no range is supplied. It does not explicitly mention when not to use it or suggest alternative tools, but the guidance is clear enough for selection.
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 disclosure. It does a good job by explaining default date ranges ('now through +90 days'), the paired nature of the results, and the need to start the range before today for current retrograde checks. It does not describe exact output structure, but the output schema covers that.
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 well-structured: purpose first, then usage guidance, then argument details. Every sentence provides useful information, and there is no repetition or fluff.
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 two optional parameters, clear defaults, and an output schema, the description is complete. It covers invocation scenarios, parameter semantics, and behavioral nuances, so the agent can select and call it correctly without additional context.
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 only provides parameter names and types, with zero description coverage. The tool description compensates fully by explaining each parameter's meaning, format, and default behavior, including examples and guidance on omission.
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 'List Mercury retrograde windows (paired start/end dates) within a date range,' which names a specific action, resource, and scope. It distinguishes itself from sibling tools by focusing on Mercury retrograde periods rather than moon-related phenomena.
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 explicitly lists example user queries that should trigger this tool and explains how to handle the 'right now' case. It does not explicitly state when not to use it or name alternative tools, but the use cases are clear and cover the main scenarios.
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. It discloses the default date range (now through +90 days) and clarifies timezone handling (IANA timezone for returned timestamps and local-time labeling). This is meaningful behavioral context, though it does not mention auth/rate limits or sorting behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly structured: purpose statement, usage examples, default behavior, then parameter breakdown. Every sentence adds value, with no fluff or repetition. Front-loaded with the core function.
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 presence of an output schema (which handles return field details), the description sufficiently covers the main behavioral aspects: what is returned (four phase types), date range semantics, default behavior, and timezone handling. The examples ensure the agent can select this tool appropriately among numerous siblings.
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 description fully compensates. Each parameter (from_date, to_date, tz) is explained with ISO 8601 examples, defaults, and semantic meaning (e.g., 'Omit for starting now'). This exceeds the baseline and leaves no ambiguity.
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 opens with a specific verb 'List' and explicitly names the four moon phase events (New Moon / First Quarter / Full Moon / Last Quarter) within a date range. This clearly distinguishes from siblings like moon_current (which returns the current phase) and moon_void_of_course.
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 explicit when-to-use guidance with concrete example queries ('when is the next full moon?', 'list the moon phases this month'). Does not explicitly state when not to use or name alternative sibling tools, but the examples effectively communicate 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden and discloses important behaviors: defaults to now through +90 days, ISO 8601 date formats, and timezone handling. It does not mention error conditions or rate limits, but the presence of an output schema reduces the need to describe return values, and the disclosed defaults are valuable 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 front-loaded with the core purpose in the first sentence, followed by usage examples and defaults. The Args section is clearly structured and concise. Every sentence adds necessary information without redundancy.
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 moderately complex with three optional parameters, an output schema, and several sibling tools. The description covers what the tool does, when to use it, parameter semantics, and default behaviors. The output schema handles return-value documentation, so nothing critical is missing.
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?
Schema description coverage is 0% (the schema itself has no property descriptions), but the tool description fully compensates with an Args section. It explains each parameter's meaning, format (ISO 8601), examples, omit behavior, and timezone default. This adds significant value beyond the bare schema 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 uses a specific verb ('List') and resource ('Moon zodiac sign ingress events'), defines exactly what constitutes an ingress (the moment the Moon moves from one sign into the next), and provides example user queries. This clearly distinguishes it from sibling tools like moon_phases and moon_void_of_course.
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 explicitly states 'Use this when...' and gives concrete user-phrase examples, making the primary use case clear. It also explains default date-range behavior. However, it does not explicitly mention alternatives or say when not to use this tool, though the specificity inherently differentiates it from 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, the description carries the full burden. It discloses default range behavior (now through +90 days), optional parameter omission semantics, and timezone defaults. It does not discuss rate limits or output format, but the output schema covers the latter.
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 well-structured: purpose first, then usage examples, then defaults, then an Args section with each parameter clearly described. Every sentence adds value with no fluff.
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 simple read-only list tool with 3 optional parameters, the description covers purpose, usage, parameter semantics, defaults, and timezone handling. The output schema exists, so return values need not be repeated. This is complete.
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?
Schema description coverage is 0%, but the description compensates fully by explaining each parameter: start/end of range, ISO 8601 format, defaults, and what omission means. This goes well beyond the schemas' 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 uses a specific verb 'List' and resource 'Void-of-Course Moon windows', defines the concept, and scopes it to a date range. This clearly distinguishes it from sibling tools like moon_phases or moon_current.
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 explicitly states 'Use this when the user asks...' with concrete example queries, providing strong when-to-use guidance. However, it does not mention when not to use or name alternatives, so it misses the full 5 criterion.
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, the description carries the behavioral burden. It discloses that southern hemisphere dates are offset by ~6 months and that hemisphere defaults to 'north', which are key behavioral traits. It doesn't explicitly mention read-only status but that is implied for a listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly written: purpose first, then usage examples, then behavioral note, then parameter definitions. Every sentence adds value, no redundancy or fluff.
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?
Comprehensive for a simple two-param listing tool. Covers purpose, usage, hemisphere behavior, parameters, and output schema is present. No significant 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?
The input schema has no descriptions (0% coverage), but the description fully explains both parameters: year (optional, current year if omitted) and hemisphere (north/south, with default and reason for offset). This goes well 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 tool lists Wheel of the Year sabbats with specific dates for a given year and hemisphere. It provides the exact sabbat names and examples of user queries, distinguishing it from sibling tools like moon_phases or solar_terms.
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?
Explicit when-to-use guidance is given via example queries and reference to the pagan/wiccan wheel of the year. However, no alternatives or when-not-to-use exclusions are stated, though sibling names make the scope fairly clear.
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. It discloses that no API key is required and implies a safe, read-only diagnostic operation. It does not explicitly state side effects or response format, but the output schema covers the latter.
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, front-loaded with the purpose, and every sentence adds value. It is efficient with no wasted words.
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 simplicity (0 params, output schema provided), the description fully covers purpose, usage context, and auth requirements. It leaves no significant gaps for an agent to misuse or misunderstand the 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 input schema has zero parameters, so the baseline is 4. The description adds no parameter-specific detail because none exist; it is appropriately scoped for a parameterless health check.
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 whether the Ephemeris & Cosmic-Weather API is reachable and healthy. This distinguishes it from sibling data tools, which focus on specific astronomical/astrological data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool to diagnose connection problems before assuming a specific data tool is broken, even providing an example (connection/timeout error). This gives clear contextual guidance on when to invoke 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 carries the full burden of behavioral disclosure. It explains that the tool returns a merged, chronological feed, includes all event types, and adds a human-readable headline. It also details the 'days' and 'tz' behavior. It does not mention rate limits or error handling, but for a read-only aggregation tool, the behavioral context is sufficiently 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 well-structured and front-loaded with the 'FLAGSHIP tool' label. It opens with a clear purpose, then provides usage guidance, then parameter details. Each sentence serves a purpose and there is no redundancy. It is longer than minimal but earns its length through rich guidance.
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 complexity of a combined feed covering multiple event types, the description is complete. It covers what the tool does, when to use it, how parameters behave, and the nature of the output (merged chronological feed plus headline). The presence of an output schema means return values need not be spelled out, and the description fills all 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?
Schema description coverage is 0%, so the description compensates fully. It explains 'days': 'How many days ahead to include, starting from now. Defaults to 7. Use larger values (e.g. 30) for "this month" style questions.' It explains 'tz': 'IANA timezone name for event timestamps and local-time labeling. Defaults to "UTC".' This adds meaningful semantics beyond the raw 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's purpose: 'get a single merged, chronological cosmic weather feed combining every event type.' It uses a specific verb (get), a specific resource (cosmic weather feed), and distinguishes itself from sibling tools by being the default/first tool for broad questions. It explicitly contrasts with tools scoped to one event type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'Use this as the default/first tool when the user asks broad questions...' It gives concrete examples and states that it is the 'richest single call' and 'usually answers the question without needing any other tool.' It implies when not to use it (when the query is scoped to one event type), effectively covering alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well: it discloses default time (12:00), default timezone (UTC), warns that sign may be inexact if Moon changes signs, and emphasizes timezone must be the birth location's then-effective zone. This goes beyond basic operation.
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?
Every sentence serves a purpose: main action, usage trigger, fallback behavior, and parameter specifications. The Args section is cleanly structured without redundancy.
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?
Output schema exists, so return values need not be explained. Input handling, defaults, and edge cases (unknown time, wrong timezone) are all covered. This is complete for a computational astrology tool.
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?
Schema coverage is 0%, but the description explains each parameter in detail: date format (ISO 8601), time format (24-hour HH:MM) plus default, tz format (IANA) plus default and correctness caveat. Fully compensates for the schema's lack of 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?
Description uses a specific verb+resource: 'Compute the natal (birth) Moon placement' and lists concrete outputs (zodiac sign, phase, illumination). It clearly distinguishes from siblings like 'moon_current' by tying to birth date/time context.
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?
Explicit usage trigger is given: 'Use this when the user asks "what was my moon sign?" or gives a specific birth date/time...'. It also provides guidance for missing time and timezone caveats, though it doesn't explicitly name alternative tools for when not to use.
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:

[![astro-cosmic-weather-mcp MCP server](https://glama.ai/mcp/servers/ncreighton/astro-cosmic-weather-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ncreighton/astro-cosmic-weather-mcp)

Score Badge

Copy to your README.md:

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

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