Deterministic calendars, seasons, moon phases, retrogrades, and symbolic systems as stable JSON for AI agents via MCP. Gregorian dates 1900–2100; same date → same bytes.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.6/5 across 3 of 3 tools scored.
Each tool has a uniquely scoped purpose: get_date for single-date queries, get_compatibility for two-date comparisons, and get_name for text/name inputs. The descriptions explicitly cross-reference each other to prevent misselection.
All tool names follow the consistent 'get_' + noun pattern: get_date, get_compatibility, get_name. This is a uniform verb_noun convention with no deviations.
Three tools is a well-scoped count for the server's astrological/numerology domain. Each tool covers a distinct and substantial function, and the small count avoids bloat while providing the necessary entry points.
The tool set covers the primary use cases: single date analysis, two-person compatibility, and name-based gematria. Minor gaps exist (e.g., no two-name compatibility or batch date processing), but these are not core to the server's stated purpose.
get_compatibilityCompatibility (two dates)AUSE when comparing exactly two people by Gregorian date. NOT for one date (moon/season/Rx/weekday/leap year/day_ruler → get_date) or names → get_name. Requires date_a and date_b. RETURNS scored dyad: cosmic_card_a/b (each side is full get_date shape incl. tarot_majors.greer/tarot_school, karma, planetary_spread; Cosmic card = birth = life = sun via also_called; planetary_spread and retrogrades_active planets include planet_type/symbol/emoji + names{} 10 cultures; each planetary_spread slot carries spread_pos 1-14 — sort by spread_pos for canonical Life-spread order), connections, overall_score, Chinese zodiac + true sidereal aspects, element harmony, life paths. temporal_context.date_a/b = {band, payload_scope} (full|extended|out_of_range × full|cosmic_card_only; 1900-2100 focus).
| Name | Required | Description | Default |
|---|---|---|---|
| date_a | Yes | Person A date YYYY-MM-DD (exactly two people; not a roster) | |
| date_b | Yes | Person B date YYYY-MM-DD (exactly two people; not a roster) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the annotations, detailing the full return structure: cosmic_card_a/b, connections, overall_score, temporal_context, and ordering semantics (spread_pos sort order). It also explains aliases like 'Cosmic card = birth = life = sun' and the payload_scope in temporal_context. No contradictions with the readOnly/idempotent/destructive annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with usage, exclusions, and requirements before diving into output details. It is dense and well-organized, but the single continuous block of text with heavy semicolon use makes it less scannable than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Since there is no output schema, the description carries the full burden of explaining return values, and it does so thoroughly: it lists all major fields, nested structures, cultural name variants, and temporal_context bands. The agent has enough information to invoke the tool and interpret complex results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes both parameters with format, Person A/B semantics, and the 'not a roster' clarification, so the description adds little new parameter-level information beyond restating that both are required. With 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's exact purpose: comparing exactly two people by Gregorian date. It also distinguishes itself from sibling tools by explicitly naming get_date for single-date queries and get_name for name-based queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use and when-not-to-use guidance, including which sibling tool to use instead for one-date or name scenarios. It also clarifies the requirement for both date_a and date_b parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_dateDate identity (any date)APRIMARY single-date tool. USE for any one Gregorian date when the ask needs moon phase (incl. blue/blood/supermoon/micromoon flags, Earth-Moon distance, phase_gmt, prev/next blue or blood dates), season/equinox anchors, classical retrogrades (retrogrades_active phase=retrograde), calendars, lunar year, Cosmic card (same card as life/sun — cosmic.also_called + planetary_spread.sun), karmic source/spirit, 14 planetary Life-spread cards, weekday or leap year (calendar_meta.weekday / is_leap_year), day_ruler (weekday planetary ruler Roman/Greek/Norse), or full date identity. NOT for two-person scoring → get_compatibility; name text → get_name. RETURNS cosmic block (incl. karma + planetary_spread) + tarot_majors (greer + tarot_school) + day_ruler (full+extended) + temporal blocks (moon_phase, season, retrogrades_active, calendar_meta, …). planetary_spread and retrogrades_active planets include planet_type/symbol/emoji + names{} (greek,norse,celtic,egyptian,sumerian,babylonian,mesopotamian,arabic,sanskrit,chinese). Each planetary_spread slot carries spread_pos (1-14 canonical Life-spread order; midheaven=13, phoenix=14 — sort by spread_pos; jsonb object keys are unordered). temporal_context={band, payload_scope} (band full|extended|out_of_range; payload_scope full|cosmic_card_only). Out-of-range responses set cosmic_card_available.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Single query date YYYY-MM-DD (any Gregorian date — sky, calendars, weekday, leap year, day_ruler, Cosmic card) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only/idempotent annotations, the description discloses key behavioral details such as 'spread_pos (1-14 canonical Life-spread order; midheaven=13, phoenix=14 — sort by spread_pos; jsonb object keys are unordered)', the temporal_context band/payload_scope, and out-of-range behavior setting cosmic_card_available. These are non-obvious behaviors not inferable from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long and dense, but every section contributes value. It is front-loaded with the primary use case and exclusions, then systematically enumerates return blocks and special attributes. The extensive name list (greek, norse, celtic, etc.) makes it verbose but is necessary given the lack of output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and high complexity, the description is remarkably comprehensive. It enumerates all major return blocks (cosmic, tarot_majors, day_ruler, temporal), details nested structures like planetary_spread and retrogrades_active, explains sorting requirements (spread_pos), and covers edge cases like out-of-range. This gives the agent sufficient information to invoke the tool and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'date' parameter, providing format and pattern. The description adds semantic context about what dates are valid ('any Gregorian date') and describes out-of-range response behavior, which slightly exceeds the schema baseline but does not introduce new parameter syntax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'PRIMARY single-date tool' that returns comprehensive date identity data (moon phase, season, retrogrades, calendars, etc.). It explicitly distinguishes itself from siblings with 'NOT for two-person scoring → get_compatibility; name text → get_name', making the scope unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is explicit: 'USE for any one Gregorian date when the ask needs...' followed by a detailed list of triggers. It also provides clear exclusions and alternative tool names, which is exactly what an agent needs to select the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_nameName → cosmic cardsAUSE for person or word name text only (gematria → cosmic cards). NOT for any date questions (weekday, leap year, moon, season, Rx, Cosmic card, day_ruler) → get_date; two people → get_compatibility. RETURNS Francis Bacon cards, Latin cipher suite, periodic{} + periodic_set{}. Free-text input guard.
| Name | Required | Description | Default |
|---|---|---|---|
| full_name | Yes | Person or word name to decode (whitespace-separated words; not a date) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only/idempotent behavior, so the description adds value by disclosing the return payload (Francis Bacon cards, Latin cipher suite, periodic{} and periodic_set{}) and a 'free-text input guard' hint. These details go beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense and front-loaded with usage, exclusions, and return details. The cryptic 'Free-text input guard' fragment is slightly ambiguous but does not add unnecessary bulk; overall each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the one-parameter tool, rich annotations, and no output schema, the description fills the essential gap by stating return values. It also covers usage, exclusions, and alternatives, making it functionally complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds only minor domain framing (gematria) but doesn't provide new semantics beyond what the schema's parameter description already covers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb-resource pair: 'USE for person or word name text only' with the transformation 'gematria → cosmic cards'. It explicitly distinguishes from siblings by excluding date and two-person queries, making it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use ('for person or word name text only') and when-not-to-use (date questions, two people) are provided, directly naming alternatives get_date and get_compatibility. This leaves no room for confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
