A
licenseNot graded
qualityB
maintenanceHigh-precision astrology tools for LLM agents, including natal charts, transits, progressions, synastry, and more, backed by Swiss Ephemeris.
1
MIT
Astrology Forecast MCP Server by RoxyAPI
by com.roxyapi
Server Details
Astrology transit forecasts, timelines and significant-date feeds for AI agents.
Ownership verified
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Available Tools
5 toolspost_forecast_digestForecast digest - Pre-summarized next 24h, 7d, 30d, and 90d rollupsARead-onlyInspect
Roll the cross-domain forecast for a single birth subject into four pre-summarized windows: the next 24 hours, 7 days, 30 days, and 90 days from the start date. Each window returns its event count, a per-domain count breakdown, a per-type count breakdown, and the top highest-significance events. Built for a glanceable what-is-coming strip so a caller can render the upcoming highlights without scanning the full event list.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | Number of highest-significance events to surface per window. Defaults to 3, capped at 20. | |
| lang | No | Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English. | en |
| compact | No | Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens. | |
| domains | No | Which forecast domains to include before rolling up the windows. Defaults to all three. | |
| birthData | Yes | The single birth subject this digest is built for. One object only, never an array. | |
| startDate | No | Start anchor for every window in YYYY-MM-DD format. The next 24h, 7d, 30d, and 90d windows are measured forward from this date at 00:00:00 UTC. Defaults to today in UTC. | |
| domainWeights | No | Per-domain significance multipliers applied before the significance floor and event cap. Bias which domains survive filtering and the cap. Omitted domains default to a weight of 1. Valid keys are western, vedic, and biorhythm. | |
| minSignificance | No | Drop events scoring below this significance threshold from 0 to 100 before the rollup. Defaults to 0. |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as readOnlyHint=true and destructiveHint=false. The description adds complementary behavior detail: it aggregates into four windows, counts, and top events, and emphasizes it is purely a summarization operation. This aligns with the read-only hint and gives the agent confidence it has no side effects. It doesn't waste space restating the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences that are dense and purposeful: the first identifies the action and windows, the second enumerates the output structure, the third provides the use case. No wasted words, and the key action and purpose are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, nested objects, and no output schema, the description provides a solid high-level contract: four windows each with counts, breakdowns, and top events. An agent can anticipate the shape of the result. It stops short of specifying the exact JSON structure or array ordering, but the schema and examples handle parameter details. Given no output schema, this level of responsiveness is nearly 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?
Input schema covers 100% of parameters with detailed descriptions (e.g., top's max, lang fallback, compact's token savings, domains enum, birthData fields). The description itself adds no parameter semantics beyond saying windows are measured 'from the start date,' which is already documented in startDate. Since the schema carries the burden, a 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?
The description uses a concrete verb ('Roll') with a clear resource ('cross-domain forecast for a single birth subject') and specifies the exact output: four windows with counts, per-domain and per-type breakdowns, and top events. This differentiates it from siblings like post_forecast_timeline or post_forecast_transits, which would return event lists rather than pre-summarized rollups.
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 a clear use context: 'Built for a glanceable what-is-coming strip ... without scanning the full event list.' This implies when to choose this over a timeline or raw forecast tool, though it doesn't explicitly name alternatives or give exclusion criteria. The context is strong enough to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
post_forecast_significant_datesSignificant dates - High-significance cross-domain forecast highlightsARead-onlyInspect
Return only the high-significance dates from the merged cross-domain forecast for a single birth subject: the rare outer-planet exact transit aspects, slow-planet sign ingresses, retrograde stations, and Vimshottari mahadasha and antardasha changes that mark genuine turning points. Defaults to a significance floor of 70 so the response is a short list of the most meaningful upcoming dates. Built for what-is-coming highlights, timing alerts, and at-a-glance forecast strips.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English. | en |
| compact | No | Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens. | |
| domains | No | Which forecast domains to consider before filtering by significance. Defaults to all three. | |
| endDate | No | Last day of the window in YYYY-MM-DD format. Defaults to startDate plus 30 days. Clamped to a maximum of 90 days from startDate. | |
| birthData | Yes | The single birth subject this forecast is built for. One object only, never an array. | |
| startDate | No | First day of the window in YYYY-MM-DD format. Defaults to today in UTC. | |
| domainWeights | No | Per-domain significance multipliers applied before the significance floor and event cap. Bias which domains survive filtering and the cap. Omitted domains default to a weight of 1. Valid keys are western, vedic, and biorhythm. | |
| minSignificance | No | Significance floor from 0 to 100 for what counts as a significant date. Defaults to 70. |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark the tool as read-only, and the description adds useful behavioral context: it is a filtered, merged-domain view, with a significance floor of 70 and a deliberately short output. It does not describe the full response item shape, but this is a minor gap given the read-only safety profile and schema coverage.
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 compact and front-loaded; the first sentence gives the core behavior and scope, the second sets expectations about output length, and the last mentions the intended use cases. Every sentence carries content without filler.
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 an 8-parameter tool with a nested required object, the description gives enough high-level context to select and call it correctly, especially because the schema documents each parameter thoroughly and annotations mark it read-only. It could be more complete by describing the output item shape or ordering, since no output schema is provided.
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% and every parameter already has a detailed description. The tool description only restates the minSignificance default, so it adds little parameter-level meaning 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 states a specific verb and resource: 'Return only the high-significance dates from the merged cross-domain forecast' and enumerates the event classes included. It is clear enough to distinguish the tool's focus, though it does not explicitly contrast it with the sibling forecast tools.
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 intended use cases: 'what-is-coming highlights, timing alerts, and at-a-glance forecast strips' and explains that the significance floor yields a short result list. It implies when this tool is appropriate but does not name exclusions or direct agents toward alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
post_forecast_solar_returnSolar return chart - Annual birthday forecast chart for a single subjectARead-onlyInspect
Cast the solar return chart for one subject and year: the chart erected for the exact moment the transiting Sun returns to its natal ecliptic longitude, the foundational technique for annual astrological forecasting. Returns the full tropical chart with planetary positions, house cusps, aspects, Ascendant, and Midheaven. Location-sensitive: pass the birthplace to anchor the chart to natal geography, or the current city for a relocated solar return where the houses and Ascendant shift to where you are on your birthday. Built for year-ahead forecast tools, birthday charts, and annual horoscope features.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Birth date in YYYY-MM-DD format. Anchors the natal Sun longitude the transiting Sun returns to each year. | |
| lang | No | Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English. | en |
| time | Yes | Birth time in 24-hour HH:MM:SS format. Pins the exact natal Sun position that defines the solar return moment. | |
| year | Yes | Year to cast the solar return for. The chart is erected for the moment in this year when the transiting Sun returns to the natal Sun longitude, on or within a day of the birthday. | |
| compact | No | Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens. | |
| latitude | Yes | Latitude of the solar return location in decimal degrees. The solar return is location-sensitive: use the birthplace to anchor the chart to natal geography, or the current city for a relocated solar return. | |
| timezone | Yes | IANA name (e.g. "America/New_York", "Europe/London", "UTC"), decimal hours (e.g. -5 for EST, 1 for CET), or a fixed UTC offset (e.g. "-05:00", "+01:00"). Prefer the IANA name: it is resolved to the DST-correct offset for the birth date, while a fixed offset or decimal is taken literally and will be wrong if it does not match the daylight-saving state on that date. Invalid timezones return 400 with a validation error. | |
| longitude | Yes | Longitude of the solar return location in decimal degrees. Sets the local sidereal time, so it drives the Ascendant, Midheaven, and house cusps of the return chart. | |
| houseSystem | No | House system for the return chart. placidus is the Western default. whole-sign, equal, and koch are also supported. | placidus |
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool safe (readOnlyHint=true, destructiveHint=false), so the description adds valuable behavioral nuance: the technique of waiting for the transiting Sun to return to natal longitude, and how location shifts the houses/Ascendant/MC. It also states what the returned chart includes. There is no contradiction and the behavior is clearly disclosed beyond the annotation defaults.
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 with no redundant filler. The core function is front-loaded, followed by return contents, then the location nuance, then expected use cases. It is compact but comprehensive and every sentence 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?
With no output schema, the description does state the returned components (planetary positions, house cusps, aspects, Ascendant, Midheaven) and faithfully describes the two usage patterns. Combined with full schema documentation and helpful annotations, the definition gives enough context for an agent to call and interpret the result correctly. It could benefit from an exact response shape or a what- the lack of roles, but this is not a significant gap.
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 already has full, rich descriptions for all 9 parameters (100% coverage), so the description's extra parameter-specific information is minimal. The description does reinforce the location-sensitive distinction between place of birth and relocated view, but most parameter meaning is already in the schema. This is a solid baseline, and the description does not meaningfully exceed it.
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 specifies the action ('Cast the solar return chart') with a specific resource and what is returned (full chart with planets, houses, aspects, Ascendant, Midheaven). It anchors the tool to the annual forecasting theme and prevents confusion with general forecast-related siblings, though it never names them directly. The purpose is obvious and well-scoped, but explicit sibling differentiation is missing.
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 gives helpful context for using the tool: it is built for year-ahead forecast tools, birthday charts, and annual horoscope features; it explains birthday vs. relocated charts. It does not mention alternatives explicitly or state when NOT to use this tool, so it stops just short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
post_forecast_timelineCross-domain forecast timeline - Transits, ingresses, stations, dasha changes, critical daysARead-onlyInspect
Build one time-ordered forecast for a single birth subject by merging upcoming events across three domains: western transit-to-natal aspects, sign ingresses, retrograde stations, eclipses, and new and full moons; biorhythm critical days; and vedic Vimshottari mahadasha, antardasha, and pratyantardasha boundaries. The window is clamped to 90 days and events are capped and scored by significance. Built for what-is-coming dashboards, daily and weekly forecast feeds, and timing tools.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English. | en |
| compact | No | Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens. | |
| domains | No | Which forecast domains to include. Defaults to all three. Pass a subset to scope the timeline to one or two engines. | |
| endDate | No | Last day of the forecast window in YYYY-MM-DD format. Defaults to startDate plus 30 days. The window is clamped to a maximum of 90 days from startDate. | |
| birthData | Yes | The single birth subject this forecast is built for. One object only, never an array. | |
| startDate | No | First day of the forecast window in YYYY-MM-DD format. Defaults to today in UTC. | |
| domainWeights | No | Per-domain significance multipliers applied before the significance floor and event cap. Bias which domains survive filtering and the cap. Omitted domains default to a weight of 1. Valid keys are western, vedic, and biorhythm. | |
| minSignificance | No | Drop events scoring below this significance threshold from 0 to 100. Defaults to 0, keeping all events. |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true and destructiveHint=false already covering the safety profile, the description adds useful context: the window is 'clamped to 90 days' and events are 'capped and scored by significance.' These are meaningful behavioral constraints beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no wasted text: the first defines the core output and domain merge, the second states hard constraints (clamping, capping, significance), and the third names the intended use cases. Every sentence contributes essential 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 no output schema, the description does a good job of conveying the overall behavior, constraints, and intended consumers. However, the exact response shape (e.g., an array of events with date and significance) is only implied by 'time-ordered forecast' and not explicitly stated.
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% description coverage for all parameters, so the baseline is 3. The description only implies the overall merging of domains and scoring behavior, but it does not need to explain individual parameters because the schema already does so thoroughly.
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 'Build one time-ordered forecast for a single birth subject by merging upcoming events across three domains,' which states a specific verb, resource, and scope. It also names the concrete output (forecast timeline across western, vedic, and biorhythm) and distinguishes it from single-domain siblings like post_forecast_transits.
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 closes with 'Built for what-is-coming dashboards, daily and weekly forecast feeds, and timing tools,' giving clear use cases. It does not explicitly name sibling alternatives or when not to use this tool, but the use context is unambiguous enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
post_forecast_transitsWestern astrology forecast - aspects, ingresses, stations, eclipses, moon phasesARead-onlyInspect
Forecast the western astrology events for a single birth chart over a window up to 90 days: every transit-to-natal major aspect refined to its exact instant, every transiting planet sign ingress, every retrograde or direct station, every solar and lunar eclipse, and every New and Full Moon. Returns a time-ordered, significance-scored timeline. Built for astrology forecast feeds, transit alerts, and timing tools.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English. | en |
| compact | No | Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens. | |
| endDate | No | Last day of the transit window in YYYY-MM-DD format. Defaults to startDate plus 30 days. Clamped to a maximum of 90 days from startDate. | |
| birthData | Yes | The single birth subject this transit forecast is built for. One object only, never an array. | |
| startDate | No | First day of the transit window in YYYY-MM-DD format. Defaults to today in UTC. | |
| minSignificance | No | Drop transit events scoring below this significance threshold from 0 to 100. Defaults to 0. |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, which establishes the safety profile. The description adds meaningful context beyond that: it discloses the full event set covered, the exact-instant refinement, the time ordering, and the significance scoring. It doesn't mention response size or execution time, but the listed behavior is transparent and aligns with a read-only forecast 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?
Four sentences, no filler, and the core message is front-loaded. The first sentence gives the verb, resource, and window; the second enumerates coverage; the third defines the output; the fourth states use cases. Every sentence 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?
For a read-only, single-request tool with no output schema, the description covers inputs, output, event scope, and purpose. The only missing piece is an explicit statement of the output shape or element structure, but the phrase 'time-ordered timeline' and the per-event enumeration make that reasonably inferable. A 5 would require more on output format.
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 the schema already documents all parameters well; baseline is 3. The description adds extra value by explicitly noting the 90-day cap (reinforcing startDate/endDate semantics) and by saying the timeline is significance-scored (connecting to minSignificance). This goes slightly beyond the schema without redundancy.
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 begins with a precise verb ('Forecast') and resource ('western astrology events for a single birth chart over a window up to 90 days'), then enumerates every event type covered: transit-to-natal aspects, sign ingresses, stations, eclipses, and New/Full Moons. It ends with a clear deliverable ('time-ordered, significance-scored timeline') and use cases, making it easy for an agent to distinguish from the sibling forecast tools.
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 gives concrete use cases ('Built for astrology forecast feeds, transit alerts, and timing tools') and explicitly scopes the window to 90 days. It does not name sibling tools like post_forecast_digest or post_forecast_timeline as alternatives, but the event-type enumeration and timeline description make it clear when this tool should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
5 tool updates
- Changed
post_forecast_digest2 fields changed- changed
Input schema / properties / lang / descriptionPrevious value: -"Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English."New value: +"Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English." - changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "tr", - "de", - "es", - "hi", - "pt", - "fr", - "ru" -]New value: +[ + "en", + "tr", + "de", + "es", + "hi", + "pt", + "fr", + "ru", + "zh-Hans", + "zh-Hant" +]
- Changed
post_forecast_significant_dates2 fields changed- changed
Input schema / properties / lang / descriptionPrevious value: -"Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English."New value: +"Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English." - changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "tr", - "de", - "es", - "hi", - "pt", - "fr", - "ru" -]New value: +[ + "en", + "tr", + "de", + "es", + "hi", + "pt", + "fr", + "ru", + "zh-Hans", + "zh-Hant" +]
- Changed
post_forecast_solar_return2 fields changed- changed
Input schema / properties / lang / descriptionPrevious value: -"Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English."New value: +"Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English." - changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "tr", - "de", - "es", - "hi", - "pt", - "fr", - "ru" -]New value: +[ + "en", + "tr", + "de", + "es", + "hi", + "pt", + "fr", + "ru", + "zh-Hans", + "zh-Hant" +]
- Changed
post_forecast_timeline2 fields changed- changed
Input schema / properties / lang / descriptionPrevious value: -"Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English."New value: +"Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English." - changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "tr", - "de", - "es", - "hi", - "pt", - "fr", - "ru" -]New value: +[ + "en", + "tr", + "de", + "es", + "hi", + "pt", + "fr", + "ru", + "zh-Hans", + "zh-Hant" +]
- Changed
post_forecast_transits2 fields changed- changed
Input schema / properties / lang / descriptionPrevious value: -"Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English."New value: +"Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English." - changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "tr", - "de", - "es", - "hi", - "pt", - "fr", - "ru" -]New value: +[ + "en", + "tr", + "de", + "es", + "hi", + "pt", + "fr", + "ru", + "zh-Hans", + "zh-Hant" +]
5 tool updates
- Changed
post_forecast_digest2 fields changed- added
Input schema / examplesAdded value: +[ + { + "birthData": { + "date": "1990-07-15", + "time": "13:30:00", + "timezone": "America/New_York" + } + } +] - changed
Input schema / properties / compact / descriptionPrevious value: -"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."New value: +"Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {\"__cols\":[names],\"__rows\":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens."
- Changed
post_forecast_significant_dates2 fields changed- added
Input schema / examplesAdded value: +[ + { + "birthData": { + "date": "1990-07-15", + "time": "13:30:00", + "timezone": "America/New_York" + } + } +] - changed
Input schema / properties / compact / descriptionPrevious value: -"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."New value: +"Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {\"__cols\":[names],\"__rows\":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens."
- Changed
post_forecast_solar_return2 fields changed- added
Input schema / examplesAdded value: +[ + { + "date": "1990-07-15", + "latitude": 40.7128, + "longitude": -74.006, + "time": "14:30:00", + "timezone": "America/New_York", + "year": 2026 + } +] - changed
Input schema / properties / compact / descriptionPrevious value: -"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."New value: +"Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {\"__cols\":[names],\"__rows\":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens."
- Changed
post_forecast_timeline2 fields changed- added
Input schema / examplesAdded value: +[ + { + "birthData": { + "date": "1990-07-15", + "time": "13:30:00", + "timezone": "America/New_York" + } + } +] - changed
Input schema / properties / compact / descriptionPrevious value: -"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."New value: +"Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {\"__cols\":[names],\"__rows\":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens."
- Changed
post_forecast_transits2 fields changed- added
Input schema / examplesAdded value: +[ + { + "birthData": { + "date": "1990-07-15", + "time": "13:30:00", + "timezone": "America/New_York" + } + } +] - changed
Input schema / properties / compact / descriptionPrevious value: -"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."New value: +"Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {\"__cols\":[names],\"__rows\":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens."
5 tool updates
- Changed
post_forecast_digest1 field changed- changed
Input schema / properties / compact / descriptionPrevious value: -"Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false."New value: +"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."
- Changed
post_forecast_significant_dates1 field changed- changed
Input schema / properties / compact / descriptionPrevious value: -"Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false."New value: +"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."
- Changed
post_forecast_solar_return1 field changed- changed
Input schema / properties / compact / descriptionPrevious value: -"Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false."New value: +"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."
- Changed
post_forecast_timeline1 field changed- changed
Input schema / properties / compact / descriptionPrevious value: -"Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false."New value: +"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."
- Changed
post_forecast_transits1 field changed- changed
Input schema / properties / compact / descriptionPrevious value: -"Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false."New value: +"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."
5 tool updates
- Changed
post_forecast_digest1 field changed- added
Input schema / properties / compactAdded value: +{ + "default": false, + "description": "Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false.", + "type": "boolean" +}
- Changed
post_forecast_significant_dates1 field changed- added
Input schema / properties / compactAdded value: +{ + "default": false, + "description": "Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false.", + "type": "boolean" +}
- Changed
post_forecast_solar_return1 field changed- added
Input schema / properties / compactAdded value: +{ + "default": false, + "description": "Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false.", + "type": "boolean" +}
- Changed
post_forecast_timeline1 field changed- added
Input schema / properties / compactAdded value: +{ + "default": false, + "description": "Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false.", + "type": "boolean" +}
- Changed
post_forecast_transits1 field changed- added
Input schema / properties / compactAdded value: +{ + "default": false, + "description": "Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false.", + "type": "boolean" +}
5 tool updates
- Changed
post_forecast_digest3 fields changed- changed
Input schema / properties / birthData / properties / timezone / anyOfPrevious value: -[ - { - "maximum": 14, - "minimum": -14, - "type": "number" - }, - { - "pattern": "^[A-Za-z_]+(?:\\/[A-Za-z0-9_+-]+){0,2}$", - "type": "string" - } -]New value: +[ + { + "maximum": 14, + "minimum": -14, + "type": "number" + }, + { + "type": "string" + } +] - changed
Input schema / properties / birthData / properties / timezone / descriptionPrevious value: -"Decimal hours (e.g. 5.5 for IST, -5 for EST) OR IANA name (e.g. \"America/New_York\", \"UTC\"). IANA is resolved to the DST-correct offset for the request date. Invalid timezones return 400 with a validation error."New value: +"IANA name (e.g. \"America/New_York\", \"Europe/London\", \"UTC\"), decimal hours (e.g. -5 for EST, 1 for CET), or a fixed UTC offset (e.g. \"-05:00\", \"+01:00\"). Prefer the IANA name: it is resolved to the DST-correct offset for the birth date, while a fixed offset or decimal is taken literally and will be wrong if it does not match the daylight-saving state on that date. Invalid timezones return 400 with a validation error." - changed
Input schema / properties / birthData / properties / timezone / examplePrevious value: -5.5New value: +"America/New_York"
- Changed
post_forecast_significant_dates3 fields changed- changed
Input schema / properties / birthData / properties / timezone / anyOfPrevious value: -[ - { - "maximum": 14, - "minimum": -14, - "type": "number" - }, - { - "pattern": "^[A-Za-z_]+(?:\\/[A-Za-z0-9_+-]+){0,2}$", - "type": "string" - } -]New value: +[ + { + "maximum": 14, + "minimum": -14, + "type": "number" + }, + { + "type": "string" + } +] - changed
Input schema / properties / birthData / properties / timezone / descriptionPrevious value: -"Decimal hours (e.g. 5.5 for IST, -5 for EST) OR IANA name (e.g. \"America/New_York\", \"UTC\"). IANA is resolved to the DST-correct offset for the request date. Invalid timezones return 400 with a validation error."New value: +"IANA name (e.g. \"America/New_York\", \"Europe/London\", \"UTC\"), decimal hours (e.g. -5 for EST, 1 for CET), or a fixed UTC offset (e.g. \"-05:00\", \"+01:00\"). Prefer the IANA name: it is resolved to the DST-correct offset for the birth date, while a fixed offset or decimal is taken literally and will be wrong if it does not match the daylight-saving state on that date. Invalid timezones return 400 with a validation error." - changed
Input schema / properties / birthData / properties / timezone / examplePrevious value: -5.5New value: +"America/New_York"
- Changed
post_forecast_solar_return3 fields changed- changed
Input schema / properties / timezone / anyOfPrevious value: -[ - { - "maximum": 14, - "minimum": -14, - "type": "number" - }, - { - "pattern": "^[A-Za-z_]+(?:\\/[A-Za-z0-9_+-]+){0,2}$", - "type": "string" - } -]New value: +[ + { + "maximum": 14, + "minimum": -14, + "type": "number" + }, + { + "type": "string" + } +] - changed
Input schema / properties / timezone / descriptionPrevious value: -"Decimal hours (e.g. 5.5 for IST, -5 for EST) OR IANA name (e.g. \"America/New_York\", \"UTC\"). IANA is resolved to the DST-correct offset for the request date. Invalid timezones return 400 with a validation error."New value: +"IANA name (e.g. \"America/New_York\", \"Europe/London\", \"UTC\"), decimal hours (e.g. -5 for EST, 1 for CET), or a fixed UTC offset (e.g. \"-05:00\", \"+01:00\"). Prefer the IANA name: it is resolved to the DST-correct offset for the birth date, while a fixed offset or decimal is taken literally and will be wrong if it does not match the daylight-saving state on that date. Invalid timezones return 400 with a validation error." - changed
Input schema / properties / timezone / examplePrevious value: -5.5New value: +"America/New_York"
- Changed
post_forecast_timeline3 fields changed- changed
Input schema / properties / birthData / properties / timezone / anyOfPrevious value: -[ - { - "maximum": 14, - "minimum": -14, - "type": "number" - }, - { - "pattern": "^[A-Za-z_]+(?:\\/[A-Za-z0-9_+-]+){0,2}$", - "type": "string" - } -]New value: +[ + { + "maximum": 14, + "minimum": -14, + "type": "number" + }, + { + "type": "string" + } +] - changed
Input schema / properties / birthData / properties / timezone / descriptionPrevious value: -"Decimal hours (e.g. 5.5 for IST, -5 for EST) OR IANA name (e.g. \"America/New_York\", \"UTC\"). IANA is resolved to the DST-correct offset for the request date. Invalid timezones return 400 with a validation error."New value: +"IANA name (e.g. \"America/New_York\", \"Europe/London\", \"UTC\"), decimal hours (e.g. -5 for EST, 1 for CET), or a fixed UTC offset (e.g. \"-05:00\", \"+01:00\"). Prefer the IANA name: it is resolved to the DST-correct offset for the birth date, while a fixed offset or decimal is taken literally and will be wrong if it does not match the daylight-saving state on that date. Invalid timezones return 400 with a validation error." - changed
Input schema / properties / birthData / properties / timezone / examplePrevious value: -5.5New value: +"America/New_York"
- Changed
post_forecast_transits3 fields changed- changed
Input schema / properties / birthData / properties / timezone / anyOfPrevious value: -[ - { - "maximum": 14, - "minimum": -14, - "type": "number" - }, - { - "pattern": "^[A-Za-z_]+(?:\\/[A-Za-z0-9_+-]+){0,2}$", - "type": "string" - } -]New value: +[ + { + "maximum": 14, + "minimum": -14, + "type": "number" + }, + { + "type": "string" + } +] - changed
Input schema / properties / birthData / properties / timezone / descriptionPrevious value: -"Decimal hours (e.g. 5.5 for IST, -5 for EST) OR IANA name (e.g. \"America/New_York\", \"UTC\"). IANA is resolved to the DST-correct offset for the request date. Invalid timezones return 400 with a validation error."New value: +"IANA name (e.g. \"America/New_York\", \"Europe/London\", \"UTC\"), decimal hours (e.g. -5 for EST, 1 for CET), or a fixed UTC offset (e.g. \"-05:00\", \"+01:00\"). Prefer the IANA name: it is resolved to the DST-correct offset for the birth date, while a fixed offset or decimal is taken literally and will be wrong if it does not match the daylight-saving state on that date. Invalid timezones return 400 with a validation error." - changed
Input schema / properties / birthData / properties / timezone / examplePrevious value: -5.5New value: +"America/New_York"
5 tool updates
- First observed
post_forecast_digest - First observed
post_forecast_significant_dates - First observed
post_forecast_solar_return - First observed
post_forecast_timeline - First observed
post_forecast_transits
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Real astrology for AI agents: cosmic weather, synastry, timing, astrocartography, and divination.
Western natal charts, horoscopes, transits and synastry for AI agents, verified vs NASA JPL.
Vedic and Western astrology for AI agents: charts, dasha, matchmaking, panchanga, numerology, tarot.
1Аccess to personalized Enigmata astrological forecasts (day/week/month/thematic) for AI assistants
Related MCP Servers
- FlicenseNot gradedqualityCmaintenanceMulti-tradition astrology engine that computes real birth charts, transits, and synastry for AI agents via MCP tools.6-
- AlicenseAqualityAmaintenanceAstrology MCP server that computes natal charts, transits, synastry, progressions, returns, eclipses, retrogrades, and moon phases from a real ephemeris, enabling AI agents to provide accurate astrological calculations without hallucination.12721MIT
- AlicenseNot gradedqualityBmaintenanceProvides real-time astrological transit calculations and synthetic evolutionary doctrine readings via the Model Context Protocol for on-device LLMs.MIT
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A4/5.0
Disambiguation3/5
The solar return tool is clearly distinct from the others, but the remaining forecast tools overlap: timeline and transits both produce time-ordered, significance-scored event feeds, while digest and significant_dates both emphasize the most important upcoming events. The descriptions provide enough detail to separate them, but selection is not always obvious.
Naming Consistency5/5
All tools follow the same post_forecast_<object> pattern with snake_case nouns. The naming is consistent and predictable across the entire server.
Tool Count4/5
Five tools is a reasonable size for an astrology forecast server, and each covers a distinct enough use case. Slightly redundant, however: post_forecast_transits appears to be a narrower western-only subset of post_forecast_timeline.
Completeness4/5
The tool surface covers the core forecasting workflow well: broad timelines, Western-only transits, high-significance dates, digest summaries, and solar returns. Missing is a more flexible custom-range event window beyond 90 days, but the coverage is not severely incomplete.