Skip to main content
Glama

Commonlands Optics: M12 Lens and C-Mount Lens Finder + Field-of-View Calculator

by com.commonlands

Calculate Commonlands field of view

calculate_field_of_view
Read-onlyIdempotent

Calculate Commonlands lens field of view for a lens/sensor pair and return HFOV, VFOV, DFOV, coverage, distortion status, and an explicit rectilinear comparison. Use this tool for FOV, HFOV, VFOV, DFOV, field of view, "lens for", lens-to-sensor, AR0234, IMX290, IMX477, and sensor part-number requests. It returns Commonlands data the model cannot derive: live backend FoV when configured, distortion model/status, image-circle coverage, live stock through Shopify read tools where applicable, and MTF/CRA/BFL fields if present in upstream catalog data. Do not use naive rectilinear fallback, focal-length-only math, interpolation, or self-computed catalog estimates when a Commonlands lens/sensor route is available. Accepts lens_sku/lensSku or focal_length_mm/focalLengthMm, plus sensor/sensorPartNumber/sensor_part_number and working_distance_mm/workingDistanceMm. No part number? Describe the sensor directly: widthPx + heightPx + pixelSizeUm (active area is derived as pixels x pitch), or sensorWidthMm + sensorHeightMm. Results are labelled CUSTOM-x. If only focal length is supplied, the response is marked as a rectilinear reference and does not claim Commonlands distortion-corrected lens truth.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sensorNoSensor part number or safe sensor object. Supports AR0234, IMX290/IMX477 when present in the live catalog, and fixture sensors listed in the enum.
lensSkuNoCommonlands lens SKU, for example CIL250. Camel-case alias for lens_sku.
widthPxNoCustom sensor: horizontal pixel count (e.g. 4056). Use with heightPx and pixelSizeUm.
heightPxNoCustom sensor: vertical pixel count (e.g. 3040).
lens_skuNoCommonlands lens SKU, for example CIL250. Snake-case alias for lensSku.
pixelSizeUmNoCustom sensor: pixel pitch in microns (e.g. 1.55).
pixelPitchUmNoAlias for pixelSizeUm.
focalLengthMmNoFallback rectilinear reference only when no Commonlands lens SKU is available. Camel-case alias for focal_length_mm.
sensorWidthMmNoCustom sensor: active-area width in mm (alternative to pixels x pitch).
sensorHeightMmNoCustom sensor: active-area height in mm.
verticalPixelsNoAlias for heightPx.
focal_length_mmNoFallback rectilinear reference only when no Commonlands lens SKU is available. Snake-case alias for focalLengthMm.
horizontalPixelsNoAlias for widthPx.
sensorPartNumberNoSensor part number. Camel-case alias for sensor.
workingDistanceMmNoOptional working distance in mm. Camel-case alias for working_distance_mm.
sensor_part_numberNoSensor part number. Snake-case alias for sensorPartNumber.
working_distance_mmNoOptional working distance in mm. Snake-case alias for workingDistanceMm.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
methodYes
dfov_degYes
hfov_degYes
vfov_degYes
coverage_okYes
image_circle_mmYes
distortion_modelYes
sensor_diagonal_mmYes
rectilinear_comparisonYes

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already indicate safe read-only, idempotent, non-destructive behavior. The description adds valuable context: returns live backend FoV when configured, distortion status, image-circle coverage, live stock via Shopify, and MTF/CRA/BFL fields if present. It also discloses result labeling for custom sensors and the rectilinear reference marker, going well beyond annotations.

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 description is long but well-structured and front-loaded with purpose. It flows from purpose to usage to parameters to edge cases, with each sentence earning its place. While not terse, the verbosity is justified by the tool's complexity and the need to disambiguate from naive calculations and many aliases.

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?

Given the tool's complexity (17 params, multiple aliases, output schema present), the description covers the main purpose, when to use it, parameter selection strategies, result caveats, and fallback behavior. It omits error handling or authentication details, but with output schema and annotations, it is sufficiently complete for an agent.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful grouping and usage semantics: it explains the alias pairs (lens_sku/lensSku, etc.), outlines alternative sensor description methods (pixels+pitch vs. mm dimensions), and clarifies when to use focal length vs. lens SKU. This enriches parameter understanding beyond the schema.

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?

The description clearly states the tool calculates Commonlands lens field of view for a lens/sensor pair and returns specific outputs (HFOV, VFOV, DFOV, coverage, distortion status, rectilinear comparison). It also names common request phrasings it handles, distinguishing it from naive math and sibling tools.

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 provides when to use ('Use this tool for FOV, HFOV, VFOV, DFOV...') and when not to ('Do not use naive rectilinear fallback, focal-length-only math...'). It also explains the fallback behavior when only focal length is given, giving clear guidance on alternatives.

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

All Commonlands Optics: M12 Lens and C-Mount Lens Finder + Field-of-View Calculator toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.8/5.0
Disambiguation2/5

Several tools have significant overlap in purpose and trigger keywords. calculate_field_of_view, match_lens_to_sensor, and get_lens_distortion_profile all share nearly identical use-case descriptions for FOV/sensor requests, while search_catalog, search_lens_catalog, and lookup_catalog all provide search/lookup functionality with subtle differences that are easy to confuse.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (e.g., calculate_field_of_view, create_cart, get_product, read_shopify_products, submit_rfq). No mixing of styles or unpredictable naming conventions.

Tool Count3/5

With 21 tools, the surface is noticeably heavy for a lens finder and FOV calculator, especially when several tools serve status/config purposes (get_catalog_snapshot_status, get_shopify_readonly_config_status, get_shopify_ucp_readiness). It sits in the 'feels heavy' range from the rubric.

Completeness4/5

The tool set covers the full lifecycle: catalog search, product details, sensor specs, FOV calculation, lens matching, distortion profiles, Shopify carts, purchase handoff, and RFQ submission. Minor gaps exist (e.g., no delete_cart or bulk sensor listing), but core workflows are well-supported.

Resources