Skip to main content
Glama
IPGeolocation

IP Geolocation MCP Server

Astronomy Data

get_astronomy
Read-only

Retrieve sunrise, sunset, moonrise, moonset, and sun/moon position for any location or IP address on a specific date.

Instructions

Read-only single-date astronomy lookup via GET /v3/astronomy. Works on free and paid plans. Cost: 1 credit. Use for one date or real-time sun/moon position; use get_astronomy_time_series for daily sunrise, moon, and twilight data across a date range.

Returns { location, astronomy } plus ip for IP/caller lookups. astronomy includes date/current_time, sunrise/sunset, moonrise/moonset, twilight blocks, day_length, sun/moon position, distance, status, moon_phase, moon_illumination_percentage, and moon_angle.

Selector priority is lat/long, location, ip, then caller IP when no selector is provided. lat and long must be provided together; date must be YYYY-MM-DD; elevation must be 0-10000 meters. time_zone changes timestamp formatting to include full dates. lang only changes location fields; non-English lang is paid-only and returns 401 on free plans.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ipNoIPv4 or IPv6 address to get astronomy data for that IP's location.
latNoLatitude coordinate. Highest priority. Must be used with long.
dateNoDate in YYYY-MM-DD format. Defaults to today.
langNoResponse language for location fields in IP-based lookups (en, de, ru, ja, fr, cn, es, cs, it, ko, fa, pt). Paid plans only. Free plan returns 401 for non-English language values.
longNoLongitude coordinate. Must be used with lat.
locationNoCity or address string (e.g. San Francisco, CA).
elevationNoElevation in meters above sea level (0-10000). Affects sunrise/sunset calculations for higher accuracy.
time_zoneNoIANA timezone name to express times in (e.g. America/New_York). If set, time fields include full date instead of just time.
Behavior5/5

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

Annotations declare readOnlyHint=true, and the description adds behavioral context: GET request, credit cost, selector priority (lat/long > location > ip > caller IP), error conditions (401 on free plan for non-English lang), and specific return fields.

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?

Well-structured with clear paragraphs: purpose, comparison, return fields, selector priority, parameter constraints. Slightly verbose but every sentence adds value.

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

Completeness5/5

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

Completely covers return format, selector priorities, parameter constraints, plan differences, and error conditions. No output schema, but return description is thorough.

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%, but the description adds interdependencies (lat/long together, elevation range 0-10000, date format YYYY-MM-DD, time_zone effect, lang paid-only). Adds value beyond schema.

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?

Description clearly states it's a 'read-only single-date astronomy lookup' via GET /v3/astronomy. It distinguishes itself from sibling get_astronomy_time_series, which is for daily data across a date range.

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

Usage Guidelines5/5

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

Explicitly says 'Use for one date or real-time sun/moon position; use get_astronomy_time_series for daily sunrise, moon, and twilight data across a date range.' Also mentions plan limitations (free vs paid, credit cost, 401 on non-English lang).

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/IPGeolocation/ipgeolocation-io-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server