Skip to main content
Glama
Sign In
Open Ephemeris

Open Ephemeris

by openephemeris
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Sign Ingresses

ephemeris_ingresses
Read-onlyIdempotent

Determine when planets change zodiac signs or reach an exact degree: returns each ingress with UTC time, signs entered and left, and retrograde status.

Instructions

Use this when the user asks 'when does Saturn enter Aries', 'when does Mercury change signs', 'when is the Moon in Scorpio next', or when a planet reaches an exact degree. Returns each sign ingress (exact UTC time, signs left and entered, retrograde flag) or, with degree, each crossing of that longitude.

CREDIT COST: 5 credits; 1 when the only planet is the Moon (90 days at most).

Input Schema

NameRequiredDescriptionDefault
signNoOnly ingresses into this sign.
degreeNoLongitude 0-360 (0 Cancer = 90). One planet only.
planetsNoe.g. ['saturn']. Default Sun to Pluto; the Moon only on its own.
end_dateNoDefault a year on (Moon: 30 days); not with `degree`. ISO 8601 date (whole UTC day) or zoned datetime.
start_dateNoDefault now. ISO 8601 date (whole UTC day) or zoned datetime.
max_crossingsNoWith `degree`, default 3.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv4.29.0
    • changedInput schema / properties / end_date / description
      Previous value: -"Default a year on (Moon: 30 days); not with `degree`. ISO 8601 date (YYYY-MM-DD) or zoned datetime; a naive clock time is rejected. A bare date covers the whole UTC day: start at 00:00, end at 23:59:59."New value: +"Default a year on (Moon: 30 days); not with `degree`. ISO 8601 date (whole UTC day) or zoned datetime."
    • changedInput schema / properties / start_date / description
      Previous value: -"Default now. ISO 8601 date (YYYY-MM-DD) or zoned datetime; a naive clock time is rejected. A bare date covers the whole UTC day: start at 00:00, end at 23:59:59."New value: +"Default now. ISO 8601 date (whole UTC day) or zoned datetime."
  2. Addedv4.27.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the description's job is cost and behavior — and it delivers: 5 credits, 1 credit for Moon-only, 90-day cap for Moon, and the shape of returned entries. It stops short of 5 because it doesn't state result caps or pagination limits for non-degree mode.

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?

The trigger examples and return shape are front-loaded, with cost placed last where it belongs. The four quoted example questions are slightly padded but each maps to a distinct input path, so little is truly wasted.

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 six optional parameters and no output schema, the description does the heavy lifting by describing the returned fields and the two operating modes. It leaves minor gaps, e.g. result caps and how `max_crossings` interacts with output size, but an agent can call it correctly from what is given.

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 coverage is 100%, so all six parameters are already documented, including `degree` as 'one planet only' and the retrograde/default behaviors. The description's 'with `degree`, each crossing of that longitude' largely restates the schema, so it sits at the high-coverage baseline rather than adding materially new semantics.

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?

States a specific verb+resource (compute sign ingresses) and enumerates the return payload (exact UTC time, signs left and entered, retrograde flag), plus a distinct mode via `degree`. This clearly separates it from siblings like ephemeris_transits or ephemeris_planet_position, which do not answer 'when does X enter Y'.

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

Usage Guidelines4/5

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

Opens with concrete user-question triggers ('when does Saturn enter Aries', 'when is the Moon in Scorpio next') and implicitly covers the degree-crossing case. It lacks an explicit 'use X instead when…' exclusion against siblings such as ephemeris_transits or explore_transit_timeline, so it stops short of full routing guidance.

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