zemax_nsc_polar_detector_dataRead bounded Detector Polar data from a Zemax non-sequential detector using object number and quantity, returning up to maxValues results.
Read bounded full Detector Polar data.
| Name | Required | Description | Default |
|---|---|---|---|
| quantity | Yes | Polar detector quantity | |
| maxValues | No | Maximum values returned | |
| objectNumber | Yes | Detector Polar object number |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden and mostly fails it. 'Bounded' hints at truncation but never states what the bound is, whether results are truncated at maxValues, what happens if the detector is larger, or whether the object must exist first. It also never explicitly confirms this is a non-mutating read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with no filler, and the key constraint ('bounded') is front-loaded. It is arguably under-specified rather than over-long, so it loses only a point for the ambiguous 'bounded full' wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain the return shape and truncation semantics for this data-retrieval tool. It does not say what a returned record looks like, whether values are truncated, or what happens on a large detector, leaving significant gaps for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (quantity, maxValues, objectNumber) are already documented in the schema, making a baseline of 3 appropriate. The description's only added signal is the word 'bounded,' which loosely ties to maxValues without explaining its truncation behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Read') and resource ('Detector Polar data'), which distinguishes it from the pixel-level sibling zemax_nsc_polar_detector_pixel. However, the phrase 'bounded full' is internally ambiguous -- it is unclear whether 'full' means the whole detector or a truncated payload -- so an agent gains only a rough sense of scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no prerequisites, and no explicit routing to or away from siblings such as zemax_nsc_polar_detector_pixel or zemax_nsc_detector_data is provided. The agent must infer that this fetches whole-detector polar data while the pixel sibling fetches a single element.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.