AstroWay Core astrology

Monthly Horoscope

astroway_horoscope_monthly

Read-onlyIdempotent

Monthly horoscope for a zodiac sign: the same shape as the daily one, over 30 days from date, with the month's ingresses, stations and lunar phases.

[Group: Horoscope] [Endpoint: POST /v1/horoscope/monthly] [Required: sign] [Cost: 50 credits (Tier 3)]

Input Schema

Name	Required	Description
`date`	No
`sign`	Yes
`style`	No	`astro` (default) names the planets, houses and aspects behind each point. `plain` uses everyday words with no astrological terms, and is written once in English and translated, so every language says the same thing. Daily, weekly and monthly.
`fields`	No	Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response.
`length`	No	With `style: "plain"`: `short` (about 70-110 words a day) or `medium` (default, about 150-230).
`topics`	No	Only these sections, in this order, in `sections` and in `horoscope`. Default all six.
`language`	No
`precision`	No	Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn.
`disclaimer_inline`	No

Output Schema

Name	Required	Description	Default
`model`	No
`language`	No
`horoscope`	No
`disclaimer`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 21, 2026

addedInput schema / properties / length

Added value: +{
+  "description": "With `style: \"plain\"`: `short` (about 70-110 words a day) or `medium` (default, about 150-230).",
+  "enum": [
+    "short",
+    "medium"
+  ],
+  "type": "string"
+}

addedInput schema / properties / style

Added value: +{
+  "description": "`astro` (default) names the planets, houses and aspects behind each point. `plain` uses everyday words with no astrological terms, and is written once in English and translated, so every language says the same thing. Daily, weekly and monthly.",
+  "enum": [
+    "astro",
+    "plain"
+  ],
+  "type": "string"
+}

addedInput schema / properties / topics

Added value: +{
+  "description": "Only these sections, in this order, in `sections` and in `horoscope`. Default all six.",
+  "items": {
+    "enum": [
+      "overview",
+      "love",
+      "career",
+      "health",
+      "finance",
+      "advice"
+    ],
+    "type": "string"
+  },
+  "maxItems": 6,
+  "minItems": 1,
+  "type": "array"
+}

First observedOct 5, 2026

TDQS

A3.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely non-annotation context: the 50-credit Tier 3 cost, the required parameter, the endpoint, and the kind of event data the month includes. It stops short of describing the response structure, but 'same shape as the daily one' gestures at that.

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?

A single front-loaded sentence carrying the scope and content, followed by a compact bracketed metadata block for group, endpoint, required param, and cost. Little waste, though the metadata block is duplicated by structured fields.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need no explanation, and cost/endpoint/required param are covered. But for a 9-parameter tool with only 56% schema description coverage, the description gives no guidance on choosing between `style`, `length` and `topics`, and its 'same shape as the daily one' reference makes the definition non-self-contained.

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 56%, and the description explains the one thing the schema does not: `date` anchors a 30-day forward window. However, it says nothing about `sign`, `disclaimer_inline`, or how `style`, `length`, `topics` and `language` interact, so it only partially compensates for the undocumented parameters.

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?

States a specific resource and scope ('Monthly horoscope for a zodiac sign ... over 30 days from `date`') and enumerates the month's distinctive content (ingresses, stations, lunar phases). It implicitly contrasts with the daily horoscope, but never names the weekly/yearly siblings it must be chosen against, so an agent still has to infer the routing boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 30-day window from `date` implies when this tool is appropriate, but there is no explicit when-to-use or when-not-to-use guidance versus astroway_horoscope_weekly, astroway_horoscope_yearly, or astroway_reports_ai_monthly_narrative. Usage is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All AstroWay Core astrology tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?