Stellara

Stellara Sun Sign Reading

get_sun_sign_reading

Read-onlyIdempotent

Returns a short, free reading based only on a birth date: sun sign (simple date table) and Pythagorean life path number, with a few sentences about character, written in the third person by default. No predictions, no personal data stored.

Input Schema

Name	Required	Description
`voice`	No	Optional voice of the reading: 'third_person' (default, about someone born under the sign) or 'second_person' (addresses the reader as 'you').
`language`	No	Language of the text: 'en' (default) or 'nl'.
`birth_date`	Yes	Birth date in YYYY-MM-DD format, for example 1988-03-14. Birth time and place are not needed.

Output Schema

Name	Required	Description	Default
`reading`	Yes
`sun_sign`	Yes
`disclaimer`	Yes
`sun_sign_key`	Yes
`sign_change_day`	Yes
`life_path_number`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 18, 2026

addedInput schema / properties / voice

Added value: +{
+  "description": "Optional voice of the reading: 'third_person' (default, about someone born under the sign) or 'second_person' (addresses the reader as 'you').",
+  "enum": [
+    "third_person",
+    "second_person"
+  ],
+  "type": "string"
+}

First observedOct 16, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so safety and determinism are covered. The description adds genuinely new behavioral context: the reading is free, contains no predictions, stores no personal data, is short, and defaults to third-person voice — useful traits beyond the structured fields.

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 that leads with what is returned, then qualifies scope and output nature. It is dense but every clause carries information; a small amount of structural separation could improve scannability.

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

Completeness5/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 no explanation. With annotations covering safety and idempotency, schema covering all three parameters, and the description covering scope, tone, language defaults, and the no-data-stored guarantee, an agent has everything needed to call this correctly.

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 enum semantics for voice and language and the YYYY-MM-DD format for birth_date are already fully documented in the schema. The description only echoes the third-person default and the birth-date-only input, adding little beyond structured data, making the baseline 3 appropriate.

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 names a specific verb (returns) and precisely characterizes the resource: a short free reading derived from birth date alone, comprising sun sign and a Pythagorean life path number. The 'based only on a birth date' scope implicitly separates it from sibling get_birth_chart, which needs time and place, 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 rather than stated: 'based only on a birth date' and 'No predictions' hint at when this lightweight reading is appropriate versus a full chart tool. There is no explicit when-to-use, when-not-to-use, or named alternative such as get_birth_chart or compare_charts.

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

All Stellara 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.