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

It discloses non-obvious behaviors beyond the annotations: flat cells are -1 rather than nodata, geographic CRS DEMs are refused, and the whitebox extraction dependency is required. The idempotentHint and destrictiveHint are not contradicted.

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 main definition is front-loaded, warnings are clearly separated, and every sentence carries actionable information. It is compact without losing needed context.

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 and annotations covering the safety/idempotence profile, the description covers key edge cases, preconditions, and dependencies. The only notable gap is z_factor param semantics, preventing a perfect score.

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 does map 'GeoTIFF in/out' to dem_path and output_path, but z_factor is completely undocumented in both the schema and the free-text description, leaving its scaling role unexplained.

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 defines the resource and output clearly: 'Aspect from a DEM: downslope azimuth in degrees, 0=north' and 'GeoTIFF in/out'. This distinguishes it from terrain siblings like slope and hillshade, though it lacks an explicit action verb such as 'Computes'.

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 gives concrete usage preconditions: mask FLAT cells before averaging, reproject geographic CRS to projected CRS, and install the whitebox extra. It also points to slope for related CRS behavior, but doesn't explicitly state when to prefer a sibling tool over this one.

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?

Beyond the annotations, the description discloses non-obvious behavior: geographic CRS inputs are reprojected to a UTM zone for the metric operation and back, the decision is recorded in the provenance manifest, and a warnings key flags suspicious valid outcomes. This adds meaningful operational context that annotations alone 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 concise and front-loaded with the core action. Each subsequent sentence adds meaningful detail about reprojection, provenance, or warnings without filler or repetition.

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 structure is already covered. The description sufficiently covers operation scope, distance units, projection handling, provenance, and warnings. Minor gaps such as explicit output_path overwrite behavior are not critical given the idempotent and non-destructive annotations.

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 schema has 0% description coverage, so the tool description must compensate. It clarifies that distance is in meters and that all features are buffered, which adds real value. However, input_path and output_path semantics are left entirely to inference, so the compensation is only partial.

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 and resource: 'Buffer all features by a distance in meters.' It clearly identifies the core operation and distinguishes it functionally from siblings like clip_layer or dissolve_layer, though it does not explicitly name or contrast those sibling tools.

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?

Usage is implied by the title and first sentence: use this when you need to buffer features by a metric distance. There is no explicit guidance about when not to use it or which sibling tool to prefer for related operations, so the guidance is present only by implication.

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?

The description discloses several non-obvious behaviors beyond the annotations: the estimated-UTM fallback for geographic CRS, the risk of planar centroids of degree coordinates being wrong, the verification of output invariants, the caveat about centroids falling outside concave/multi-part features, and refusal of CRS-less inputs. This is rich, honest transparency with no contradiction to the annotations.

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 one-sentence summary is front-loaded, and every subsequent sentence adds a distinct caveat or fact: CRS projection behavior, output verification, centroid-location caveat, and refusal condition. No filler or redundant phrasing.

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 behavioral risks, output guarantees, and input constraints. An output schema exists for return-value structure, and annotations cover idempotence and non-destructiveness. Nothing essential for selecting and correctly invoking this tool is 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?

The schema has 0% description coverage, and the description does not explicitly define input_path or output_path. However, it does add meaning by explaining input CRS requirements, the output CRS behavior, and the refusal condition, which indirectly informs both parameters. Path parameters are also fairly self-descriptive, so the gap is moderate rather than severe.

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 precise, specific statement: 'One point per feature: the geometric centroid, computed in a metric CRS.' It clearly names the operation, the resource (a layer), and the output shape, making the tool's purpose unmistakable even among many geometry 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 operational context: geographic-CRS inputs are handled via an estimated UTM zone, inputs without a CRS are refused, and results are returned in the input CRS. It does not explicitly name alternatives or state when not to use this tool, but the conditions are concrete and actionable.

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?

Beyond the annotations (idempotentHint=true, destructiveHint=false, readOnlyHint=false), the description discloses meaningful behavior: automatic CRS alignment, refusal of inputs without a CRS, and the warnings key with hints about empty results or non-overlapping extents. This gives the agent important runtime expectations. No contradiction with annotations.

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 operation is stated in the first sentence, and the second paragraph efficiently covers warnings and CRS restrictions. Every sentence adds useful information; there is no fluff 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?

Given the simple three-parameter input, the presence of an output schema, and annotations covering idempotency and destructiveness, the description covers the essential caveats: CRS handling, refusal behavior, and warning semantics. Nothing critical appears missing for an agent to invoke and interpret the tool 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 0%, so the description must compensate. It clarifies roles by naming 'a layer' and 'a mask layer', and adds the CRS requirement for inputs. However, it does not directly explain each path parameter or the meaning of output_path, relying on self-explanatory parameter names. Partial compensation only.

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 ('Clip') and resource ('a layer' clipped to 'a mask layer'), making the core action clear. It also adds relevant CRS alignment context. However, it does not explicitly distinguish this tool from sibling spatial operations like overlay_layers or spatial_join, so it stops short of full 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 use case is implied by the name and first sentence: clip when you need to cut a layer to a mask extent. It also states prerequisites (inputs must have a CRS) and warning behavior. But it never explicitly says when to use this tool versus alternatives, nor lists exclusions or alternatives.

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?

Beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false), the description discloses substantial behavior: output is re-read and verified for feature count and CRS, specific conversions are refused, and invalid geometry is repaired deterministically with a 'repairs' key. This gives the agent a precise model of side effects and outcomes.

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?

Three sentences cover purpose, target-selection, verification, refusals, and repair behavior with no filler. The most important defining behavior is front-loaded, and every sentence adds operational value.

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 return value is covered structurally. The description covers key edge cases and verification behavior that an agent needs to invoke the tool correctly. It falls slightly short of a 5 by not explicitly stating supported input formats or format-specific limitations beyond the two refusals.

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 carries the burden. It adds essential meaning to output_path by stating that the target format is chosen by its extension and enumerates supported formats, but it gives no details about input_path formats or whether they are auto-detected. The parameter names are self-explanatory, but some explicit input semantics are 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 opens with a specific verb ('Convert') and resource ('vector dataset'), and immediately identifies the target-selection mechanism (output extension). It clearly distinguishes this from sibling geoprocessing tools like reproject_layer or buffer_layer by focusing purely on format conversion.

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 when to use the tool via the extension-driven target and provides concrete exclusions: shapefile and non-WGS84 GeoJSON conversions are refused, with 'reproject first' implicitly pointing to reproject_layer. It does not explicitly name reproject_layer as the alternative, but the context is clear enough.

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?

Annotations already mark the tool as read-only and idempotent, so the description adds extra behavioral context: per-layer description for containers, the refusal of operations on unchosen layers, the [raster] extra requirement, and the distinction between nodata and masked statistics. No contradiction exists.

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 longer than average but well-structured with clear vector/raster sections and front-loaded purpose. Each sentence adds useful behavior or usage context, though it could be tightened without losing value.

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?

Given the tool's complexity and the presence of an output schema, the description covers the important edge cases: multi-layer containers, raster-specific requirements, nodata handling, and when to extract a layer first. It is complete enough for an agent to decide when and how to invoke 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 0%, so the description must compensate, but it never explicitly names or describes the single required parameter. It implicitly refers to a 'dataset' and uses 'path' in the run_sql example, yet an agent still lacks clear semantics about the expected argument format, type, or identifier.

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: 'Inspect a dataset, vector or raster, before analysing it.' It clearly distinguishes the tool's scope from siblings by detailing vector, raster, and multi-layer container behavior, so an agent can tell it apart from related GIS tools.

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 explicitly says to call this tool first on any uninspected dataset and warns that silent GIS errors often stem from wrong assumptions. It also provides a concrete follow-up action for multi-layer containers, naming run_sql with an example query, which gives strong when-to-use and when-to-do-something-else guidance.

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?

The description goes well beyond the annotations by disclosing that the aggfunc choice is recorded in the manifest, that features with a null by key are dropped and counted, and that the output feature count is verified against distinct keys so a wrong grouping fails loudly. These failure-mode details are not available elsewhere and do not contradict the annotations.

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 front-loaded with the core operation and every subsequent sentence adds a concrete behavioral caveat: manifest recording, null dropping, and fail-loud verification. There is no filler, redundancy, or wasted 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?

Together with the provided annotations and output schema, the description covers parameter semantics, null behavior, aggregation defaults, and failure mode, which is enough for an agent to select and invoke the tool correctly. Missing details are either schema-present or non-essential 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 carry the burden. It does this well by explaining the two non-obvious parameters: `by` as the grouping value with null meaning one feature in all, and `aggfunc` as an enumerated aggregation with 'first' as the default. `input_path` and `output_path` are left to their self-explanatory names, which is acceptable but not fully elaborated.

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: 'Merge features into one geometry per value of `by`' and also specifies the all-features fallback. This clearly distinguishes dissolve_layer from sibling tools like explode_layer and merge_layers even without naming them.

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 communicates that this is the dissolve-by-attribute operation and clarifies when a null grouping key dissolves all features into one. However, it does not explicitly name alternatives or state when not to use this tool, so usage guidance is implied rather than direct.

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?

The description adds substantial behavior beyond the annotations: invalid plans run nothing, steps execute in order, execution stops at the first failing step, outputs already produced stay on disk, every step writes a provenance manifest, and a plan-level manifest records the plan sha256 and per-step outcomes. It also discloses the step_warnings signal for suspicious results. This is rich, non-obvious behavioral context.

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 well-organized, front-loading the core purpose before explaining execution behavior, failure semantics, and warnings. It is longer than a minimal description, but the length is justified by the complexity of execution. The only minor redundancy is reiterating 'validate first, then execute' after the opening sentence already says 'Validate, then execute.'

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 multi-step execution tool, the description covers the essential operating envelope: validation, ordering, failure handling, provenance manifests, and the step_warnings caveat. It also notes that outputs persist after partial failure, which is critical for an agent reasoning about side effects. With an output schema present, the description is complete enough for correct invocation and interpretation.

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?

Although the top-level plan parameter has no description in the schema, the description compensates by explaining key semantics: steps run in order, '$step_id' references resolve to earlier step outputs, and manifests are tied to the last output. It also cross-references validate_plan for the exact plan format. The nested schema definitions cover the structural details, so the description adds meaningful semantic value without needing to restate every 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: 'Validate, then execute a geoprocessing plan step by step.' It clearly distinguishes this from validate_plan by stating that execution re-validates first and that the plan format matches validate_plan. The resource and behavior 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?

The description gives clear context on when execution happens: only after re-validation, and only valid plans run anything. It also points to validate_plan with 'Same plan format as validate_plan — validate first, then execute.' However, it does not explicitly say when to prefer this over run_operation or when not to use it, so exclusions are missing.

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?

Beyond the annotations, the description adds meaningful behavioral details: attributes are copied to each output feature, output feature count is verified against the pre-run part count so lost parts fail loudly, and inputs without a CRS are refused. These constraints and failure semantics are not visible in the schema or annotations and materially help an agent anticipate tool behavior.

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 three sentences with no filler. The main action is front-loaded in the first sentence, and each subsequent sentence adds a distinct piece of information: attribute handling, failure verification, and CRS requirement. Nothing is repetitive or tangential.

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?

Given the presence of an output schema and meaningful annotations, the description covers the core behavior, the output semantics, and key operational constraints. An agent has enough information to select this tool and understand the important failure and requirement conditions without needing to inspect additional resources.

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 missing parameter documentation. It adds some useful semantics: 'Inputs without a CRS are refused' constrains input_path, and 'attributes copied' hints at output behavior. However, it does not explicitly clarify what input_path and output_path should contain, their supported formats, or the relationship between them, leaving part of the burden on parameter names.

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 ('Split') and a precise resource ('multi-part geometries into one feature per part'), with a note that attributes are copied. This clearly conveys the operation and distinguishes it from sibling tools like dissolve_layer, merge_layers, or centroid_layer, which perform different geometry transformations.

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 implies when to use the tool: when multi-part geometries need to be exploded into single-part features. However, it does not explicitly state when not to use it, mention prerequisites beyond CRS, or name alternative sibling tools for comparison. The usage guidance is functional but not explicit about exclusions.

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?

Annotations already mark it as non-read-only, non-destructive, and idempotent. The description adds valuable algorithmic behavior (depressions are filled first) and an environment requirement (whitebox extra), which would not be discoverable from annotations or schema. No contradiction with annotations.

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, front-loads the core operation, and uses linne breaks to separate optional parameter guidance. No redundant or filler sentences.

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 four-parameter raster tool with an output schema and annotations, the description conveys the algorithm, both optional parameters, and a hard dependency. It might not enumerate edge cases or precise path requirements, but nothing essential to selecting or invoking the tool is 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%, but the description compensates by defining out_type values ('cells' vs 'sca') and log_transform's purpose. The opening 'GeoTIFF in/out' clarifies dem_path and output_path roles. It doesn't add path-format details, but the parameter names plus these explanations are sufficient.

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 names the exact algorithm ('D8 flow accumulation'), the input ('a DEM'), and the I/O format ('GeoTIFF in/out'). This is enough to distinguish it from sibling terrain tools like slope, hillshade, or watershed. The added 'Depressions are filled first' further specifies the computation.

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: it is for deriving upslope accumulation from a DEM and even notes a dependency prerequisite (whitebox extra). It does not explicitly name alternative tools or state when not to use it, so the agent must infer routing from the tool name and siblings. Overall the context is clear enough, but exclusions/alternatives are absent.

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?

Annotations already declare readOnlyHint, openWorldHint=false, and idempotentHint, covering safety. The description adds the useful scoping phrase 'full lineage manifest', but it does not disclose edge-case behavior such as invalid paths or the completeness of lineage traversal. No contradiction with annotations.

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 a single sentence with no filler, action first, and a concrete object. Every word contributes to telling the agent what the tool does.

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 one-parameter read-only tool with an output schema and strong annotations, the description is nearly complete. The only notable gap is explicit parameter documentation, which is already reflected in the parameter_semantics score.

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 description does not explicitly explain output_path. It only implies via 'MapSmith output dataset' that the parameter is a path to such a dataset. For a low-coverage schema, the description should compensate more directly.

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 ('Return') and a precise object ('full lineage manifest of a MapSmith output dataset'). This clearly distinguishes it from the sibling tools, which are all spatial processing or server utilities.

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 makes clear that the tool is for retrieving provenance of a MapSmith output dataset, so the context of use is implied. However, it does not explicitly state when to prefer this tool over alternatives or mention exclusions.

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?

The description goes well beyond the annotations by disclosing output value scaling (0-32767), the meaning and defaults of azimuth and altitude, rejection of DEMs without a CRS, and the dependency on the [whitebox] extra. This gives the agent a clear picture of what the operation does and how it behaves.

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, front-loaded with the core transformation, and includes only essential behavior, parameters, and constraints. Every sentence earns its place with no redundancy or filler.

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 input/output format, value scaling, key parameter defaults, a validation constraint, and a runtime dependency. It is nearly complete, but omits any explanation of z_factor and does not state whether existing output files are overwritten; these are minor given the output schema and annotations.

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?

With 0% schema description coverage, the description compensates for azimuth and altitude by explaining their units, defaults, and interpretation, and implies that dem_path/output_path are GeoTIFF inputs/outputs. However, z_factor is not described at all, leaving a meaningful parameter semantically unexplained.

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 clearly identifies the tool's purpose: generating shaded relief from a DEM, with a specific GeoTIFF-to-GeoTIFF transformation. This is distinct from sibling terrain tools like slope, aspect, and flow_accumulation because it names the output product ('shaded relief') and the processing model ('GeoTIFF in, GeoTIFF out').

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 useful usage conditions: DEMs must have a CRS, and the [whitebox] extra is required. However, it does not explicitly state when to choose hillshade over alternative terrain-analysis siblings (e.g., slope or aspect), so the usage guidance 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?

Beyond readOnlyHint/idempotentHint, it discloses that ranking is measured and limited, that order_is_weak can occur, and exactly what each status value (choose, unsure, none_apply) means and what the agent should do. It also explains engine behavior including fallback and determinism. No contradiction with annotations.

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 long, but the length is earned: it uses bolded facet names, a table of measured effects, and status-based sections that map to response handling. Some statistical passages could be tightened, but the structure front-loads the core guidance and separates it clearly.

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 tool with no parameter descriptions and complex response semantics, this is complete: it explains all output statuses, how to interpret order_is_weak, what detail=True returns, how engine affects ranking, and how to recover from none_apply. The agent has enough context to use it correctly without opening schemas.

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?

With 0% schema description coverage, the description carries the full burden and succeeds: it defines input_kind, produces, category, projected, dataset_inputs, query, detail, and engine with concrete allowed values and intended meaning. Only limit is not explicitly described, but the practical behavior of the returned set is covered thoroughly.

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 line 'Find the operation you need' names a specific verb and resource, and the description clarifies it is a catalog-search/ranking tool rather than a GIS operation, distinguishing it from siblings like run_operation or buffer_layer. It also defines its exact scope: searching/filtering the operation catalog by facets and query.

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 explicit when-to-use guidance: fill facets when known, use detail=True on the exact operation name before calling an unfamiliar tool, use empty query to list everything, and respond differently per status (choose/unsure/none_apply). It even tells the agent when not to continue ('MapSmith probably does not do this — say so rather than running a neighbour').

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?

Beyond the annotations, the description discloses important non-obvious behaviors: invalid geometry is repaired before measuring, repairs are recorded, planar results are compared with ground area and may return a warnings ratio, and planar is refused on geographic CRS. Nothing contradicts the idempotentHint or other annotations.

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 front-loaded with the core purpose and units, then provides method details and edge-case behavior in a compact, dense structure. Every sentence adds meaningful information with no filler or repetition.

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 tool with no parameter description coverage, the description covers operation semantics, units, method trade-offs, refusal behavior, repair behavior, and warning output. An agent has enough context to select parameters and interpret results, especially since an output schema exists.

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?

With 0% schema description coverage, the description carries the burden. It richly explains the `method` parameter including defaults, refusal conditions, and unit conversion behavior, and clarifies that area is written to a named column. It does not explicitly detail `input_path`, `output_path`, or the default `area_column` name, though these are inferable from context and schema defaults.

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 the exact action: compute area per feature in square metres, write it to a named column, and include a total in the result. This clearly distinguishes it from sibling geometry operations like buffer, centroid, or dissolve.

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 strong method-selection guidance: geodesic as the default for ground area, planar for layer-CRS area, and explicitly refuses planar on geographic CRS. It does not name an alternative sibling tool, but area measurement is unique among the listed siblings, so the internal method guidance is sufficient.

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?

The description goes well beyond annotations by disclosing reprojection behavior, null-filling of missing columns, provenance manifest recording, feature count verification, and refusal of inputs without a CRS. It also warns about the silent-error risk of measured-looking absent data. No contradiction with annotations exists.

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 purpose is front-loaded in the first sentence, and every following sentence adds a distinct, important behavioral fact. The extended caveats about null-filling and CRS handling are necessary for correct use, not filler.

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 moderately complex data-merging operation with only two parameters and an output schema available, the description covers the key conditions, failure modes, and relationships to sibling tools. Nothing essential is missing for an agent to invoke 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?

The schema provides only names and types, so the description carries the semantic burden. It meaningfully clarifies that input_paths expects two or more layers and that the operation writes to output_path, while also explaining processing details like CRS reprojection. It doesn't explicitly bind each parameter name, but given only two parameters that map naturally, this is a strong-enough compensation for 0% schema coverage.

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 action: 'Append two or more layers into one', clarifies schema union and attribute alignment, and explicitly distinguishes itself from a geometric union. This makes the tool's purpose unmistakable and separates it from siblings like dissolve_layer.

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 provides clear usage context: layers are reprojected to the first layer's CRS, inputs without CRS are refused, and it explicitly tells the agent to use dissolve_layer for geometric merging instead. This is exemplary when-to-use versus when-not-to-use guidance.

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?

Annotations already signal idempotence and non-destructiveness; the description adds the critical CRS safety behavior—estimated UTM measurement for geographic inputs, return in input CRS, and prevention of the classic degrees error—plus the warnings entry on emptied results. This is exactly the behavioral context an agent needs.

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 core operation is front-loaded in the first sentence, followed by two high-value caveats (CRS handling and max_distance behavior). No filler or repetition; every sentence earns its place.

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 join tool with an output schema and safety annotations, this is complete: it explains the operation, the main failure mode it prevents, the distance filter, and the warning behavior. Nothing material is missing for an agent to call it successfully.

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?

With 0% schema description coverage, the description must carry parameter meaning, and it does for distance_column (IN METERS, named) and max_distance_meters (drops pairs beyond threshold). left_path, right_path, and output_path are sufficiently clear from their names, though the description does not elaborate on them.

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 operation: attach each feature's nearest neighbour from another layer and add a named distance column. The 'nearest neighbour' and 'distance in meters' wording sets it apart from the generic spatial_join sibling.

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 implies this is the tool for nearest-neighbour joins and describes conditions under which behavior changes (geographic CRS, max_distance_meters), but it never explicitly says when to use it instead of spatial_join or other siblings.

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?

The description discloses important behaviors beyond the annotations: reprojection and provenance recording, dropping lower-dimensional pieces, refusing inputs without CRS, and reporting empty results with warnings. This is exactly the kind of contextual side-effect information an agent needs, and it does not contradict the annotations.

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 front-loaded with the core operation and each subsequent sentence adds a distinct behavioral detail without redundancy or fluff. It is compact yet information-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?

For a 4-parameter tool with an output schema, the description covers the operation variants, CRS mismatch behavior, geometric dimension handling, validation failures, and empty-result warnings. Nothing essential for selecting or invoking the tool is 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 compensate, and it does: it explains the 'how' values and clarifies the roles of input and overlay layers. It doesn't explicitly document the path parameters, but their names are self-explanatory and the behavior around the overlay result is conveyed.

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 operation ('Set-theoretic overlay of two layers') and enumerates the allowed variants, so an agent immediately knows what the tool does. This distinguishes it from siblings like clip_layer or merge_layers because it names the exact set-theoretic semantics.

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 for when the tool applies, including CRS handling and edge cases, but it does not explicitly name alternatives or say when not to use it. The set-theoretic operation definition is enough to imply the main use case.

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?

Beyond the readOnly/idempotent annotations, the description discloses projection to EPSG:4326, simplified geometry, capped feature counts, provenance summaries, and verification status. It also states that datasets of record stay on disk, reinforcing the read-only characterization. No contradiction with annotations.

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 front-loaded with the core purpose and structured into input, rendering behavior, safety, and fallback. Every sentence adds meaningful eligibility or behavioral context, with no redundant or filler content.

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 input types, projection, simplification, feature limits, layer-card content, safety, and the no-MCP-Apps fallback. The only meaningful omission is explicit semantics for max_features, which is minor because the parameter has a sensible default and the cap is described behaviorally.

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 description thoroughly explains the paths parameter as MapSmith outputs/source datasets, vector or GeoTIFF. However, max_features is never explicitly named; 'capped feature counts sized to fit client limits' only indirectly hints at it, and schema description coverage is 0%, so the agent gets no direct documentation of how to control the cap.

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 action ('Show datasets') and a concrete resource ('interactive in-chat map panel'), and clarifies it is a read-only preview. It effectively distinguishes this tool from transformation/analysis siblings like buffer_layer or run_sql without needing to inspect schemas.

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 gives clear eligibility guidance: paths of MapSmith outputs or source datasets, vector or GeoTIFF, plus fallback behavior on clients without MCP Apps support. However, it does not explicitly name sibling alternatives or state when not to use this tool, so it falls short of full routing guidance.

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?

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.

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

Beyond the annotations, the description discloses that arguments are validated before execution, errors use stable codes, validation covers unknown operations and path safety, and execution follows the same path as execute_plan. This adds meaningful behavioral context. No contradiction with the annotations is apparent; the generic 'any operation' framing does not directly conflict with idempotentHint or destructiveHint.

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 main purpose is front-loaded in the first sentence. The later paragraphs explain the catalog growth rationale and validation behavior, which are useful but somewhat expansive; still, each part carries information an agent needs to use a generic dispatch tool safely.

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 generic operation runner with an open-ended arguments object, the description is complete: it names the discovery tool, tells how to get parameter details, explains error behavior, and connects execution semantics to execute_plan. The output schema exists, so return values do not need explanation here, and annotations already cover the idempotency/safety profile.

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 schema provides 0% description coverage and arguments is an opaque object, but the description compensates by explaining that parameters are validated against the catalog and that list_operations with detail=true returns exact parameters and worked examples. It gives the agent a concrete path to resolve parameter semantics without attempting to enumerate a dynamic catalog.

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 'Run ANY catalog operation by name', which is a specific verb plus resource and immediately clarifies this is the generic catch-all runner. It explicitly distinguishes itself from the dedicated siblings by explaining that most operations have no tool of their own and that list_operations is the discovery mechanism.

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 clearly says to discover operations with list_operations (using detail=true) and then call them here, and it frames the listed tools as the 'handful an agent reaches for constantly.' It does not explicitly state 'use a dedicated sibling when one exists,' but the context strongly implies this is the fallback for the long tail of operations.

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?

Beyond the destructiveHint annotation, the description discloses preview vs. materialization behavior and the creation of a provenance manifest. It doesn't mention overwrite semantics or failure behavior, but annotations already flag destructive potential.

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 with no filler. The first sentence establishes the core purpose and syntax focus; the second efficiently distinguishes the two execution modes. Well 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?

The description covers both parameters, preview limits, output format, and provenance, which is strong for a SQL runner. Minor omissions like error handling and exact path constraints are acceptable given the annotations and output 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?

Schema description coverage is 0%, so the description carries the burden for parameters. It meaningfully explains both query (spatial SQL dialect/functions) and output_path (preview vs. GeoParquet materialization), going beyond raw names.

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 clearly states the tool runs spatial SQL using DuckDB dialect with ST_* functions and file-reading helpers, giving a specific verb and resource. It doesn't explicitly contrast with sibling tools like run_operation, but the raw SQL scope is evident.

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 provides clear conditional usage: omit output_path for preview rows or provide a .parquet output_path for full materialization. It gives actionable context but does not mention alternatives or exclusions.

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?

Annotations already flag readOnlyHint and idempotentHint, and the description adds that the result contains version, licensing, and engine availability. This adds useful context about what the endpoint exposes and is fully consistent with the annotations.

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 concise sentence carries the full meaning with no filler and leads directly with the tool's purpose. Every word earns its place.

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 read-only info endpoint with an output schema and readOnly/idempotent annotations, the description covers all necessary decision points. No missing context could prevent an agent from safely invoking it.

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 schema coverage is 100%, so there are no parameter semantics that the description needs to add. The description correctly focuses on the returned information rather than arguments.

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 the exact resource (MapSmith server) and the specific facts returned: version, licensing, and available engines. It is clearly distinguishable from the sibling GIS data tools, which all perform spatial operations rather than expose server metadata.

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?

Although it doesn't explicitly name alternatives, the description makes the intended use obvious: call this to inspect server capabilities or licensing status. No exclusions or alternative routing are needed because it is effectively the only metadata/information tool among the siblings.

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?

Beyond the annotations, the description discloses significant behavioral detail: drift is measured in the manifest, feature count is verified unchanged, vertex counts before/after are included, topology is preserved, and non-CRS inputs are refused. These details materially affect how an agent interprets results and plans calls.

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 yet information-dense. Every sentence adds a necessary behavioral or CRS-related detail, and the primary purpose is stated first. No filler or redundant restatement of the tool name appears.

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 simplification tool with three parameters and an output schema, the description covers the algorithm, topology preservation, CRS handling, tolerance units, output measurements, feature-count verification, and refusal conditions. Nothing essential for correct invocation or interpretation is 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 coverage is 0%, so the description carries the parameter-semantics burden. It thoroughly explains tolerance behavior across geographic and projected CRS, which is essential for correctly using tolerance_meters. input_path and output_path remain self-explanatory, so no further description is needed.

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: 'Simplify geometries', and further specifies the algorithm (Douglas-Peucker) and a key invariant (topology preserved). This clearly differentiates it from sibling tools like buffer_layer, explode_layer, or dissolve_layer.

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 operational context, especially around CRS handling: geographic inputs are simplified in estimated UTM and returned in the input CRS, projected inputs use CRS units, and missing CRS causes refusal. It does not explicitly name alternatives or state when not to use this tool, but the guidance is sufficient for a geometry-simplification operation.

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?

The description goes well beyond annotations by disclosing supported units, refusal of geographic CRS with a rationale about plausible but wrong values, provenance recording, and the whitebox dependency. These traits are not visible in the annotations or schema.

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 purpose is front-loaded in the first sentence, and the remaining sentences contain only high-value caveats and dependencies. There is 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?

The description covers purpose, units, CRS restriction, provenance, and dependency, and an output schema exists for return details. The only notable gap is the unexplained z_factor parameter, which has a default and is likely optional for typical calls.

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?

With 0% schema property descriptions, the description must carry parameter meaning. It explains units values/default and implies dem_path/output_path roles via the GeoTIFF in/out wording, but z_factor remains undefined, leaving one of four parameters semantically opaque.

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 operation (slope gradient from a DEM) with clear input/output format (GeoTIFF in, GeoTIFF out). This makes it easy to distinguish from sibling terrain tools like hillshade or aspect.

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 gives clear usage context and crucial preconditions: geographic CRS DEMs are refused and must be reprojected, and the whitebox extra is required. It doesn't name alternative tools, but it provides enough guidance on when to invoke slope correctly.

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?

The description adds rich behavioral details beyond annotations: engine routing precedence, a warnings key for empty or non-overlapping joins, and refusal of inputs lacking a CRS. These are non-obvious behaviors an agent could not infer from the schema or annotations, and there is no contradiction with the idempotentHint.

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 three tight sentences with no filler. The core operation is front-loaded, followed by engine routing and key warnings, with every sentence contributing new information.

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 5-parameter join tool, the description covers predicate choices, engine selection strategy, warning behavior, and a failure condition. An output schema is provided separately, so return values need not be described here. The definition is complete enough for an agent to invoke the tool 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 0%, so the description carries the burden. It explains engine values and predicate options in some detail, while left_path, right_path, and output_path are left to name inference. These names are self-explanatory, so the gap is minor.

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 'Join by spatial predicate (intersects/within/contains)' names the action, resource, and allowed predicates, which clearly distinguishes it from sibling tools like nearest_join and overlay_layers. An agent can immediately understand what operation is performed.

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 concrete guidance on engine selection, explaining when SedonaDB, DuckDB, or GeoPandas is preferred. It also states a hard precondition: inputs without a CRS are refused. It does not explicitly contrast this tool with nearest_join, but the predicate-based wording implies the appropriate use case.

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?

Beyond the readOnlyHint and idempotentHint annotations, the description details exactly what validation covers: operation existence, argument completeness/typing, backward reference resolution, file existence, output collision checks, and CRS flow. It also states the return shape (errors/warnings/notes plus simulated CRS) and explicitly promises no side effects: 'Nothing is executed and nothing is written.'

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 longer than average, but it earns the length by covering validation semantics, plan structure, reference syntax, and return behavior. The example plan is helpful. A small amount of redundancy exists ('BEFORE running anything' vs. 'Nothing is executed'), but overall the structure is logical and 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?

For a validation tool with one complex nested parameter and no need to document return values thanks to the output schema, this description is complete. It tells the agent what the input must look like, what checks will be performed, what the result contains, and that the tool has no side effects. Nothing essential is 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?

The single `plan` parameter is thoroughly explained: steps in execution order, unique ids, operation names from list_operations, and the crucial `$step_id` reference syntax for consuming earlier outputs. The description even provides a concrete example plan. This compensates fully for the 0% schema description coverage at the top level.

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 precise verb and object: 'Statically validate a multi-step geoprocessing plan BEFORE running anything.' It clearly distinguishes this from execution-oriented siblings like execute_plan and run_operation, and the details about validation checks reinforce what the tool is for.

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 makes the usage context explicit: validate before executing, and use operation names from list_operations. It doesn't explicitly name execute_plan as the follow-up tool, but the 'BEFORE running anything' framing and the contrast with execution-oriented sibling tools give an agent clear guidance on when this tool applies.

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?

Beyond annotations, the description discloses the 1-based ID ordering, nodata behavior for non-draining cells, automatic CRS alignment with a recorded decision, and the whitebox dependency. These are meaningful behavioral details an agent would not otherwise know.

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?

Three sentences, each earning its place: purpose, output semantics, and dependency/CRS behavior. The most important information is front-loaded in the first sentence.

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 three-parameter raster-processing tool, this description covers purpose, output format, ID semantics, nodata behavior, CRS handling, and required extra. Nothing essential is missing for an agent to select and invoke 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?

The input schema has no parameter descriptions, so the description must compensate. It maps dem_path to DEM, pour_points_path to pour points, and output_path to the basin raster GeoTIFF, and adds CRS alignment context. This is sufficient for correct invocation, though explicit per-parameter naming is absent.

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 (watershed delineation), states the inputs (DEM, pour points), and the output (basin raster GeoTIFF). This clearly differentiates it from sibling tools like flow_accumulation or hillshade.

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 implies usage clearly: use when you need watersheds from a DEM and pour points. It does not explicitly name alternatives or exclusion cases, but the specialized input/output pattern gives enough context for an agent to select 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?

The description discloses important behaviors beyond the annotations: automatic CRS alignment with provenance recording, refusal of zones without CRS, result repair/warning keys, and the [raster] extra dependency. This gives an agent a realistic model of side effects and failure modes.

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 well-organized: core purpose first, then stats options, then edge-case behavior. Every sentence adds operational value without 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?

For a raster/vector analysis tool with an output schema available, the description covers what the tool does, accepted stats, defaults, CRS handling, failure conditions, and installation prerequisite. Nothing essential is missing for a knowledgeable agent to invoke it safely.

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?

With 0% schema description coverage, the description compensates meaningfully by enumerating the valid stats values and the default set. The three path parameters are self-explanatory from the domain language, though the description does not provide file-format or coercion details for them.

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 clearly states the operation: computing raster statistics within vector zones, with the distinctive detail of exact fractional pixel coverage. It differentiates itself from sibling raster tools like hillshade or slope by focusing on zonal aggregation rather than surface derivation.

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 context of use is clear: summarizing a raster by vector zones, with specifics about how zones are handled. It does not explicitly name alternative tools or when-not-to-use conditions, but the raster/zone framing sufficiently implies the intended scenario.

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