Current Layer Set Selection

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

Annotations already declare idempotentHint=true, destructiveHint=false and readOnlyHint=false, so the safety profile is partly covered. The description goes beyond that by disclosing the optimistic concurrency mechanism (expected_count + digest guard) and that the final OID set is verified, which is genuine behavioral context. It omits what happens on a concurrency mismatch and whether the selection is replaced or merged, keeping it below a 5.

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 filler; the concurrency guard is stated before the verification step. It is efficient, though the extreme terseness borders on under-specification for a six-parameter mutation tool.

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?

This is a write operation requiring six mandatory parameters with no schema descriptions and no output schema explanation needed (output schema exists). Given that complexity, one sentence covering only the concurrency guard leaves critical gaps: the semantics of operation and object_ids, and the failure mode on a concurrency conflict, are 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?

Schema description coverage is 0%, so the description must carry parameter meaning, and it largely does not. It references expected_count and digest conceptually but never explains aprx_path, layer_name, object_ids, or — most importantly — the operation parameter, whose allowed values and replace-vs-add semantics are entirely undocumented.

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 states a specific verb and resource (更新...选择集) and pins it to the CURRENT layer, so an agent knows this mutates the active layer's selection rather than a table or an arbitrary dataset. It does not distinguish itself from siblings like select_layer_by_attribute, select_layer_by_location, or clear_map_selection, leaving the routing to inference.

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 mention of prerequisites or alternatives. The many selection-related siblings (select_layer_by_attribute, select_layer_by_location, clear_map_selection, delete_layer_selection, layer_selection_count/fids) are never referenced, so the agent gets no help choosing this tool over them.

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