eo-mcp

Overview Schema Source Related Servers Discussions Admin

analyze_urban_heat_island

Compute Land Surface Temperature and map urban heat island hotspots from Landsat 8/9 thermal data, returning LST, UHI intensity, and thermal risk for a specified area and date range.

Instructions

Compute Land Surface Temperature (LST in °C) and map Urban Heat Island (UHI) microclimate hotspots using Landsat 8/9 Thermal Infrared (TIRS Band 10) and NDVI-derived surface emissivity. Zero-config: Streams public Landsat surface reflectance and thermal data without credentials.

Args: bbox: Bounding box [min_lon, min_lat, max_lon, max_lat] in WGS84. datetime_range: Acquisition date window during warm season (e.g. '2024-06-01/2024-08-31'). format: Output format ('summary', 'geojson', or 'csv').

Returns: JSON or formatted string with mean/min/max LST (°C), UHI intensity (delta °C), thermal hotspot area (ha), cool island buffer area, and thermal risk classification.

References:

Valor, E., & Caselles, V. (1996). Remote Sensing of Environment, 57(3), 167-184. DOI: 10.1016/0034-4257(96)00039-9
Sobrino, J. A., et al. (2004). Remote Sensing of Environment, 90(4), 434-440. DOI: 10.1016/j.rse.2004.02.003
Jiménez-Muñoz, J. C., et al. (2009). IEEE TGRS, 47(1), 339-349. DOI: 10.1109/TGRS.2008.2007125

Input Schema

TableJSON Schema

Name	Required	Default
`bbox`	Yes
`format`	No	summary
`datetime_range`	No	2024-06-01/2024-08-31

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 23, 2026

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description carries the behavioral burden. It explicitly discloses the zero-config behavior, 'Streams public Landsat surface reflectance and thermal data without credentials,' and describes the return shape. It does not mention rate limits or side effects, but the tool is an analysis operation on public data and the disclosed auth/streaming behavior is materially useful.

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 front-loaded with the core purpose and zero-config behavior, then cleanly structured into Args, Returns, and References. The References section with three full citations is arguably unnecessary for tool invocation, which keeps it from a 5, but the overall length and formatting are still reasonable.

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?

For a fairly complex remote-sensing tool, the description covers the data source, authentication behavior, all parameters, and expected outputs (mean/min/max LST, UHI intensity, hotspot area, classification). The presence of an output schema and defaults in the input schema further reduces missing information, so an agent has enough to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must fully document parameters. It does: bbox is defined as '[min_lon, min_lat, max_lon, max_lat] in WGS84,' datetime_range has a concrete example, and format enumerates all three allowed values ('summary', 'geojson', or 'csv'). This exceeds what the input schema provides.

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 opening sentence states a specific verb+resource: 'Compute Land Surface Temperature (LST in °C) and map Urban Heat Island (UHI) microclimate hotspots using Landsat 8/9 Thermal Infrared (TIRS Band 10) and NDVI-derived surface emissivity.' This clearly distinguishes it from sibling EO tools because no other sibling is described as an LST/UHI analysis. It also names the exact data source and method, leaving no ambiguity about the tool's purpose.

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?

The description gives clear usage context: use this tool when you need LST/UHI outputs from Landsat data, with examples such as 'Acquisition date window during warm season (e.g. '2024-06-01/2024-08-31').' It does not explicitly name alternatives or when-not conditions, but the context is strong enough for an agent to choose this tool over unrelated siblings.

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