Skip to main content
Glama

pick_change_interval

Read-only

Scan a site's whole series and name the two passes worth narrating.

The deterministic first half of the "watch a site over time" story, and the
step that turns a wall of passes into an answer. Given the STAC URLs of a
site's passes (2 or more, any order), it co-registers them into a
``to_stack`` cube, reduces it with ``stack_stats``, and returns the *one*
consecutive pass-pair whose measured change stands **furthest clear of the
speckle detection floor** — the pair a reader should look at first. No model
is called: a number picks the frames (the determinism boundary applied to
frame selection), so the choice is reproducible and safe
to quote.

Why this exists as its own tool: ``narrate_change`` reads a *pair* of passes,
but a site has many, and "which two?" is a measurement question, not a model
one — a picture past three dates encodes nothing a model can separate, so the
pair has to be chosen before the model is called. This answers it. The
returned ``urls`` are the two chosen passes in time order, ready to hand
straight to ``narrate_change`` (or ``change_composite`` to see them): the
two tools chain into scan → narrate with no server and no model in the
selection.

Returns ``selected_interval`` (the interval's ``earlier_id`` / ``later_id``,
their datetimes, the ``changed_fraction`` and signed ``mean_delta_db``, the
cube's ``false_alarm_fraction`` speckle floor, the ``excess`` of the change
over that floor, and ``stands_clear`` — whether the change cleared the floor
by a usable margin), ``urls`` (the earlier then the later pass's STAC URL),
and the license/attribution. When ``stands_clear`` is false the series' own
largest change is still inside the speckle, so the pair is offered but the
reader is warned the difference may be interference rather than change.

``selected_interval`` is ``None`` (and ``urls`` empty) when the series has
fewer than two comparable passes or no interval reported any change — there
is no pair to narrate. ``crs="utm"`` (the default) grids the cube in the
site's UTM zone so the change fractions weigh equal ground; ``max_size`` and
``change_threshold_db`` match ``stack_stats``. Refuses to mix polarizations
(HH vs VV are not comparable). Requires the ``load`` extra.

Input Schema

NameRequiredDescriptionDefault
crsNoutm
urlsYes
assetNoGEC
extentNointersection
max_sizeNo
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?

This description is remarkably transparent. It explains the underlying mechanics (co-registers into a 'to_stack' cube, reduces with 'stack_stats'), defines the criteria for success (furthest clear of the speckle floor), and handles failure modes (returning 'None' if insufficient data exists).

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?

While the description is quite lengthy, its detailed nature is justified by the technical complexity of the algorithm. Every sentence serves to explain a critical constraint or purpose, meaning there is zero wasted information.

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?

The tool is comprehensively defined. It covers input constraints (required `load` extra, no mixing polarizations), output behavior (what the returned fields mean), logical termination conditions, and its role in the overall data analysis architecture.

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?

Given the 0% schema description coverage, the description is vital. It explains the semantic constraints of the parameters, such as why 'crs' is used (to weigh equal ground) and that 'max_size' and 'change_threshold_db' must align with 'stack_stats'.

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 purpose is stated with surgical precision: it scans a whole series and names the *pair* of passes with the greatest measurable change. It explicitly differentiates itself from narrating tools by defining its role as a measurement and selection step, not a modeling one.

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?

The description provides a complete workflow explanation, detailing why this tool is necessary before calling `narrate_change` or `change_composite`. It defines the 'before and after' use case, ensuring the agent understands its placement in the analytical pipeline.

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.