Skip to main content
Glama

area_by_stratum

Read-onlyIdempotent

Calculate total and per-stratum polygon area in an equal-area CRS for carbon project audits. Dissolves overlapping polygons so ground is counted once, reporting overlaps within and between strata.

Instructions

Area in hectares of a polygon layer, in total and per stratum, measured in an equal-area CRS. Overlapping polygons are dissolved so ground is never counted twice, and the overlap inside each stratum and between strata is reported.

Args: path: Polygon layer (project area, strata, eligible area...). stratum_field: Attribute holding the stratum or class (optional). layer: Layer name inside a multi-layer file (optional). crs: Projected CRS to measure in, e.g. "EPSG:32720". If omitted, a local Lambert Azimuthal Equal Area projection centred on the data is used.

Input Schema

NameRequiredDescriptionDefault
crsNo
pathYes
layerNo
stratum_fieldNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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.