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

With no annotations, the description carries the full behavioral burden and does disclose real traits: the operation is a request whose completion is not immediate, and cancelling a native plot additionally closes the CODE V plot file already opened. It omits any note on permissions, idempotency, or behavior if no task is running.

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?

Two sentences, both load-bearing: the first states the action and its two-state semantics, the second scopes applicability and the side effect. Nothing is repeated or wasted, and the core action is front-loaded.

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?

An output schema exists, so return values need not be described, and with zero parameters the surface is small. The description covers applicability and the main side effect; only edge-case behavior (e.g. calling when nothing is running) is left unstated.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description adds no parameter information, which is appropriate here.

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 gives a specific verb+resource ('请求取消当前分析任务' / request cancellation of the current analysis task) and even distinguishes the two resulting states (requested vs. confirmed stopped). It does not name a sibling such as run_analysis or get_status to route against, so it falls short of a 5.

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?

It states an explicit applicability condition: only meaningful for asynchronous tasks (spot diagram and native plot export), which implicitly excludes synchronous analyses. No alternative tool is named for the cases where cancellation is not applicable, so it stops short of a 5.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose the postcondition (returns the released session's status), but omits whether the operation is idempotent, what happens if no session exists, and whether release is irreversible.

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 compact sentence covering both the action and its postcondition, with the action front-loaded. The clause about returning the post-release status is mildly redundant given an output schema exists, but nothing is wasted.

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?

For a parameterless cleanup call with an output schema covering the return value, the description supplies enough to invoke it correctly. The remaining gap is lifecycle/prerequisite context rather than anything structural.

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?

The tool takes zero parameters and the schema is fully described, so there is nothing for the description to disambiguate. The baseline of 4 for a parameterless tool applies.

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?

States a specific verb (release/close) and resource (the CODE V session), and scopes it to the session 'created by this service'. Among the lens-oriented siblings there is no competing session-lifecycle tool, so the purpose is unambiguous without further differentiation.

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?

The description says what the tool does but gives no when-to-use or when-not guidance. It does not state prerequisites (an open session), whether it is safe to call when none exists, or how it relates to any session-opening flow, leaving the agent to infer usage entirely.

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

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

With no annotations, the description carries the full burden and does disclose real behavior: it publishes a verified recovery point (a side effect), requires an empty session, and explains that with image_solve='pim' the surface thickness becomes CODE V-derived and no longer directly editable. It omits permission/error behavior, but the non-obvious mutation semantics are well covered.

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?

Two sentences, front-loaded with the core action and precondition, then the image_solve caveat. Every sentence carries information, though the PIM explanation is slightly dense.

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?

An output schema exists, so return values need no explanation. The description covers the key non-obvious aspects (empty-session requirement, recovery point, PIM behavior); remaining gaps like units handling and aperture kinds are documented in the nested schema.

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?

Top-level schema coverage is reported as 0%, and the description compensates richly for exactly one field (image_solve='pim' and its non-editable consequence). The many nested fields (units, aperture_kind, wavelengths, fields, surfaces) rely entirely on their nested schema descriptions and get no extra meaning from the description.

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?

States a specific verb and resource: creates a new single-zoom lens from restricted spherical specs. The 'in an empty session' qualifier and the 'typed values only' framing help distinguish it from open_lens/update_lens, though no sibling is named explicitly.

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?

The 'empty session' precondition is a useful usage constraint, but the description never states when to prefer create_lens over open_lens or edit_lens_structure, nor any explicit exclusion. Usage is implied by session state rather than spelled out.

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

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

No annotations are provided, so the description carries the full burden. It hints at a readback/verify-and-restore step (回读并核对恢复), but for a destructive structural mutation it never states reversibility, atomicity across the batch, permission requirements, or what happens to existing surfaces. The behavioral picture is left largely unspecified.

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 compact sentence that front-loads the scope and the operation set. Nothing is padded, though it is terse to the point of under-specification rather than tightly informative.

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?

An output schema exists, so return-value explanation is not required, and the scope plus operation types are covered. However, with no annotations on a mutation tool and no parameter guidance, the definition leaves meaningful gaps for correct invocation.

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 0%, so the description must compensate, but it only loosely maps to the three operation kinds (insert_sphere, delete_surface, set_stop) without explaining fields like glass, radius, thickness, before_surface, or new_stop_surface. The one useful schema note ('native CODE V numbers') lives in the schema, not the description.

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 specific verbs and resources: batch insert/delete ordinary spherical surfaces and set the aperture stop on simple lenses created by this service. This distinguishes it from the general update_lens sibling, though it doesn't name that sibling explicitly.

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?

It scopes usage to 'simple lenses newly created by this service' (对本服务新建的简单镜头), which implies when the tool applies, but it never names an alternative such as update_lens or states when not to use it. Usage is implied rather than explicit.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose useful non-obvious traits: results come back as text JSON, images are additionally emitted as MCP image content, and a copy is retained in the result file. It omits failure behavior when no analysis is running, permissions, and whether repeated calls are cheap.

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?

Two short sentences: the first front-loads purpose and scope, the second covers the return channels. No filler, no restatement of the name or title, and the most decision-relevant information comes first.

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?

A no-parameter read tool with an output schema and full schema coverage needs little text, so the description is close to sufficient. However, the unresolved overlap with the sibling get_status and the absence of any precondition (an analysis must be running) leave a real gap for correct invocation.

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?

The tool takes zero parameters, so there are no parameter semantics to explain; the baseline for a parameterless tool is 4. The description adds no misleading parameter information.

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 uses a specific verb+resource ("get the status, numerical results, and images of the current analysis task") and scopes it to the current analysis, so the agent knows what it retrieves. It does not differentiate itself from the sibling get_status, which creates residual ambiguity about which of the two to call.

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?

There is no explicit when-to-use guidance, no statement of prerequisites (e.g. call after run_analysis, only valid while an analysis is active), and no exclusion of the sibling get_status or run_analysis. The phrase "current analysis task" weakly implies post-startup use, but the agent must infer everything.

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

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

No annotations are supplied, so the description carries the full burden for a read-only tool. It usefully discloses the scoping nuance that zoom_position only affects data fetched by zoom position, and that field data carries CODE V VUX/VLX/VUY/VLY vignetting factors, but it never states read-only/no-side-effect semantics or anything about volume/size of the returned data.

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?

Two short paragraphs, front-loaded with the tool's scope and followed by the two operative caveats (vignetting-factor naming/write path, zoom_position scoping). No filler, though the parenthetical CODE V identifier list is dense reference material rather than selection guidance.

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?

An output schema exists, so return values need not be described; given that, the description covers what is read, the zoom-position behavior, and the write counterpart. It leaves minor gaps about the relationship to get_status and whether a session must be open first.

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 0%, so the description must explain the single parameter, and it does: zoom_position is for multi-zoom lenses and only affects zoom-position-dependent values. The default-null / 'omit for the current position' semantics are implied rather than stated, keeping it short of a 5.

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 opening sentence uses a specific verb (读取/read) plus the resource (当前镜头/current lens) and enumerates exactly which data blocks it returns (surfaces, materials, units, aperture, wavelength, field, zoom position). This clearly separates it from write-oriented siblings like update_lens and edit_lens_structure, so an agent can route without opening any schema.

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?

It states the condition for the optional parameter (zoom_position applies to multi-zoom lenses only) and points at the alternative tool for the write path (vignetting factors can be modified via update_lens). It never states explicitly when to prefer get_lens over get_status or get_analysis, so the routing is clear but not exhaustive.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the scope of state inspected (session, lens, analysis task, capabilities), which implicitly frames this as a non-mutating inspection, but it never explicitly confirms read-only/idempotent behavior, side effects, cost, or state freshness.

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 front-loaded sentence with no preamble or filler, and the most important noun (status) is implied by the name and reinforced by the field list. It is a comma-separated enumeration rather than structured prose, but nothing is wasted.

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 an output schema present, the description is not obliged to explain return formats, and a parameterless status tool needs little else. The only gap is the absence of any guidance on when the reported state is meaningful or how often to re-check, which is minor given the tool's simplicity and its English-named sibling set.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. No argument semantics are needed or missing.

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 clear verb (return/get) and enumerates the specific resources reported: backend type, CODE V version, session and lens state, current analysis task, and supported capabilities. No sibling tool (open_lens, get_lens, run_analysis, etc.) overlaps with this diagnostic role, so an agent can identify it without opening the schema. It stops short of explicitly contrasting itself with siblings, which keeps it from a 5.

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?

There is no when-to-use statement, no prerequisites, and no mention of alternatives or follow-up tools. The list of returned state only implicitly suggests a 'check before you act' role; the agent must infer when this call is warranted versus get_lens or get_analysis.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Working copy' hints at session state, but it never says whether the underlying file is modified, whether the copy must later be released via close_session, whether repeated opens are allowed, or what permissions are needed. For a state-creating operation this is a significant gap.

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?

One compact sentence, front-loaded with the action and resource, followed by the returned data. No padding or redundancy.

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?

An output schema exists, so return values need not be re-explained, and the description correctly enumerates the returned categories. However, for a session-opening tool with no annotations and a documented sibling (close_session), the lifecycle and file-safety context an agent needs is absent.

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 0% and the single required 'path' parameter is never explained. The mention of a '.len 镜头文件' does implicitly signal the expected file type, which gives partial meaning, but format, absolute-vs-relative path, and error behavior are all unaddressed.

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 gives a specific verb ('打开' / open) and a specific resource (a working copy of a .len lens file), and lists what the call surfaces (surfaces, materials, units, wavelengths, fields). This distinguishes it reasonably from create_lens and get_lens, though it never explicitly names an alternative sibling. It is clear but lacks the explicit sibling differentiation that would earn a 5.

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?

There is no when-to-use guidance, no statement of when to prefer this over create_lens, get_lens, or open-a-new-session flows, and no mention of prerequisites or the close_session lifecycle. The agent is left to infer the correct moment to call it.

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

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

No annotations are provided, so the description carries the full behavioral burden and does a good job: it discloses sync vs async execution per analysis kind, the one-task-at-a-time concurrency constraint, that WAV fixes NRD=20 and does not change the focal plane, and that MTF needs a caller-supplied frequency grid. It omits error/failure behavior and permission requirements.

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?

Front-loads the submission action and the returned status, then layers constraints per analysis kind. Dense but each sentence conveys a distinct constraint; no obvious padding.

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 an output schema present, return values need not be explained, and the description covers the key operational traits an agent needs (async vs sync, polling via get_analysis, single-task limit, WAV restrictions). Only some option-level parameter details are left to the schema.

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?

Reported schema description coverage is 0% for the top-level argument, so the description must compensate. It clarifies that native plots are selected via options.plot_type and that MTF frequencies must be supplied by the caller, but leaves ray_grid, azimuth, field_numbers, zoom_position and wavelength_numbers unaddressed.

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?

States a specific verb and the resources it submits (一阶参数、点列图、MTF、当前焦面 WAV、原生绘图) and notes it returns task status. It is distinguishable from get_analysis by being the submission step, but it does not explicitly name that sibling as the polling counterpart in the purpose statement.

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?

Gives concrete usage context: spot diagram and native plots are asynchronous and require polling get_analysis, while first-order, MTF and WAV complete synchronously; only one analysis task is allowed at a time; WAV is limited to single-zoom lenses over all fields/wavelengths. No explicit 'when not to use' or routing among siblings beyond the async note.

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

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

With no annotations, the description carries the full burden. It usefully discloses the refusal behavior (no overwrite of source or existing files), which is real behavioral context. It stops there, though: nothing about permissions, what happens to the original working copy, or side effects.

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 front-loaded sentence that states the action first and the constraint second. No filler or redundancy.

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?

An output schema exists so return values need not be explained, and the save-as plus refusal behavior is covered. Gaps remain around what 'current working copy' refers to and the undocumented path parameter, leaving it only minimally adequate for a 1-param tool.

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 0% and the single 'path' parameter is never mentioned in the description. The name 'path' is largely self-explanatory, but the description adds no meaning about its format, target location, or constraints.

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?

States a specific verb+resource ('save the current working copy as a new file'), which is clearly distinct from the mutation siblings like update_lens or create_lens. It does not explicitly name a sibling to differentiate from, but the save-as semantics are unambiguous.

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?

It communicates a when-not condition ('refuses to overwrite the source file or existing files'), which implies you should use it for creating a new copy rather than overwriting. However, it names no alternatives and gives no explicit trigger conditions for choosing it over create_lens or update_lens.

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

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

With no annotations, the description carries the full burden and does so: it states the whole batch is one transaction sharing a recovery point and that any single rejection rolls back the entire batch, which is critical for an agent to know before writing. It also discloses rejection rules (solves/pickups), read-only restrictions (auto aperture, obscurations, compound definitions), and inheritance semantics for field_set.

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?

Purpose and the atomicity rule are front-loaded, and the dense blocks on field_set and aperture constraints each add non-redundant rules. It is long, but the length tracks the real complexity of the tool; only the aperture section feels slightly compressed given how many edge cases it mentions.

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?

For a batch-mutation tool with no annotations, the description covers atomicity, per-target selectors, zoom handling, field_set transaction isolation, and read-only cases. An output schema exists, so return values need not be explained, and nothing an agent needs to call this correctly appears to be missing.

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?

Top-level schema coverage is reported as 0%, but the description compensates by enumerating the per-target parameter names, the vignetting valid range (-0.99..0.99), the 1-10 field count limit of field_set, and the meaning of target=aperture/parameter=value. The nested $defs also carry their own descriptions, so this is well beyond the schema alone, though it does not restate every nested field.

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 opens with a specific verb and resource: batch-modifying existing surface, field, wavelength, and constrained-aperture parameters. The emphasis on '已有' (existing) parameters cleanly separates it from a structure-editing sibling like edit_lens_structure, which adds or removes optical elements.

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?

It sets concrete conditions and exclusions: solve/pickup-controlled parameters are rejected, multi-zoom lenses must supply zoom_position, field_set cannot be batched with edits, and only single-zoom angle-defined fields / single-zoom apertures are supported. It stops short of naming sibling tools (e.g. edit_lens_structure) as the alternative for structural changes, so it is context-rich but not fully routing.

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