Skip to main content
Glama
Sign In
Open Ephemeris

Open Ephemeris

by openephemeris
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Time Lords

ephemeris_time_lords
Read-onlyIdempotent

Compute time-lord periods over a date window as structured data, including releasing levels, profection year and optional firdaria for astrological timing analysis.

Instructions

Use this when the user asks for 'time-lord periods as data', 'releasing dates between two dates' or 'profection lords to compare with transits'. Returns time-lord periods over a date window as data: releasing levels 1–2 with peak and loosing flags, the profection year with house and lord, optional firdaria, and change dates.

CREDIT COST: 5 credits (natal + one Lot + profections); +2 per extra Lot or firdaria.

Input Schema

NameRequiredDescriptionDefault
lotNoLot to release from. Default spirit.
to_dateNoWindow end. Default one year after from_date; at most 25 years.
timezoneNoIANA zone for a local datetime.
from_dateNoWindow start, ISO 8601 with offset or Z. Default now. `current` is always the period in effect now (or at the nearest window edge if now is outside the window).
techniquesNoDefault zodiacal_releasing and profections.
birth_datetimeYesISO 8601; zone required (`Z`/offset, or local time plus `timezone`).
birth_latitudeYesBirth latitude.
birth_longitudeYesBirth longitude.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv4.31.0
    • changedInput schema / properties / from_date / description
      Previous value: -"Window start, ISO 8601 with offset or Z. Default now."New value: +"Window start, ISO 8601 with offset or Z. Default now. `current` is always the period in effect now (or at the nearest window edge if now is outside the window)."
  2. Changed4 schema fields changedv4.29.0
    • changedInput schema / properties / birth_datetime / description
      Previous value: -"ISO 8601 datetime. A datetime with no zone is rejected; give a `Z` or ±HH:MM suffix, or a local time with the `timezone` argument. Date-only resolves to 12:00 UTC."New value: +"ISO 8601; zone required (`Z`/offset, or local time plus `timezone`)."
    • changedInput schema / properties / birth_latitude / description
      Previous value: -"Birth latitude in decimal degrees."New value: +"Birth latitude."
    • changedInput schema / properties / birth_longitude / description
      Previous value: -"Birth longitude in decimal degrees."New value: +"Birth longitude."
    • changedInput schema / properties / timezone / description
      Previous value: -"IANA timezone (e.g. `America/Chicago`); required when the datetime is naive, ignored otherwise."New value: +"IANA zone for a local datetime."
  3. Addedv4.24.2

TDQS

A4.1/5.0
Behavior4/5

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

The annotations already establish that this is a read-only, idempotent, non-destructive, closed-world operation. The description adds useful behavioral context beyond annotations by disclosing the credit cost, the optional firdaria inclusion, and the returned time-lord components.

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

Conciseness5/5

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

The description is front-loaded with the usage condition and return summary, followed by a separate credit cost note. Every sentence carries useful information, and there is no redundant restatement of the title or schema.

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?

For an eight-parameter tool with no output schema, the description does a good job naming the returned data and cost implications. It is still somewhat high-level about the exact shape of the returned periods, but the input schema covers parameter details thoroughly.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by tying the `lot` and `techniques` parameters to credit cost: the base covers natal plus one Lot plus profections, with +2 credits per extra Lot or firdaria.

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 and resource: it returns time-lord periods over a date window as data, including releasing levels, profection year, optional firdaria, and change dates. It implicitly contrasts with the exploratory sibling via the phrase 'time-lord periods as data,' but it does not explicitly name explore_time_lords as the alternative.

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?

It gives clear trigger phrases: user asks for 'time-lord periods as data,' 'releasing dates between two dates,' or 'profection lords to compare with transits.' It does not state when not to use this tool or explicitly name an alternative sibling, so it is clear context without exclusions.

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