reproject_layer

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

The description adds substantial behavior beyond the annotations: geometry passes through unchanged, invalid inputs yield invalid outputs, broken geometry is repaired deterministically, repairs are reported in a `repairs` key, and geometry type may change. This is rich, decision-relevant context that the annotations do not provide.

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 compact and front-loaded: the core action and CRS examples appear first, followed by essential warnings. Every sentence earns its place, and the warning about CRS-less inputs is clearly separated without 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?

The description covers the critical operational caveats: CRS requirement, pass-through geometry, deterministic repair, and the `repairs` key. Since an output schema exists, return-value documentation is not the description's burden. Minor gaps remain around path parameter details, but the tool is usable as described.

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. It adds meaning for `target_crs` by giving concrete examples and clarifies that the input layer must already have a CRS. However, it does not explain `input_path` or `output_path` semantics beyond their names, such as expected formats, overwrite behavior, or path types.

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 and resource: 'Reproject a layer to a target CRS'. It further clarifies acceptable CRS forms ('EPSG:32632' or a WKT string), making the tool's purpose concrete and distinguishing it from generic format-conversion or geometry-operation siblings.

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 gives clear context: use this tool to reproject a layer to a specified target CRS, and it explicitly states when not to use it by refusing inputs without a CRS. It does not name sibling alternatives, so it stops short of full 'use X instead' routing, but the usage boundary is clear.

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