stac-eo-mcp

Overview Schema Source Related Servers Discussions Admin

compute_index

Idempotent

Compute NDVI, NDWI, or NBR statistics for a Sentinel-2 L2A scene over a bounding box, with cloud masking and optional map or GeoTIFF output.

Instructions

Compute NDVI, NDWI or NBR on one Sentinel-2 L2A scene, reading only the bbox window.

Clouds, shadows and no-data are masked with the SCL layer. Returns min, max, mean, std
and the share of valid pixels, plus file paths when `save` is set. No raster data is
returned. Area is limited (default 100 km²).

Input Schema

Name	Required	Description	Default
`bbox`	Yes	[west, south, east, north] in WGS84 degrees, e.g. [12.47, 41.9, 12.5, 41.92]
`save`	No	Also write the index map to the output folder	none
`index`	Yes	Spectral index: ndvi (vegetation), ndwi (water), nbr (burn).
`catalog`	No	STAC catalog. Defaults to the server's configured catalog.
`item_id`	Yes	Sentinel-2 L2A scene id from search_scenes

Output Schema

Name	Required	Description
`bbox`	Yes
`note`	No
`index`	Yes
`stats`	Yes
`item_id`	Yes
`outputs`	No	format -> file path
`datetime`	Yes
`resolution_m`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 29, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Adds real behavioral detail beyond the annotations: cloud/shadow/no-data masking via SCL, an area cap (default 100 km²), and an explicit statement that no raster data is returned unless save is set. The annotations already cover read-only/destructive/idempotency semantics, though the description does not mention open-world or rate/permission behavior.

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

Conciseness5/5

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

Three short sentences, front-loaded with what is computed, followed by masking, return shape, and the area constraint. No filler or redundancy.

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?

With an output schema present and annotations covering safety semantics, the key gaps an agent needs (masking behavior, returned statistics, no-raster default, area cap) are all covered. Only edge behavior such as failure modes when the bbox exceeds the area limit or the scene lacks SCL is left implicit.

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 100%, so the baseline is 3; the description still adds value by tying bbox to a window-only read, tying save to returned file paths, and flagging the area limit that constrains bbox size. It does not add detail the schema lacks for catalog or index enums, which is fine.

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 specific verb (compute) and resource (spectral index over a Sentinel-2 L2A scene) and names the concrete outputs (NDVI, NDWI, NBR). It also pins the scope to a bbox window and a single scene, which cleanly separates it from siblings like search_scenes and time_series.

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

Usage Guidelines4/5

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

Implies the prerequisite chain by saying item_id comes from search_scenes and that only one scene is processed, which steers an agent away from using it for multi-scene or series work. It does not explicitly name time_series as the alternative for multi-date analysis or state when not to use it.

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

Deploy Server