Stellarhound — stargazing forecasts, dark-sky sites & aurora

calculate_telescope_fov

Read-only

Compute astrophotography field of view, image scale, diffraction limits, and seeing sampling (fov-v1).

Use when the user asks "will M31 fit in my telescope + camera", "what is the
image scale of an RedCat 51 / Askar SQA55 / EdgeHD 8 with an ASI2600MC", or
"am I undersampled or oversampled". Uses Stellarhound's deterministic fov-v1
rules (exact 2*atan(s / 2f) field of view, 206.265*pixel_um/f_mm image scale,
Dawes 116/D and Rayleigh 138/D limits, and Nyquist 2-3 px/FWHM sampling bands
across 1.5", 2.0", 2.5", 3.0" seeing).

Args:
    focal_length_mm: Effective focal length in mm (include reducer/barlow factor if used, >0).
    aperture_mm: Clear aperture diameter in mm (>0).
    sensor_w_mm: Sensor width in mm (>0).
    sensor_h_mm: Sensor height in mm (>0).
    pixel_um: Pixel pitch in micrometres (>0, optional).

Returns {rules_version, fov_w_deg, fov_h_deg, fov_diag_deg, fov_w_arcmin,
fov_h_arcmin, f_ratio, scale_arcsec_px, dawes_arcsec, rayleigh_arcsec,
sampling:[{fwhm_arcsec, px_per_fwhm, verdict}], source_url, citation}.

Input Schema

Name	Required	Description	Default
`pixel_um`	No
`aperture_mm`	Yes
`sensor_h_mm`	Yes
`sensor_w_mm`	Yes
`focal_length_mm`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 30, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so safety is covered. The description adds real behavioral value beyond that: it pins the ruleset version (fov-v1), discloses the exact formulas used (2*atan(s/2f), 206.265*pixel/f, Dawes 116/D, Rayleigh 138/D, Nyquist 2-3 px/FWHM), and states the result is deterministic and cited — an agent knows the output is reproducible and traceable.

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 the purpose sentence, then triggers, then method, then args, then returns — a clean and scannable order. The Returns block is long, but with no output schema it earns its space by enumerating the exact keys the agent will receive.

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?

Given zero schema descriptions and no output schema, the description supplies everything needed: units and constraints for all inputs, the full return-key list, and the rule provenance for the numeric outputs. An agent can call this correctly and interpret the response without further lookups.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the entire burden, and it does: each of the five parameters gets a unit, a positivity constraint, and a semantic caveat (focal_length_mm must include reducer/barlow factor; pixel_um is optional). The 'Args' block effectively substitutes for the missing schema descriptions.

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?

Names a specific verb ('Compute') and a concrete set of outputs: field of view, image scale, diffraction limits, and seeing sampling. The scope is unambiguously different from every sibling (site finding, aurora, light pollution, conditions, agenda), so an agent can route on the first clause alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives three concrete user-question triggers ('will M31 fit in my telescope + camera', 'what is the image scale of a RedCat 51...', 'am I undersampled'), which is strong positive routing guidance. It stops short of stating when NOT to use it or naming an alternative, but the sibling set is a different domain so the risk of confusion is low.

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

All Stellarhound — stargazing forecasts, dark-sky sites & aurora 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?