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

While annotations cover safety, the description adds critical operational context, such as the guarantee that 'ground is never counted twice' due to dissolving overlaps. This explains the specific nature of the calculation process beyond simple execution hints.

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 efficiently structured, dedicating the first sentence to the primary value proposition. It uses the second sentence to explain the core processing behavior without unnecessary jargon.

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 complexity of GIS area calculations and CRS handling, the definition is highly complete regarding how the tool handles overlap and measurement. This context is crucial for an AI agent to select this over simpler area calculation tools.

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?

Since schema coverage is 0%, the description must carry the weight of semantics. It clarifies that 'path' is a polygon layer and explains the critical default behavior of the 'crs' parameter (local Lambert Azimuthal Equal Area projection).

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 specific resource (a polygon layer) and the result (Area in hectares), specifying that the calculation includes reporting per stratum. It distinguishes itself by detailing the use of an equal-area CRS and the process of dissolving overlapping polygons.

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 focuses entirely on the technical mechanics of the tool rather than providing guidance on when to use it versus alternatives. It does not compare the tool's functionality to siblings like 'check_overlap' or 'layer_info.'

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 establish read-only, idempotent, non-destructive, closed-world behavior, so the description's burden is small; it still adds real value by disclosing that 0 ha is reported explicitly, that results are measured in a projected equal-area CRS by default, and that pair listing is capped. It does not cover failure behavior (e.g. non-overlapping extents, unprojectable data).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence front-loads the purpose and outputs, and the Args block is scannable with one line per parameter; nothing is padding. Minor redundancy in restating schema defaults (20, null) inside the Args lines.

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 an eight-parameter spatial tool with zero schema descriptions, the definition supplies purpose, use-case examples, all parameter meanings, and default projection behavior, while the output schema covers return values. Remaining gaps are secondary details like CRS format expectations and behavior on degenerate or empty geometries.

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 schema description coverage at 0%, the description carries the full burden and does so through an Args block covering all eight parameters, including non-obvious semantics such as id_field_a naming features of layer A, layer_a selecting a layer inside a multi-layer file, and crs defaulting to an equal-area projection. It stops short of specifying accepted CRS syntax or what the max_pairs cutoff does to reported totals.

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 computation on a specific resource pair ('Overlap between two polygon layers') and enumerates the outputs (hectares, percentage of each layer, largest overlapping feature pairs). It is unambiguous and clearly distinct from siblings like area_by_stratum or compare_declared_area, but it never explicitly differentiates itself from them, leaving that inference to the agent.

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 parenthetical examples ('project area vs. protected areas, other registered projects, leakage belt or reference region') convey the intended contexts, which is genuinely useful, but they are examples of layer types rather than explicit use/when-not-use guidance. No alternative tool is named and no prerequisite or exclusion is stated.

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, idempotentHint and destructiveHint=false, so safety is covered. The description adds genuine behavioral context beyond that: the tolerance threshold concept, the default of 1.0, and the equal-area default CRS used for measurement. It doesn't say what a 'flag' looks like in the response, but the output schema carries that.

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 sentence is front-loaded and the remaining content is a tight Args block with no filler. The docstring formatting is slightly mechanical, but every line carries information an agent needs.

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 six-parameter tool with a nested object argument and an output schema, this covers nearly everything needed to invoke it correctly, including the CRS/measurement concern. The main gap is that it doesn't say whether tolerance violations cause an error or are simply reported, though the output schema likely answers that.

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 full burden, and it does: it explains path, the declared_ha keying convention with a concrete example ({"total": 8000, "dense_forest": 5200}), when stratum_field is required, what layer means for multi-layer files, and the meaning/default of crs and tolerance_pct. This is meaning an agent cannot get from the bare schema titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: compare areas declared in a project document (PD, monitoring report) against areas calculated from the layer, and flag differences above a tolerance. That is far more than a restatement of the name. It does not explicitly distinguish itself from siblings such as area_by_stratum, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The context of use is implied by 'declared in a project document' versus 'calculated from the layer', which tells an agent this is a QA/validation step. However, there is no explicit when-to-use, no prerequisites (e.g. run area_by_stratum first), and no named 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 declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral rule beyond that: blank text counts as missing. However it says nothing about how nulls vs empty strings vs whitespace are treated further, or what happens for a nonexistent field name. Given the read-only annotations cover the risky dimensions, a 3 is fair.

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 with the key rule (blank text equals missing) in parentheses, followed by a compact Args list. The Args list partially duplicates schema titles, but with 0% schema description coverage that duplication is earning 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?

An output schema exists, so the return shape does not need explaining, and the description already states what the result measures (filled, missing, distinct counts). For a 3-parameter read-only inspection tool this is close to complete; only edge-case behavior for invalid paths or fields is unaddressed.

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 parameters, and it does explain all three: path is the vector layer to inspect, fields is an optional subset defaulting to all fields, and layer selects a layer inside a multi-layer file. It does not specify accepted path formats or what error surfaces for an invalid field name, which keeps it below a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the specific measurement (filled/missing values per field plus distinct-value counts) and its scope (attributes of a vector layer), which clearly separates it from siblings like layer_info or area_by_stratum. It is not a bare restatement of the name 'data_completeness' because it enumerates exactly what is counted.

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 purpose (a data-quality check on a layer's attributes) but there is no explicit when-to-use or when-not-to-use guidance, and no pointer to the sibling tools such as layer_info that also describe a layer. An agent can infer the context but must decide on its own.

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 read-only, idempotent, non-destructive behavior, so the description is not burdened with the safety profile. It instead adds substantive traits the annotations cannot convey: geodesic pixel areas for degree-based rasters and the coverage fraction that prevents a partial tile from being misread as 'no loss'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and the key caveat are front-loaded before the Args block, and every line is doing work given the empty schema descriptions. The Args enumeration duplicates parameter names from the schema, but that duplication is justified at 0% coverage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the description still flags the coverage-reporting output as the key safeguard. For a two-required-parameter geospatial tool it covers the essential semantics, missing only edge-case handling for out-of-range years or mismatched CRS.

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 parameter burden, and it does: each of the six parameters gets meaning, including the non-obvious base_year offset (2000 for Hansen GFC) and the optional aoi_layer for multi-layer files. It stops short of specifying path format or how start_year/end_year interact with base_year.

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?

First sentence states a specific verb and resource: forest loss per year inside an AOI computed from a local lossyear raster, with the raster encoding spelled out (1 = 2001 ... 24 = 2024). This is clearly distinct from siblings like area_by_stratum or data_completeness, which do not operate on a loss-year raster.

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 the use case (project area, leakage belt) but never explicitly says when to pick this over data_completeness or compare_declared_area, nor does it state preconditions such as raster/AOI CRS compatibility. Usage is inferable rather than instructed.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the meaningful behavioral detail that the call performs a full scan (invalid geometry detection, per-field null counts) and reports a degrees/CRS check, which primes the agent for what the call inspects. It omits cost hints for very large layers and what happens when a multi-layer file is passed without the layer argument.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose and the "call this first" directive, then a clearly separated Args block. The enumeration of return contents is dense but earns its place by signalling scan depth; only the return-value listing mildly overlaps the existing output schema.

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 two-parameter read-only inspection tool with an output schema, the description covers purpose, sequencing, both parameters, and the scope of what is examined. The remaining ambiguity (layer resolution on multi-layer files, runtime on large inputs) is minor and does not affect 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 carries the full burden and does so: it names supported vector formats for path (GeoPackage, Shapefile, GeoJSON, KML, FlatGeobuf) and explains that layer is the optional layer name inside a multi-layer file such as a GeoPackage. Both parameters gain meaning that the bare schema lacks.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (describe a vector layer) and immediately enumerates the concrete outputs: CRS with a degrees flag, feature count, missing/empty/invalid geometries, geometry types, bounds, and per-field null counts. The siblings are all analysis tools, and the description makes clear this is the metadata/inspection counterpart an agent should run before 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?

"Call this first on every layer" and "before any analysis" give an explicit precondition for invocation, which is exactly what an agent needs for sequencing. It stops short of naming any sibling tools or stating when-not to use it, so it falls just short of the top band.

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, idempotentHint and destructiveHint=false, so safety is covered; the description adds real behavioral context beyond them, notably that distances use the local UTM zone unless a CRS is supplied and that edge_distance_m=0 disables boundary flagging. It also tells the agent what categories of findings are produced, which is not derivable from the annotations. It stops short of describing granularity of results or how findings are keyed, which the output schema presumably covers.

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 outcome-oriented summary before the parameter block, and both parts earn their space. The multi-clause opening sentence is dense but readable, and the per-argument lines are terse; only the redundant 'Layer name inside the X file' phrasing could be tightened.

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 9-parameter geospatial validation tool, the definition covers all required inputs plus the optional ones and explains the distance/CRS behavior. An output schema exists, so return values need not be explained. Only input format expectations (CRS syntax, file type expectations) are missing, a modest gap given the tool's complexity.

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% (only bare titles), so the Args block carries the full documentation burden and does so for all nine parameters, including which are optional and that edge_distance_m defaults to off. The gap is format guidance: it does not say what a CRS string looks like (EPSG code vs WKT) or what file formats plots_path/strata_path accept, which an agent must guess.

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 ('Check monitoring or inventory plots against the strata') and enumerates the exact conditions it detects: plots outside every stratum, mismatched declared stratum, overlapping strata, near-boundary plots, and duplicate coordinates. This is far more specific than a restatement of the name, though it never names or distinguishes itself from siblings such as check_overlap or data_completeness.

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 list of checks performed (a QA/validation pass on plot geometry against a strata layer), so an agent can infer the scenario. However, there is no explicit when-to-use guidance, no exclusion criteria, and no pointer to the sibling tools that might be the better choice (e.g., check_overlap for pure overlap testing).

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