Vigi-Sky

Match a precise sighting to a satellite

identify

Read-onlyIdempotent

Check whether a precisely measured point in the sky (azimuth, elevation and exact time) matches one of about 160 bright satellites and rocket bodies within 2 degrees, also listing planets, the Moon and bright stars within 5 degrees. Use it when the witness measured the direction (compass, phone app); for a vague memory ('a light last night towards the west') use what_did_i_see, for a fixed star or planet use which_star. Returns insufficient_data when orbital elements are older than 72 hours. A match means compatible with the observation, not proven; the tool never says 'UFO detected'.

Input Schema

Name	Required	Description
`az`	Yes	Direction in degrees from true north, clockwise: 0 = north, 90 = east, 180 = south, 270 = west.
`el`	Yes	Height above the horizon in degrees: 0 = horizon, 90 = straight overhead.
`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.
`time`	Yes	Moment of the observation, ISO-8601 with a time zone, e.g. 2026-11-01T19:30:00Z.

Output Schema

Name	Required	Description	Default
`answer`	No
`matches`	No
`verdict`	No
`citations`	Yes
`best_match`	No
`provenance`	Yes
`separation_deg`	No
`rejected_matches`	No
`natural_objects_within_5deg`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedNov 2, 2026

addedInput schema / properties / az / description

Added value: +"Direction in degrees from true north, clockwise: 0 = north, 90 = east, 180 = south, 270 = west."

addedInput schema / properties / el / description

Added value: +"Height above the horizon in degrees: 0 = horizon, 90 = straight overhead."

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."

changedInput schema / properties / time / description

Previous value: -"ISO-8601, e.g. 2026-08-14T21:30:00Z"New value: +"Moment of the observation, ISO-8601 with a time zone, e.g. 2026-11-01T19:30:00Z."

addedOutput schema / description

Added value: +"Returns verdict (compatible | no_catalog_match | insufficient_data), answer, best_match, matches, natural_objects_within_5deg, rejected_matches, separation_deg."

Changed3 schema fields changedNov 2, 2026

addedOutput schema / properties / answer

Added value: +{
+  "enum": [
+    "satellite",
+    "natural_object",
+    "nothing_known",
+    "unknown_catalog_stale"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / natural_objects_within_5deg
```
Added value: +{
+  "type": "array"
+}
```
addedOutput schema / properties / rejected_matches
```
Added value: +{
+  "type": "array"
+}
```

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

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real behavioral context beyond them: the insufficient_data failure mode when orbital elements exceed 72 hours, the epistemic caveat that a match is 'compatible with the observation, not proven', and the explicit note that it never claims 'UFO detected'. These are non-obvious traits an agent needs.

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?

Three sentences, front-loaded with the core matching behavior, then usage routing, then caveats. No filler; every clause carries information an agent would otherwise have to guess.

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?

Output schema exists so return values needn't be explained, and the description still covers the key interpretive point (match = compatible, not proof) and the degraded-data failure case. Nothing essential for correct invocation is missing.

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%, so az, el, lat, lon/lng, time and lang are all documented in the schema itself. The description restates 'azimuth, elevation and exact time' but adds no format or constraint detail beyond the schema, so the baseline 3 applies.

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 resource ('check whether a precisely measured point in the sky ... matches one of about 160 bright satellites and rocket bodies') with concrete scope (2 degrees for satellites, 5 degrees for planets/Moon/stars). This is clearly distinguishable from which_star and what_did_i_see, which are named.

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 when to use it ('when the witness measured the direction (compass, phone app)') and routes two alternatives: what_did_i_see for vague memory, which_star for a fixed star or planet. Both the positive condition and the exclusions are stated.

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?