en es ja ko zh

Celestial Position MCP Server

Name: Celestial Position MCP Server
Author: Rkm1999

by Rkm1999

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

CelestialMCP

Un servidor de Protocolo de Contexto de Modelo (MCP) para Claude AI que proporciona herramientas para calcular posiciones de objetos celestes, horas de salida y puesta y otros datos astronómicos.

Descripción general

CelestialMCP se basa en el marco mcp y utiliza la biblioteca astronomy-engine para proporcionar cálculos astronómicos precisos. Ofrece diversas herramientas para determinar la posición de los objetos celestes, calcular sus horas de salida y puesta, y listar los objetos disponibles en los catálogos de estrellas y objetos de cielo profundo.

Características

Cálculos de posición celeste : obtenga coordenadas de altitud y acimut de cualquier objeto celeste desde una ubicación específica en la Tierra
Cálculos de hora de salida y puesta : descubre cuándo salen, transitan y se ponen los objetos celestes desde una ubicación específica
Información detallada de objetos : obtenga información completa sobre los objetos celestes, incluidos:
- Distancia (para objetos del sistema solar)
- Información de fase (para la Luna y los planetas)
- Próximas fases lunares (para la Luna)
Amplio catálogo de objetos : Incluye:
- Objetos del sistema solar (Sol, Luna, planetas)
- Más de 5500 estrellas de la base de datos HYG
- Más de 14.000 objetos de cielo profundo del catálogo NGC

Herramientas

El paquete contiene tres herramientas principales:

getCelestialPosition : Calcula las coordenadas de altitud/azimut de un objeto celeste
getCelestialDetails : proporciona información detallada sobre un objeto celeste
listCelestialObjects : Devuelve una lista de objetos celestes disponibles por categoría

Related MCP server: chuk-mcp-celestial

Inicio rápido

# Install dependencies
npm install

# Build the project
npm run build

# Start the server
npm start

Uso con Claude Desktop

Desarrollo local

Agregue esta configuración a su archivo de configuración de Claude Desktop:

Windows : %APPDATA%/Claude/claude_desktop_config.json MacOS : ~/Library/Application Support/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "CelestialMCP": {
      "command": "node",
      "args":["/absolute/path/to/CelestialMCP/dist/index.js"]
    }
  }
}

Datos del catálogo

Este proyecto incluye un script para obtener datos del catálogo astronómico:

# Fetch star and deep sky object catalogs
npm run fetch-catalogs

Esto descargará la base de datos de estrellas HYG y el catálogo de objetos de cielo profundo NGC al directorio data/ .

Uso de herramientas

A continuación se muestran algunos ejemplos del uso de las herramientas con Claude:

Obtener la posición del objeto

Pregúntale a Claude: "¿Cuál es la posición actual de Júpiter en el cielo desde Vancouver?"

Obtener detalles del objeto

Pregúntale a Claude: "¿Cuándo sale y se pone la Luna hoy en Vancouver?"

Listado de objetos disponibles

Pregúntale a Claude: "Muéstrame una lista de estrellas que pueda buscar".

Estructura del proyecto

CelestialMCP/
├── src/
│   ├── tools/            # MCP Tools
│   │   ├── CelestialPositionTool.ts
│   │   ├── CelestialDetailsTool.ts
│   │   └── ListCelestialObjectsTool.ts
│   ├── utils/
│   │   └── astronomy.ts  # Core astronomy calculations
│   ├── config.ts         # Observer configuration
│   └── index.ts          # Server entry point
├── scripts/
│   └── fetch-catalogs.js # Script to download star catalogs
├── data/                 # Catalog data files
│   ├── hygdata_v41.csv   # HYG star database
│   └── ngc.csv           # New General Catalogue
├── package.json
└── tsconfig.json

Configuración predeterminada

De forma predeterminada, la ubicación del observador es Vancouver, Canadá. Puede cambiarla en src/config.ts :

export const OBSERVER_CONFIG = {
  latitude: 49.2827,    // Observer latitude
  longitude: -123.1207, // Observer longitude
  altitude: 30,         // Observer altitude in meters
  temperature: 15,      // Default temperature in Celsius
  pressure: 1013.25     // Default pressure in hPa
};

Licencia

Instituto Tecnológico de Massachusetts (MIT)

Expresiones de gratitud

motor astronómico para cálculos astronómicos básicos
mcp-framework para la implementación del servidor MCP
Base de datos HYG para datos estelares
OpenNGC para datos de objetos del cielo profundo

Available Tools

3 tools

getCelestialDetailsA

Retrieves detailed astronomical information for a specified celestial object (e.g., planet, star, Messier object, NGC/IC object). Information includes current equatorial and horizontal (altitude/azimuth) coordinates, visibility status (above/below horizon), rise/transit/set times, and, where applicable, distance, phase illumination, and upcoming moon phases. All calculations are performed for the pre-configured observer location and the current system time. The tool automatically resolves common names (e.g., 'Andromeda Galaxy' to 'M31') and handles various catalog identifiers.

ParametersJSON Schema

Name	Required	Description	Default
`objectName`	Yes	The name or catalog identifier of the celestial object. Examples: 'Jupiter', 'Sirius', 'M31', 'NGC 7000', 'Crab Nebula'. The tool will attempt to resolve common names.

TDQS

A4.1/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes key behaviors: automatic name resolution, pre-configured observer location and current time calculations, and the types of information returned. However, it doesn't mention potential limitations like accuracy constraints, failure modes for unresolvable names, or performance characteristics.

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 efficiently structured in two sentences: the first states the purpose and comprehensive information returned, the second explains behavioral aspects like automatic resolution and calculation settings. Every sentence adds essential information with zero wasted words.

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

Completeness3/5

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

For a tool with no annotations and no output schema, the description does a reasonable job covering the tool's purpose, behavior, and parameter context. However, it doesn't describe the format or structure of returned information, which would be important for an agent to process the results effectively.

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?

With 100% schema description coverage for the single parameter, the baseline is 3. The description adds value by explaining the tool's automatic name resolution capability ('resolves common names') and providing broader context about what types of celestial objects are supported, which complements the schema's examples.

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?

The description clearly states the verb ('Retrieves') and resource ('detailed astronomical information for a specified celestial object'), with specific examples of object types (planet, star, Messier object) and information returned (coordinates, visibility, times, distance, phases). It distinguishes from sibling tools by focusing on detailed information retrieval rather than pathfinding or listing.

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?

The description provides clear context for when to use this tool: to get detailed astronomical information for a specific celestial object. It mentions automatic name resolution and pre-configured observer/time settings, but doesn't explicitly state when NOT to use it or name alternatives among sibling tools (e.g., use listCelestialObjects for browsing).

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

getStarHoppingPathC

Calculates a star hopping path from a bright start star to a target celestial object. Each hop is within the specified Field of View (FOV).

ParametersJSON Schema

Name	Required	Description
`fovDegrees`	Yes	The Field of View (FOV) of the user's equipment in degrees.
`initialSearchRadiusDegrees`	Yes	The angular radius around the target object to search for a suitable bright starting star. Default: 20.0 degrees.
`maxHopMagnitude`	Yes	The maximum (dimmest) stellar magnitude for stars in the hopping path. Default: 8.0.
`startStarMagnitudeThreshold`	Yes	The maximum (dimmest) magnitude for a star to be a good, bright "starting star." Default: 3.5.
`targetObjectName`	Yes	The name or catalog identifier of the celestial object to find (e.g., "M13", "Andromeda Galaxy", "Mars").

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the calculation process and FOV constraint, but lacks details on what the output looks like (e.g., path format, error handling), computational requirements, rate limits, or any side effects. For a tool with 5 parameters and no output schema, this leaves significant gaps in understanding how the tool behaves.

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 efficiently structured in two sentences: the first states the core purpose, and the second adds a key constraint. Every word earns its place, with no redundancy or fluff. It's appropriately sized for the tool's complexity.

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

Completeness2/5

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

Given the tool's complexity (5 parameters, no annotations, no output schema), the description is incomplete. It explains what the tool does but not what it returns, how errors are handled, or practical considerations for use. Without annotations or output schema, users lack critical context about the tool's behavior and results.

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 the input schema fully documents all 5 parameters with clear descriptions and defaults. The description adds no additional parameter semantics beyond what's in the schema—it doesn't explain relationships between parameters (e.g., how FOV interacts with hop selection) or provide usage examples. Baseline 3 is appropriate when the schema does the heavy lifting.

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 states the tool's purpose: calculating a star hopping path from a bright start star to a target celestial object, with hops constrained by Field of View. It specifies the verb ('calculates'), resource ('star hopping path'), and key constraint ('within the specified Field of View'). However, it doesn't explicitly differentiate from sibling tools like 'getCelestialDetails' or 'listCelestialObjects', which likely provide different astronomical data rather than navigation paths.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or other contexts where star hopping might be preferred over direct object lookup. Usage is implied (e.g., for astronomical navigation when equipment FOV is limited), but no explicit when/when-not scenarios or prerequisites are stated.

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

listCelestialObjectsB

Lists available celestial objects that can be queried by other tools. Objects are grouped by category. You can request all objects, or filter by a specific category. This tool helps in discovering what objects are known to the system.

ParametersJSON Schema

Name	Required	Description	Default
`category`	No	Optional. Filters the list by category. Valid categories are: 'planets' (for Solar System objects like Sun, Moon, and planets), 'stars', 'messier' (for Messier objects), 'ic' (for Index Catalogue objects), 'ngc' (for New General Catalogue objects), 'dso' (for all Deep Sky Objects, including Messier, IC, NGC, and others), or 'all' (to list objects from all available categories). If omitted, defaults to 'all'.

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that objects are 'grouped by category' and can be filtered, but doesn't describe output format, pagination, rate limits, or error handling. For a tool with no annotations, this leaves significant gaps in understanding how the tool behaves beyond basic functionality.

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 description is concise with three sentences that efficiently convey purpose, functionality, and utility. It's front-loaded with the core action ('Lists available celestial objects') and avoids redundancy. However, the last sentence ('This tool helps in discovering...') could be considered slightly verbose, as it restates the purpose rather than adding new information.

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

Completeness3/5

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

Given the tool's low complexity (1 optional parameter, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and filtering, but lacks details on output structure, error cases, or integration with siblings. Without annotations or output schema, more behavioral context would improve completeness for agent use.

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?

The input schema has 100% description coverage, fully documenting the single optional parameter 'category' with valid values and default behavior. The description adds minimal value beyond the schema, only implying filtering capability without providing additional syntax or format details. This meets the baseline score when schema coverage is high.

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 states the tool's purpose: 'Lists available celestial objects that can be queried by other tools' and 'Objects are grouped by category.' It specifies the verb (lists) and resource (celestial objects) with additional context about grouping. However, it doesn't explicitly differentiate from sibling tools like getCelestialDetails or getStarHoppingPath, which prevents a perfect score.

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

Usage Guidelines3/5

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

The description implies usage by stating 'This tool helps in discovering what objects are known to the system' and mentions filtering by category, suggesting it's for discovery purposes. However, it lacks explicit guidance on when to use this tool versus alternatives like getCelestialDetails (which likely provides detailed info) or getStarHoppingPath (which might involve navigation). No exclusions or clear alternatives are named.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

3 tool updatesv1.0.0Aug 18, 2025
- First observedgetCelestialDetails
- First observedgetStarHoppingPath
- First observedlistCelestialObjects

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.5/5.0

Scored 2026-04-18 10:25 across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: getCelestialDetails retrieves detailed information for a specific object, getStarHoppingPath calculates navigation paths between objects, and listCelestialObjects provides a catalog for discovery. The descriptions clearly differentiate their functions, eliminating any ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in camelCase: getCelestialDetails, getStarHoppingPath, and listCelestialObjects. This uniformity makes the tools predictable and easy to understand, with no deviations in naming style.

Tool Count3/5

With only 3 tools, the server feels slightly thin for the celestial position domain, as it lacks operations like update or delete for observer settings or object data. However, the core functions (retrieve details, navigate, list objects) are covered, making it borderline but functional.

Completeness4/5

The tool set covers key aspects of celestial navigation: listing objects, getting details, and calculating paths. Minor gaps exist, such as no tools for configuring observer location or time, but agents can work around this by relying on pre-configured settings, and the core workflows are well-supported.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

CycleCalcs Astronomy A
com.cyclecalcs
Read-only astronomy calculations: sun, moon, planets, eclipses, twilight and star positions.
Aerospace & Astrodynamics Education & Learning Tools
111
thirdtrail A
io.github.thirdtrail
Elevation-corrected sun, moon, twilight, solar and tide data for any point on Earth
Weather Services Open Data
81
astronomy-mcp-server A
io.github.cyanheads
Offline observational astronomy: positions, rise/set, moon phases, eclipses, and seasons.
Aerospace & Astrodynamics Research & Data
713
stellara-mcp A
it.natlex
Swiss Ephemeris for AI agents: exact natal charts, transits, synastry and birth-place resolution
Entertainment & Media Health & Wellness Research & Data
41

Related MCP Servers

mcp-stargazing
Weather Services Location Services
StarGazer1995
A
license
A
quality
A
maintenance
Calculate the altitude, rise, and set times of celestial objects (Sun, Moon, planets, stars, and deep-space objects) for any location on Earth.
Updated a month ago (2026-09-07 12:58 UTC)
15
MIT
chuk-mcp-celestial
Location Services Weather Services
IBM
A
license
A
quality
F
maintenance
Provides authoritative astronomical data including moon phases, solar eclipses, and sun/moon rise and set times using the US Navy API or offline Skyfield calculations. It enables users to query Earth's seasons and celestial events for any location and date.
Updated 25 days ago (2026-09-21 22:15 UTC)
8
1
Apache 2.0
astronomy-oracle
Search Research & Data
gregario
A
license
A
quality
C
maintenance
Accurate astronomical catalog data and observing session planner for LLM assistants. Stops hallucinated magnitudes, coordinates, and visibility.
Updated 15 days ago (2026-10-01 14:21 UTC)
3
76 npm
3
MIT
Swiss Ephemeris MCP Server
Research & Data Education & Learning Tools
ducrouxolivier
F
license
A
quality
D
maintenance
Provides astronomical calculations using the Swiss Ephemeris library, including planetary positions, houses, chart points, and asteroids for any date and location.
Updated a year ago (2025-07-10 10:46 UTC)
4
10
-