Skip to main content
Glama
enesjakozh
Rkm1999

Celestial Position MCP Server

by Rkm1999
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

CelestialMCP

Claude AI 的模型上下文协议 (MCP) 服务器提供用于计算天体位置、升起/落下时间和其他天文数据的工具。

概述

CelestialMCP 基于 mcp-framework 构建，并利用 astronomy-engine 库提供精确的天文计算。它提供了多种工具，用于确定天体位置、计算其升起和落下时间，以及列出恒星和深空天体目录中可用的天体。

特征

  • 天体位置计算：从地球上的指定位置获取任何天体的高度和方位坐标

  • 升起/落下时间计算：查找天体从特定位置升起、过境和落下的时间

  • 详细物体信息：获取有关天体的全面信息，包括：

    • 距离（对于太阳系物体）

    • 相位信息（月球和行星）

    • 即将到来的月相（月亮）

  • 广泛的对象目录：包括：

    • 太阳系天体（太阳、月亮、行星）

    • 来自 HYG 数据库的 5,500 多颗星

    • NGC 目录中的 14,000 多个深空天体

工具

该软件包包含三个主要工具：

  1. getCelestialPosition ：计算天体的高度/方位角坐标

  2. getCelestialDetails ：提供有关天体的详细信息

  3. listCelestialObjects ：按类别返回可用天体的列表

Related MCP server: chuk-mcp-celestial

快速入门

# Install dependencies
npm install

# Build the project
npm run build

# Start the server
npm start

与 Claude Desktop 一起使用

本地开发

将此配置添加到您的 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"]
    }
  }
}

目录数据

该项目包括一个用于获取天文目录数据的脚本：

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

这会将 HYG 星数据库和 NGC 深空天体目录下载到data/目录。

工具使用

以下是使用 Claude 工具的一些示例：

获取对象位置

问克劳德：“从温哥华看，木星现在在天空中的什么位置？”

获取对象详细信息

问克劳德：“今天温哥华的月亮什么时候升起和落下？”

列出可用对象

问克劳德：“给我一份我可以查找的星星列表。”

项目结构

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

默认配置

默认情况下，观察者的位置设置为加拿大温哥华。你可以在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
};

执照

麻省理工学院

致谢

  • 用于核心天文计算的天文引擎

  • mcp-framework用于 MCP 服务器实现

  • HYG 星体数据数据库

  • OpenNGC 用于深空天体数据

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
NameRequiredDescriptionDefault
objectNameYesThe 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
NameRequiredDescriptionDefault
fovDegreesYesThe Field of View (FOV) of the user's equipment in degrees.
initialSearchRadiusDegreesYesThe angular radius around the target object to search for a suitable bright starting star. Default: 20.0 degrees.
maxHopMagnitudeYesThe maximum (dimmest) stellar magnitude for stars in the hopping path. Default: 8.0.
startStarMagnitudeThresholdYesThe maximum (dimmest) magnitude for a star to be a good, bright "starting star." Default: 3.5.
targetObjectNameYesThe 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
NameRequiredDescriptionDefault
categoryNoOptional. 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.

  1. 3 tool updatesv1.0.0
    • 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 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

Related MCP Connectors

Related MCP Servers

  • chuk-mcp-celestial

    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.
    8
    1
    Apache 2.0

  • astronomy-oracle

    gregario
    A
    license
    A
    quality
    C
    maintenance
    Accurate astronomical catalog data and observing session planner for LLM assistants. Stops hallucinated magnitudes, coordinates, and visibility.
    3
    76 npm
    3
    MIT