Vigi-Sky

Aurora odds for a latitude

aurora

Read-onlyIdempotent

Return the current geomagnetic Kp index and whether an aurora can be seen from a given latitude, with the Kp needed there (France: Kp 6 in the far north, 7 to 8 in the centre, 9 in the south). Use it for 'can I see the aurora tonight'; for the solar storms behind it (CMEs) use solar, for a full night summary use tonight_sky. Live NOAA SWPC data through the Vigi-Sky API, cached 2 minutes; clouds and light pollution are not modelled.

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": {
      "lat": "<lat>"
    },
    "name": "aurora"
  }
}

Input Schema

Name	Required	Description
`lat`	Yes	Observer latitude in decimal degrees, WGS84 (north positive).
`lng`	No	Observer longitude in decimal degrees, WGS84 (east positive). lon and lng are aliases: give one.
`lon`	No	Observer longitude in decimal degrees, WGS84 (east positive). lon and lng are aliases: give one.
`lang`	No	Language of the text fields: fr (default) or en.

Output Schema

Name	Required	Description	Default
`aurora`	No
`citations`	Yes
`provenance`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedNov 2, 2026

addedInput schema / properties / lang / description

Added value: +"Language of the text fields: fr (default) or en."

changedInput schema / properties / lat / description

Previous value: -"Latitude WGS84"New value: +"Observer latitude in decimal degrees, WGS84 (north positive)."

changedInput schema / properties / lng / description

Previous value: -"Longitude WGS84. lon and lng are aliases — provide either."New value: +"Observer longitude in decimal degrees, WGS84 (east positive). lon and lng are aliases: give one."

changedInput schema / properties / lon / description

Previous value: -"Longitude WGS84. lon and lng are aliases — provide either."New value: +"Observer longitude in decimal degrees, WGS84 (east positive). lon and lng are aliases: give one."

addedOutput schema / description

Added value: +"Returns aurora {kp_current, kp_needed, visible_now, user_latitude}, citations, provenance."

Changed1 schema field changedAug 18, 2026
- addedOutput schema / required
```
Added value: +[
+  "citations",
+  "provenance"
+]
```
First observedAug 17, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Beyond the readOnly/idempotent/openWorld annotations, the description discloses the data source (NOAA SWPC via Vigi-Sky), a 2-minute cache TTL, and two explicit model limits (clouds and light pollution not modelled). That is real behavioral context; only the response shape is left unstated, which the output schema covers.

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?

Front-loaded with what is returned, then usage routing, then data provenance and caveats — a sensible order with no filler. It is a single dense paragraph whose parenthetical France example is long but genuinely illustrative rather than redundant.

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 annotations covering the safety profile, an output schema present, and full parameter documentation, the description supplies the remaining essentials: scope, alternatives, data source, cache, and known non-modelled factors. Only edge-case behavior (e.g. polar latitudes or how borderline Kp is reported) is unaddressed.

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 100%, including lat/lon ranges and the lon/lng alias note, so the baseline is 3. The description adds a useful interpretation of latitude via the France Kp-by-region example, but says nothing about how lng or lang affect the result beyond what the schema already documents.

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?

States a specific verb and two concrete outputs (current Kp index and aurora visibility for a latitude), plus the local Kp threshold needed. It is clearly distinguishable from sibling tools like solar, moon, or tonight_sky without opening any schema.

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?

Gives an explicit triggering question ('can I see the aurora tonight') and names two alternatives with the conditions that select them: solar for CMEs, tonight_sky for a full night summary. Nothing is left to inference.

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

All Vigi-Sky tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?