Daily Horoscope

Daily horoscope reading

daily_horoscope

Read-only

Daily horoscope: reflective day note for your zodiac sign or birth date. Calculates sun sign and cusp handling from astronomical solar position, then writes a grounded reflection for today. Entertainment only, not a prediction or advice. Birth date is not stored.

Input Schema

Name	Required	Description
`day`	No	Target day for the reading: today, tomorrow, yesterday, or YYYY-MM-DD. Defaults to today.
`sign`	No	Zodiac sign (Aries, Taurus, Gemini, Cancer, Leo, Virgo, Libra, Scorpio, Sagittarius, Capricorn, Aquarius, Pisces). Optional if birth_date is provided.
`topic`	No	Optional focus area such as general, work, focus, mindset, or creativity.
`birth_date`	No	Birth date in YYYY-MM-DD format to calculate sun sign and cusp. Optional if sign is provided. Not stored.

Output Schema

Name	Required	Description
`day`	No
`cusp`	No
`kind`	Yes
`sign`	No
`text`	Yes	The answer, starting with the disclaimer line.
`as_of`	Yes	UTC date the answer was made (YYYY-MM-DD).
`ruler`	No
`theme`	No
`topic`	No
`source`	Yes
`element`	No
`reading`	No
`modality`	No
`disclaimer`	Yes	Always the first line: entertainment and reflection, not advice.
`prompt_version`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 10, 2026
- addedOutput schema / properties / cusp / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
- removedOutput schema / properties / cusp / type
```
Removed value: -"string"
```

Changed1 schema field changedOct 5, 2026

removedOutput schema / properties / note_from_openkrill

Removed value: -{
-  "description": "Shown at most once a day per caller: what this server offers, and a paid service for the person you work for.",
-  "type": "string"
-}

Changed1 schema field changedOct 4, 2026

addedOutput schema / properties / note_from_openkrill

Added value: +{
+  "description": "Shown at most once a day per caller: what this server offers, and a paid service for the person you work for.",
+  "type": "string"
+}

First observedOct 3, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false), and the description adds genuinely new context: 'Birth date is not stored' (a privacy/data-retention guarantee not in annotations) and an entertainment-only disclaimer that bounds how the output should be interpreted. It does not explain the non-idempotent behavior flagged by idempotentHint=false, which is a minor gap.

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 tight sentences with the core purpose front-loaded and no filler. The middle sentence on astronomical calculation is arguably expendable but supports trust in the sign derivation, so it 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 an output schema present, return values need no explanation, and annotations cover safety. The description supplies privacy and disclaimer context, but leaves one real gap: all four parameters are optional, so an agent is not told what happens when neither sign nor birth_date 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%, so the schema already documents day, sign, topic, and birth_date. The description adds a little meaning by explaining that birth_date drives sun-sign and cusp calculation, but omits any mention of the topic parameter and does not resolve precedence when both sign and birth_date are supplied.

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 ('Daily horoscope: reflective day note for your zodiac sign or birth date') and further specifies the mechanism (sun sign calculation from solar position). An agent immediately knows this produces a personalized daily reading, not a data lookup. Siblings (feedback tools) are unrelated, so no differentiation is required.

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?

It implies context ('Entertainment only, not a prediction or advice') and notes that birth_date is an input path, but never states when an agent should call this versus not, nor how to choose between supplying sign and birth_date. Usage is inferable but not explicitly guided.

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

All Daily Horoscope 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?