Sky Compass MCP

locate_by_coordinates

Converts RA/Dec coordinates into magnetic compass bearing and altitude for a specified location and time, helping observers point to celestial objects and check horizon visibility.

Instructions

Magnetic compass bearing and altitude for explicit RA/Dec (ICRS, J2000 degrees).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "ra_deg": "<ra_deg>",
      "dec_deg": "<dec_deg>"
    },
    "name": "locate_by_coordinates"
  }
}

Input Schema

Name	Required	Description
`ra_deg`	Yes	Right ascension, ICRS J2000 degrees.
`dec_deg`	Yes	Declination, ICRS J2000 degrees.
`latitude`	No
`time_utc`	No	ISO 8601 UTC time. Defaults to now.
`longitude`	No
`place_name`	No	Observer place name. An uncached query is sent to public OpenStreetMap Nominatim.
`elevation_m`	No	Elevation above sea level, metres.
`magnetic_declination_deg`	No	Local magnetic declination, east positive (from a WMM lookup). Bearing = true azimuth - declination.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.1.0Nov 5, 2026

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are supplied, so the description carries the full behavioral burden and does very little with it. It does not say that the bearing depends on observer latitude/longitude/time, that missing location means a place-name lookup is attempted, or what happens when place_name is uncached. The one behavioral hint (ICRS/J2000) duplicates the schema.

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?

A single front-loaded sentence with no filler, which makes the core purpose immediately clear. It is arguably too compressed given the eight parameters, but there is no wasted wording to penalize.

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?

For an eight-parameter astronomy tool with no annotations and no output schema, the description is thin. It never explains that a meaningful compass bearing requires observer latitude/longitude and time, nor what the return value looks like (bearing in degrees? altitude in degrees? both tied to the given time?), leaving the caller to infer the tool's actual utility.

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 coverage is 75%, so the schema already documents ra_deg, dec_deg, latitude, longitude, elevation, and magnetic declination well. The description restates the RA/Dec frame but adds nothing about the relationship between the optional observer fields and the bearing computation; the baseline 3 for high schema coverage applies.

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 names a specific output (magnetic compass bearing and altitude) and a specific input (explicit RA/Dec in ICRS J2000 degrees), which distinguishes it from get_place_coordinates and locate_celestial_object, both of which presumably work from names or places. It does not explicitly name those siblings, but the 'explicit RA/Dec' qualifier does the differentiating work.

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 phrase 'explicit RA/Dec' implies this tool is the right choice when the caller already has coordinates rather than an object name or place, which is useful implied routing. However, there is no explicit when-to-use/when-not statement, no mention of the alternatives by name, and no guidance on which optional observer parameters matter.

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

Deploy Server