Skip to main content
Glama
openephemeris

Open Ephemeris

by openephemeris
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Eclipse Finder

ephemeris_next_eclipse
Read-onlyIdempotent

Find the next solar or lunar eclipse after any date and get its type, maximum time, magnitude, and totality duration. Add coordinates to see local contact times and visibility.

Instructions

Use this when the user asks 'when is the next eclipse', 'when is the next solar / lunar eclipse' or 'is there an eclipse visible from Tokyo'. Returns the eclipse type, time of maximum, magnitude and totality duration; with latitude+longitude, local contact times and visibility.

CREDIT COST: 1 credit per call.

Input Schema

NameRequiredDescriptionDefault
latitudeNoOptional observer latitude; with longitude adds local times and visibility.
longitudeNoOptional; pair with latitude.
after_dateNoISO 8601 date; default today.
eclipse_typeYes'any' = next of either.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv4.29.0
    • changedInput schema / properties / after_date / description
      Previous value: -"ISO 8601 date to search after (e.g. '2026-01-01'). Defaults to today if omitted."New value: +"ISO 8601 date; default today."
    • changedInput schema / properties / eclipse_type / description
      Previous value: -"Eclipse type to search for. Use 'any' for whichever comes first (solar or lunar)."New value: +"'any' = next of either."
    • changedInput schema / properties / latitude / description
      Previous value: -"Observer latitude in decimal degrees (optional). When provided with longitude, returns local contact times and visibility."New value: +"Optional observer latitude; with longitude adds local times and visibility."
    • changedInput schema / properties / longitude / description
      Previous value: -"Observer longitude in decimal degrees (optional, pair with latitude)."New value: +"Optional; pair with latitude."
  2. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful behavioral context by listing returned fields, explaining that latitude/longitude add local contact times and visibility, and disclosing the 1-credit cost.

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 definition is front-loaded with usage guidance and keeps the return and cost details brief. Every sentence contributes useful selection or invocation information.

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 no output schema, the description appropriately mentions the key returned values, and the annotations cover safety semantics. It is nearly complete, though it could explicitly mention sibling alternatives or prerequisites for location-based visibility queries.

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 all four parameters are already documented in the schema. The description reinforces the latitude/longitude effect but adds little beyond the schema for eclipse_type or after_date.

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 clearly conveys that this tool answers next-eclipse questions and returns eclipse details such as type, maximum time, magnitude, and totality duration. It is distinguishable in practice from sibling ephemeris tools by focusing specifically on eclipses, though it does not explicitly name alternatives.

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 concrete user-question examples for when to use the tool, including solar, lunar, and location-specific visibility queries. It does not explicitly state when not to use it or which sibling tool to choose instead.

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