Vigi-Sky

Historical UFO cases near a place

nearby_cases

Read-onlyIdempotent

List historical UFO/UAP reports from the Hatch UDB archive (1900-2002, compiled by Larry Hatch) near a point, optionally filtered by country or text. Use it for the history of a region; it is not a live feed of recent sightings (use sky_events) and geocoding is approximate. Read-only query of the Vigi-Sky API; default radius 50 km, 200 km when filtering by country or text.

Input Schema

Name	Required	Description
`q`	No	Optional text filter on the case summary, e.g. 'cigar' or 'Valensole'.
`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.
`country`	No	Optional country filter as written in the archive, e.g. FRANCE, USA.
`radius_km`	No	Search radius in kilometres (default 50, or 200 with country/q; maximum 20000).

Output Schema

Name	Required	Description	Default
`cases`	No
`query`	No
`archive`	No
`returned`	No
`citations`	Yes
`provenance`	Yes
`not_vigisky_live`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedNov 2, 2026

addedInput schema / properties / country

Added value: +{
+  "description": "Optional country filter as written in the archive, e.g. FRANCE, USA.",
+  "type": "string"
+}

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

addedInput schema / properties / q

Added value: +{
+  "description": "Optional text filter on the case summary, e.g. 'cigar' or 'Valensole'.",
+  "type": "string"
+}

addedInput schema / properties / radius_km / description

Added value: +"Search radius in kilometres (default 50, or 200 with country/q; maximum 20000)."

addedOutput schema / description

Added value: +"Returns archive, query, returned, cases [...], not_vigisky_live (always true)."

Changed8 schema fields changedAug 18, 2026
- addedOutput schema / properties / archive
```
Added value: +{
+  "type": "object"
+}
```
- addedOutput schema / properties / cases
```
Added value: +{
+  "type": "array"
+}
```
- removedOutput schema / properties / doctrine
```
Removed value: -{
-  "type": "string"
-}
```
- addedOutput schema / properties / not_vigisky_live
```
Added value: +{
+  "type": "boolean"
+}
```
- addedOutput schema / properties / provenance / properties / never
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / query
```
Added value: +{
+  "type": "object"
+}
```
- addedOutput schema / properties / returned
```
Added value: +{
+  "type": "integer"
+}
```
- addedOutput schema / required
```
Added value: +[
+  "citations",
+  "provenance"
+]
```
First observedAug 17, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds genuine context beyond that: the archive's provenance and date range, approximate geocoding, and the non-obvious radius defaults (50 km, 200 km when filtering). It doesn't mention pagination or result limits, which keeps it short of a 5.

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?

Three compact sentences with the core purpose front-loaded and the exclusion plus radius caveat trailing. 'Read-only query of the Vigi-Sky API' slightly duplicates the readOnlyHint annotation, a minor redundancy in an otherwise tight description.

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?

With a full output schema, rich annotations, and 100% parameter coverage, the description only needs to supply scope, alternative routing, and data-quality caveats — and it does all three. Nothing required to call this tool correctly 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 description coverage is 100%, so the schema already documents lat/lng/lon aliasing, the lang enum, country format, and the radius_km default logic. The description restates the default-radius behaviour rather than adding new semantics, so the baseline 3 is appropriate.

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 — 'List historical UFO/UAP reports from the Hatch UDB archive (1900-2002)' — plus the spatial scoping ('near a point') and optional filters. It is immediately distinguishable from sibling tools like sky_events and hatch_stats.

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 routes the agent: 'Use it for the history of a region' and 'it is not a live feed of recent sightings (use sky_events)'. It also warns that geocoding is approximate, which is a real usage caveat an agent needs before trusting radius results.

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?