coregister

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

There are no annotations, so the description carries the full burden. It does disclose useful runtime behavior: live pyproj on first call with caching afterward, automatic exaggeration selection when exaggeration <= 0, screen labeling, and the returned comparability block. However, it does not state whether the tool mutates scene state, requires specific data to already be loaded, or has side effects beyond computing/displaying results.

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?

The description is dense but front-loaded: the core operation appears first, then runtime behavior, then display behavior. It is three sentences with no filler. The parenthetical technical details add specificity, though they could be trimmed without losing the main message.

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 complex four-parameter tool with no annotations and no output schema, the description is incomplete. It does not define the comparability block, explain the role of common_epoch or colocation_radius_m, describe prerequisites, or mention side effects. An agent would need additional inference to call this tool confidently.

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 for the four parameters. It gives some indirect context for scene_id ('in a scene'), common_epoch ('epoch co-registration'), and colocation_radius_m ('co-locate GLAS shots'), and it explicitly explains exaggeration behavior. But it does not explain common_epoch units, how colocation_radius_m is used, or what values are sensible, leaving significant ambiguity.

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 operation (ITRF2014 + epoch co-registration), the exact resource (both missions in a scene), and the expected output (delta-h statistics and the comparability block). This clearly distinguishes it from siblings like show_photons, add_glas, and ui_coregister. The 'Slice 3' prefix adds pipeline context and does not obscure the core purpose.

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 explains what the tool does but gives no explicit guidance about when to use it versus alternatives. It does not mention that ui_coregister is the UI counterpart, when add_glas might be needed first, or any conditions under which coregister is or is not appropriate. 'Slice 3' weakly implies a pipeline order, but that is not enough to guide tool selection.

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