Skip to main content
Glama

verify_astrometry

Verify an image's astrometric solution by measuring how well it reproduces sky positions, comparing detected stars to Gaia DR3 and reporting deviation statistics.

Instructions

Measure how well an open image's astrometric solution reproduces the sky, with the engine of PixInsight's AstrometricSolutionVerifier script (PixInsight 1.9.5 or later), run without its dialog: no deviation map, graphs, files or new windows, and the image is not modified. Every detected star is PSF-fitted, placed on the sky with the image's solution and compared with its Gaia DR3 star at the observation time. The result (JSON) gives the star counts (detected, PSF-fitted, matched, rejected by sigma clipping), the catalogue and its limit magnitude, the deviations (median, sigma, rms, 90th and 99th percentile, maximum) in pixels and arcseconds over the stars kept after sigma clipping and over all matched stars, the median bias, and the grid cell with the largest median deviation (cells with fewer than 3 matched stars are skipped) with its column, row and centre in image pixels. The view needs an astrometric solution.

Input Schema

NameRequiredDescriptionDefault
view_idYesView ID to verify
magnitudeNoCatalogue limit magnitude used when auto_magnitude is false (script default 16)
grid_cellsNoNumber of grid cells along the largest image dimension, 1 to 255 (script default 8)
auto_magnitudeNoChoose the catalogue limit magnitude automatically (script default true)
rejection_sigmaNoSigma-clipping factor on the deviations; matched stars beyond median + factor x sigma are left out of the retained statistics and the grid, 0 disables (script default 5)
matching_toleranceNoMaximum distance in pixels between a detected star and its catalogue position for a match (script default 3)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.5.0

TDQS

A4.1/5.0
Behavior5/5

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

With no annotations, the description fully carries behavioral disclosure and does so well: it is non-destructive ('the image is not modified'), produces no side artifacts (no deviation map, graphs, files or new windows), and explains the algorithm (PSF-fit stars, matched to Gaia DR3). It also enumerates the returned JSON fields in detail.

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 purpose is front-loaded in the first clause, and the dense enumeration of return fields earns its place because there is no output schema. The single long paragraph is information-rich but slightly overloaded, with the 'needs an astrometric solution' prerequisite trailing at the end.

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?

For a 6-parameter, non-destructive analysis tool with no annotations and no output schema, the description is close to complete: it explains behavior, side-effect profile, and the full return structure. It could still clarify failure behavior (e.g., what happens if no solution exists) and the parameter-return relationship.

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 every parameter is already documented in the schema with defaults and meanings. The description references related concepts (sigma clipping, grid cells, catalogue limit magnitude) but adds no parameter syntax or constraints beyond what the schema supplies, making the baseline 3 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: 'Measure how well an open image's astrometric solution reproduces the sky', and names the exact engine (PixInsight's AstrometricSolutionVerifier). This clearly distinguishes it from siblings like run_plate_solve (which creates a solution) and copy_astrometric_solution (which transfers one).

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?

It states the key prerequisite ('The view needs an astrometric solution') and the version requirement (PixInsight 1.9.5+), which is useful. However, it never explicitly contrasts itself with alternatives such as run_plate_solve, nor says when verification is warranted versus when to first solve — guidance is implied rather than stated.

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