Skip to main content
Glama
astroway

astroway-mcp

Official
by astroway

Yearly Horoscope

astroway_horoscope_yearly
Read-onlyIdempotent

Generate a 12-month horoscope for a zodiac sign, including major transit cycles, solar return context, and yearly profection time-lord insight.

Instructions

Generate a year-ahead horoscope (12-month window) with major transit cycles, solar return chart context, and time-lord (profection) for the year.

[Group: Horoscope] [Endpoint: POST /v1/horoscope/yearly] [Required: sign] [Cost: 100 credits (Tier 4)]

Input Schema

NameRequiredDescriptionDefault
dateNo
signYes
styleNo`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.
lengthNoWith `style: "plain"`: `short` (about 70-110 words a day) or `medium` (default, about 150-230).
topicsNoOnly these sections, in this order, in `sections` and in `horoscope`. Default all six.
languageNo
disclaimer_inlineNo

Output Schema

NameRequiredDescriptionDefault
bodyNo
yearNo
titleNo
languageNo
solarReturnNo
profectionLordNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.6.0

TDQS

B3.4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive and non-open-world, so safety is covered. The description adds genuinely non-structured context: the endpoint, that only 'sign' is required, and that a call costs 100 credits at Tier 4 — cost awareness is important for a paid generative call.

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 followed by compact metadata lines; the call's scope and outputs come first and nothing is redundant. Slight cost: the tag-block format is terse rather than explanatory, but it is efficient.

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

Completeness3/5

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

An output schema exists, so return values need not be described, and cost/endpoint/required-param are supplied. However, for a 7-parameter generative tool with a 12-month window, the description leaves the meaning of 'date', default behaviors, and the effect of 'topics'/'length' on output entirely to the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 43% across 7 parameters, so the description should compensate but does not. It mentions only the required 'sign'; the ambiguous 'date' parameter (start of the year window? natal date?) is never explained, and 'language' and 'disclaimer_inline' get no mention at all.

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 ('Generate') and resource ('year-ahead horoscope, 12-month window') and enumerates the content produced (transit cycles, solar return context, profection time-lord). The 12-month scope implicitly separates it from the daily/weekly/monthly horoscope siblings, though no sibling is named outright.

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?

Usage is implied by the time window rather than stated: an agent can infer this is the yearly option versus astroway_horoscope_daily/weekly/monthly. There is no explicit when-to-use, when-not-to-use, or prerequisite statement.

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

Deploy Server

Other Tools