Skip to main content
Glama
openephemeris

Open Ephemeris

by openephemeris
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Angles & Points

ephemeris_angles_points
Read-onlyIdempotent

Calculate chart angles—ASC, MC, DSC, IC, Vertex and Equatorial Ascendant—for a given datetime and location to answer questions about where your Vertex or East Point falls.

Instructions

Use this when the user asks 'where is my Vertex', 'what's my East Point / equatorial ascendant' or 'what are my chart angles' for a date, time and place. Returns ASC, MC, DSC, IC, Vertex and the Equatorial Ascendant/Descendant (also as east_point).

CREDIT COST: 1 credit per call.

Input Schema

NameRequiredDescriptionDefault
datetimeYesISO 8601; zone required (`Z`/offset, or local time plus `timezone`).
latitudeYesObserver latitude.
timezoneNoIANA zone for a local datetime.
longitudeYesObserver longitude.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv4.29.0
    • changedInput schema / properties / 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 / 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."
  2. Changed1 schema field changedv4.24.2
    • changedInput schema / properties / datetime / description
      Previous value: -"ISO 8601 datetime; zone required — a `Z`/±HH:MM suffix or the `timezone` argument. Date-only resolves to 12:00 UTC. Full rule: server `instructions`."New 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."
  3. Changed2 schema fields changedv4.8.0
    • changedInput schema / properties / datetime / description
      Previous value: -"ISO 8601 date/time."New value: +"ISO 8601 datetime; zone required — a `Z`/±HH:MM suffix or the `timezone` argument. Date-only resolves to 12:00 UTC. Full rule: server `instructions`."
    • addedInput schema / properties / timezone
      Added value: +{
+  "description": "IANA timezone (e.g. `America/Chicago`); required when the datetime is naive, ignored otherwise.",
+  "type": "string"
+}
  4. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

The annotations already declare this as a safe, read-only, idempotent, non-destructive calculation. The description adds useful context beyond annotations by listing exactly which points are returned and disclosing a per-call credit cost, though it doesn't mention output format or edge cases around timezone handling.

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 use case, followed by the returned fields and credit cost. Every sentence adds actionable information with no wasted text.

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?

There is no output schema, but the description lists the key returned angles, which compensates well. Inputs are fully documented in the schema, and credit cost is disclosed; only minor details such as output structure or timezone failure behavior are absent.

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%, and the schema already documents datetime ISO format, latitude, longitude, and timezone. The description does not add any further parameter semantics, so the baseline 3 is 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 states a specific verb/resource: computing chart angles (ASC, MC, DSC, IC, Vertex, East Point/Equatorial Ascendant) for a date/time/place. It is concrete and distinct from generic natal-chart siblings, though it does not explicitly name which sibling to use for alternative angle-related needs.

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 provides clear trigger examples such as 'where is my Vertex', 'what's my East Point', and 'what are my chart angles', which helps an agent recognize when to call it. It does not state exclusions or explicitly route competing requests to siblings like ephemeris_natal_chart or ephemeris_house_cusps.

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