Skip to main content
Glama

stack_stats

Read-only

Measure how much a site changed across its passes, as numbers.

The quantitative counterpart to ``change_composite`` / ``timescan``: those
return a picture of *where* change is, this returns the *how much*. Pass the
STAC URLs of a site's passes (2 or more, any order); they are co-registered
onto one shared grid and reduced to a per-pass statistics series plus a net
baseline-to-latest record — mean/median/spread of each pass, the signed
decibel change against the pass before it, the fraction of ground that moved
past ``change_threshold_db``, and that fraction as an **area in km²**.

Change is always reported in decibels (a ratio of backscatter is a difference
on the log scale). The default ``crs="utm"`` puts the grid in the site's UTM
zone so every cell covers the same ground and the area figures mean
something; pass ``crs="EPSG:4326"`` for a lon/lat grid, and the areas come
back ``None`` rather than wrong. ``extent="intersection"`` (the default)
compares only ground every pass covers; ``"union"`` keeps all of it and
compares per cell where two passes overlap. ``bbox`` (lon/lat
``[min_lon, min_lat, max_lon, max_lat]``) narrows the measurement to a
sub-area, e.g. one facility inside the scene.

``blocks=N`` adds the *where* to the *how much*: the scene is cut into an
N x N grid (6 is a good default; 0, the default, skips it) and the extra
``spatial`` key reports each block's own net change, a compass label and
lon/lat centre to locate it by, and the consecutive pair of passes that
block moved most between — plus ``peak_block`` and an ASCII ``grid_text``
heat-map of the net change. Ask for it whenever the question is *where on
this site* something happened, or when a scene-wide mean looks small but the
picture from ``change_composite`` shows an obvious hot spot: a change
confined to one corner is averaged away scene-wide and stands out per block.

``block_series=True`` (which needs ``blocks``) keeps each block's *whole*
pass-to-pass sequence rather than only its peak interval, so a block that
drifted a little every pass reads differently from one that jumped once and
held. It is the largest payload this tool emits — ``blocks`` × ``blocks`` ×
(passes − 1) records — so ask for it only when the *shape* of the history is
the question, not the size of the change.

``speckle_filter="boxcar"`` or ``"lee"`` averages **speckle** down before
anything is measured. Speckle is not sensor noise: it is the interference
pattern coherent illumination makes on rough ground, and on single-look
imagery it scatters as widely as its own mean — so on a quiet site an
unfiltered per-cell decibel delta is mostly interference rather than change.
``"boxcar"`` averages every window (most variance removed, blind to the edges
it averages across); ``"lee"`` averages only where a window is no more
variable than speckle alone explains, so edges and bright points survive.
Reach for it when the change you are looking for is small, or when the
numbers look noisy against a picture that looks quiet; leave it off when the
question is about *fine* structure, because what it spends is resolution — a
``speckle_window``-cell window (odd, 5 by default) makes each cell report
ground that many cells across. The returned ``caveats`` say so, so a quoted
figure carries the trade with it.

Refuses to mix polarizations (HH and VV are not comparable). **No model is
called** — this is arithmetic over streamed COG overviews, so the numbers are
reproducible and safe to quote. Read the ``caveats`` before interpreting
them: Umbra's open products are not radiometrically calibrated, so a decibel
value is relative to the same ground on another date, and look geometry moves
backscatter too.

Input Schema

NameRequiredDescriptionDefault
crsNoutm
bboxNo
urlsYes
assetNoGEC
blocksNo
extentNointersection
max_sizeNo
block_seriesNo
speckle_filterNo
speckle_windowNo
change_threshold_dbNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only say readOnlyHint=true; the description goes well beyond by declaring no model is called, arithmetic over streamed COG overviews, results reproducible and safe to quote, and by warning that Umbra's open products are not radiometrically calibrated so decibel values are relative. It also discloses payload-size cost for block_series and the resolution trade the caveats record.

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?

Front-loaded with the core purpose and the sibling contrast, then organized by parameter group with clear paragraph boundaries. It is long, and the speckle pedagogy ('it is the interference pattern coherent illumination makes on rough ground') is more explanation than an agent strictly needs, but almost every sentence either sets policy or explains a default.

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

Completeness5/5

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

An output schema exists, so return shapes need not be enumerated, yet the description still names the extra keys (spatial, peak_block, grid_text, caveats) that only appear when specific flags are set — the one thing a schema check would not reveal. For a complex 11-parameter analytics tool with an unsafe-to-misread numeric output, nothing an agent needs to call it correctly is missing.

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?

Schema coverage is 0%, so the description must carry the load; it explains crs (utm vs EPSG:4326 and why areas become None), extent (intersection vs union semantics), bbox format and purpose, blocks (N x N, 0 default, 6 a good default), block_series dependency on blocks, speckle_filter values, speckle_window (odd, 5 default), and change_threshold_db's role. Only asset and max_size go unexplained, which is a minor gap at 11 parameters.

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?

States a precise verb and resource — measure how much a site changed across its passes, as numbers — and explicitly contrasts itself with change_composite and timescan ('those return a picture of *where* change is, this returns the *how much*'). An agent can route between these three siblings from the description alone.

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

Usage Guidelines5/5

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

Gives explicit when-to-use conditions for each optional behavior: ask for blocks whenever the question is *where on this site*, or when a scene-wide mean looks small but change_composite shows a hot spot; use block_series only when the shape of history is the question; use speckle_filter when change is small or numbers look noisy, and leave it off for fine structure. Also states an input exclusion: refuses to mix polarizations.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.