stellara-mcp

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

Annotations already provide readOnly, idempotent, and openWorld hints, and the description adds substantial non-obvious behavior: it uses Swiss Ephemeris rather than AI or guessing, returns an exact tropical chart, and enumerates the full result shape including aspects, orbs, applying/separating flags, house cusps and angles. Nothing in the description contradicts 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the usage condition and prerequisite before the output details. It is dense and somewhat run-on in the first sentence, but every clause carries information about behavior or return shape, so it earns a high score rather than a maximum.

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

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

This is a complex calculation tool with no output schema, and the description compensates fully by specifying the 14 points, house cusps, angles, aspect types, orbs, applying/separating status and zodiac. Combined with the fully described input schema, an agent has everything needed to invoke and interpret the call.

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

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

Schema coverage is 100% and every parameter already has a thorough description, so the baseline is 3. The description adds useful context by explaining that the birth place and local time must be resolved through resolve_birth_place before supplying latitude, longitude and birth_datetime, and by tying the result fields to the input birth moment and place.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the exact resource (natal chart / birth chart / personal horoscope) and a specific action (compute with Swiss Ephemeris). It also distinguishes itself by explicitly forbidding self-computation or web-search and pointing to resolve_birth_place for place-name-only inputs, so an agent can tell it apart from siblings.

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

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

It states when to use the tool: for ANY natal chart or personal horoscope request. It gives an explicit when-not by saying never compute or recall positions yourself and never web-search them, and it names the alternative resolve_birth_place as a prerequisite when only a place name and local time are available.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds meaningful behavior beyond that: it reports every inter-chart aspect at exact orbs, includes house overlays, and embeds both full natal charts in the response. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with the primary trigger and prohibition front-loaded, followed by a compact but complete specification of the output. No filler or repetition of schema content.

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

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

With no output schema, the description carries the burden of explaining return value, and it does: every inter-chart aspect with orbs, house overlays both directions, and embedded natal charts. The input schema covers all parameters, so an agent has everything needed to select and call the tool correctly.

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

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

Schema description coverage is 100%, with detailed descriptions for birth_datetime, coordinates, house_system, and include_minor_aspects. The prose adds no parameter-specific semantics, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the exact resource ('compatibility / relationship / synastry question about two people') and enumerates the computed output: every inter-chart aspect with exact orbs plus house overlays. This differentiates it from single-chart tools like calculate_natal_chart or time-based get_transits_and_aspects.

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

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

It explicitly says to use the tool for ANY two-person compatibility/synastry question and forbids estimating aspects or web-searching them. It does not name sibling tools or state when not to use this tool (e.g., single chart → calculate_natal_chart), so it stops short of full alternative guidance.

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

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

Beyond the readOnly/openWorld/idempotent annotations, the description discloses detailed behavior: it computes transiting planet positions at target_datetime, all aspects to natal points including angles, exact orbs, applying/separating states, natal house placement per transiting planet, and embeds the full natal chart. This gives the agent a clear model of what the tool does internally without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the usage directive and followed by a compact feature list. Every clause earns its place—no filler, no repetition of schema details, and the most important guidance comes first.

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

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

For a fairly complex astrological computation with no output schema, the description covers what is computed, which points are included, and what extra data is embedded (houses, full chart). It does not describe the exact response structure or pagination/format details, but for the agent's invocation decision the description is reasonably complete.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds meaning beyond field names by explaining how target_datetime is used ('transiting planet positions at target_datetime') and how natal relates to it ('every aspect ... to the natal points ... with the natal point fixed'). This helps an agent understand which parameter drives which behavior, though the schema already documents the basics well.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource ('compute transits to a natal chart') and immediately ties it to concrete user intents: 'what is going on for me now / today / this week / this month', horoscopes, forecasts, and transit questions. This clearly distinguishes it from siblings like calculate_natal_chart (static chart) and calculate_synastry (relationship chart).

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

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

It explicitly says 'Use this tool for ANY ... forecast or transit question' and instructs the agent to 'never estimate transiting positions yourself and never web-search them', giving strong when-to-use guidance. It does not explicitly name alternative sibling tools or state when NOT to use them, stopping just short of a 5.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the safety profile is covered. The description adds valuable behavioral context: it explains DST ambiguity handling, the 'time_assumed_noon' flag, the 'local_time_ambiguity' field, and that nothing is stored server-side. It doesn't fully explain what happens in ambiguous/nonexistent cases beyond 'ask the user', but the disclosure is strong.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but well-organized, front-loading the most important usage instruction ('Call this FIRST'). It packs a lot of information into a few sentences, though the list of return fields is long and could be slightly more scannable. Every sentence earns its place.

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

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

For a tool with 2 parameters, 100% schema coverage, and no output schema, the description is remarkably complete. It explains the return fields, the ambiguity flags, the noon assumption, the historical timezone handling, and the privacy behavior. An agent has everything it needs to call this tool correctly and interpret its output.

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

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 both parameters well. The description adds meaning by explaining that local_datetime must be in LOCAL time without an offset, and that 'YYYY-MM-DD' alone triggers noon assumption. It also clarifies that the place can be in any language. This goes beyond the schema's basic descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('resolve') and resource ('birth place'), and clearly distinguishes this tool from siblings by naming the downstream tools it feeds. It also explicitly says to call it FIRST whenever birth data appears, which differentiates it from calculate_natal_chart, get_transits_and_aspects, and calculate_synastry.

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

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

The description gives explicit when-to-use guidance ('Call this FIRST whenever a birth date / time and a place of birth appear in the conversation'), and explicit when-not-to-use guidance ('Never compute coordinates, timezones or UTC offsets yourself and never web-search them'). It also names the downstream tools that consume its output, making the workflow clear.

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