Accelerating geospatial work with Kiro: One AI interface for the geo stack

Geospatial practitioners face a double integration tax. A single question such as, “How has vegetation changed around this watershed over the last 2 years, and where should we focus field work?”, can require coordinating half a dozen tools, each with its own API, data format, coordinate reference system (CRS) conventions, and rate limits, before a single analytical result emerges.

Worse, the fragmentation is two-sided. In most domains, the integration problem is mostly about data access. In geospatial work, processing and compute are as fragmented as the data. The catalog that lists the imagery doesn’t reproject it, the library that reprojects it doesn’t run band math, and neither of them scale a job across a cluster when the area of interest grows. Researchers either juggle a dozen desktop tools and browser tabs or write integration scripts that require maintenance when APIs or projection assumptions change.

This post introduces the Geospatial Power Pack, a Kiro power package that turns Kiro into a unified, AI-assisted geospatial workspace. Kiro is an agentic development environment created by Amazon Web Services (AWS). It helps developers and teams turn prompts into executable specs, validate code correctness to find bugs that unit tests miss, and build across large codebases with parallel agents that learn from every session. Users ask questions in natural language, and Kiro pulls data directly from authoritative sources, such as Registry of Open Data on AWS, and reads it in place rather than downloading, running real geospatial operations in the same environment the user writes code.

Now, you can use datasets from National Aeronautics and Space Administration (NASA), such as Surface Water and Ocean Topography (SWOT), and from United States Geological Survey (USGS), such as USGS Landsat, from the Registry of Open Data using Kiro with the Geospatial Powerpack.

Fragmentation slows the work on both sides

Consider an analyst assessing post-wildfire vegetation recovery. Today they might need to:

1. Find pre- and post-fire Sentinel-2 scenes across SpatioTemporal Asset Catalogs (STAC).
2. Pull the fire perimeters and infrastructure as vector features, reproject to a common CRS.
3. Read relevant bands from Cloud-Optimized GeoTIFF (COGs), compute burn-severity index (NBR), and difference the dates.
4. Summarize severity by management unit (zonal statistics).
5. Run a foundation model (FM) change-detection pass and scale out when the AOI spans a region.

That’s five categories of work spanning multiple tools, coordinate systems, file formats, and scaling regimes—for a single analysis. Multiply it across every site and project, and the cognitive overhead adds up fast.

Solution overview: The Geospatial Power Pack

The pack combines Kiro powers with modular Model Context Protocol (MCP) servers. A central power, kiro-geospatial, acts as the hub, providing an onboarding dashboard, a searchable resource catalog, a credential manager, domain skills, and guided workflows. Nineteen standalone MCP servers exposing 46 tools handle the actual work, each independently installable and configurable, plus a peer power for distributed compute on AWS.

The design is guided by a few key decisions:

• Dual fragmentation, equal weight – Data access (discover and read) and processing and compute (transform and analyze) are treated as co-equal problems. By design, the pack ships at least as many processing and compute servers as data servers, with a third pillar dedicated to geospatial artificial intelligence (GeoAI).
• Modular by design – Install only the servers you need using uvx. A team doing imagery analytics doesn’t have to install the point-cloud or biodiversity servers. Each server is a standalone Python package, and installing one pulls in only the shared base.
• Single credential surface – Configure keys one time in mcp.json, each flagged as required, optional, or license-needed. Secret values never appear in any status report, error, or log.
• Orchestrated discovery, processing, and analysis – Ask one question and the hub’s orchestration router fans it across multiple sources and tools in parallel, always in pillar order, with graceful degradation when a source fails.
• Open data first – The default discovery and GeoAI paths read open, credential-free datasets from the Registry of Open Data on AWS, such as Sentinel-2 Cloud Optimized GeoTIFFs using the Earth Search STAC API, LGND Clay v1.5 embeddings over anonymous Amazon Simple Storage Service (Amazon S3), so a new user gets a working pipeline with nothing to license or configure.

Coverage at a glance

The pack organizes capabilities into three pillars plus credentialed and peer servers.

In total, that’s 21 packages—the hub, the geo-common shared base, and 19 MCP servers exposing 46 tools across open, free-tier, and proprietary sources.

How it works

The interface is built to answer a single question by coordinating multiple sources and operations. A researcher might ask Kiro:

Find the two least-cloudy Sentinel-2 scenes over this area of interest from before and after the fire, compute the burn-severity difference, and summarize it by the parcels in this GeoJSON.

Kiro discovers the scenes across STAC catalogs, reads only the bands it needs directly from Amazon S3, computes the index, and rolls the result up by zone, with no scripting, no tab switching, and no manual reprojection.

Orchestration with graceful degradation

A single natural-language request flows strictly in pillar order: every discover step precedes every process step, which precedes every analyze step. Discovery sources are queried concurrently; if one source fails, the router records that in the provenance, labels the result partial, and keeps going rather than failing the whole request.

Federated STAC search is a good example. stac_search_multi queries multiple catalogs at once—Earth Search, CMR-STAC, Copernicus, and USGS—and round-robin merges the results so every responding catalog is represented rather than the first one filling the quota. It also collapses the same physical scene served by multiple catalogs under different ID schemes, with per-endpoint provenance for every result.

Guided multistep workflows

The pack includes steering workflows: executable, step-by-step guides that activate based on your workspace file patterns. They cover end-to-end pipelines such as COG conversion, STAC discover-and-analyze, zonal statistics, geocode-and-route, and embedding-based change detection. These aren’t documentation pages—they’re guides Kiro follows step by step, calling the right tools in the right order.

Domain skills with encoded best practices

Skills provide contextual guidance that activates based on what you’re working on—cloud-optimized format conventions (COG, GeoParquet, Zarr, or COPC), coordinate-reference handling, and the discovery, processing, and analysis pattern. When you’re converting rasters or wrangling projections, Kiro already knows the conventions.

Walkthrough: Sentinel-2 and Clay embeddings from the Registry of Open Data on AWS

Here’s a concrete, credential-free walkthrough built entirely on two Registry of Open Data on AWS datasets—Sentinel-2 Cloud-Optimized GeoTIFFs and the LGND Clay v1.5 Sentinel-2 embeddings. Imagine you want to characterize vegetation around an area of interest (AOI) and find other places that look like it.

1. Discover (Sentinel-2, open) – Ask, Find the least-cloudy Sentinel-2 L2A scene over this AOI from June 2024. Kiro queries the open Earth Search STAC API (maintained by Element 84) for the sentinel-2-l2a collection and returns matching items with their COG asset hrefs and eo:cloud_cover. This requires no account or key.
2. Read in place (COGs on Amazon S3, open) – Ask, Read the red and NIR bands for my AOI and compute NDVI. Kiro reads only the byte ranges it needs for the AOI window directly from the sentinel-cogs bucket, which is in the US West (Oregon) – us-west-2 AWS Region, using geo-raster, then runs the (normalized difference vegetation index) NDVI band math. No scene is downloaded whole; the read is scoped to the pixels in the window.
3. Retrieve embeddings (LGND Clay v1.5, open) – Ask, Pull the published Clay v1.5 embeddings for this same AOI. Kiro calls geo-foundation-models lookup_embeddings, which fetches real 1024-dimensional Clay v1.5 vectors for the AOI from the LGND dataset on Source Cooperative’s anonymous Amazon S3 mirror (us-west-2.opendata.source.coop, CC-BY 4.0). The dataset publishes an aggregated product (one representative embedding per MajorTOM grid cell per month) and a per-scene product, currently for June 2024 and June 2025. The bounding box (bbox) area and result count are bounded so a single call returns a small, consumable set.
4. Search by similarity (open vector store) – Ask, Index these embeddings and find the most similar cells in my collection. Kiro loads the retrieved vectors into geo-embedding-search (LanceDB locally or Amazon OpenSearch Service) and runs a nearest-neighbor query, surfacing other locations whose Clay embeddings are closest to the AOI—semantic “find more like this” over open data.

Each of these steps runs against open, credential-free data. There are two practical notes the pack encodes directly. The Clay embedding files are large single-row-group GeoParquet, so the embedding retrieval is best run in US West (Oregon) – us-west-2 or as a batch ingest into the vector store—remote interactive calls are best-effort. And because the on-tile embed_tile path ships a deterministic local stand-in (not real model weights), use lookup_embeddings when you need real Clay v1.5 vectors; each embedding result carries a backend field that records which produced it, so the two are never silently mixed.

This is the pattern the Registry of Open Data on AWS is built for: discovery, cloud-optimized reads, and now FM embeddings, all over sponsored open datasets, with the AWS “bring compute to the data” path (aws-geo-compute) ready when an AOI grows past what fits in-process.

Data credits

This walkthrough uses the Sentinel-2 Cloud-Optimized GeoTIFFs on the Registry of Open Data on AWS (and contains modified Copernicus Sentinel data) and the LGND Clay v1.5 Sentinel-2 embeddings (Source Cooperative, CC-BY 4.0). OpenStreetMap-derived features are © OpenStreetMap contributors (ODbL).

What makes this different

Desktop geographic information system (GIS) tools are powerful but keep you in a point-and-click loop that’s hard to reproduce or automate, and they don’t reach cleanly into cloud-optimized catalogs and object storage.

Library stacks like GDAL, rasterio, shapely, and pyproj give you programmatic control but require writing and maintaining integration code for every catalog, projection, and format—exactly the part that breaks. The pack handles the API calls, byte-range reads, error handling, and rate limiting so you can focus on the analysis rather than the infrastructure.

Generic AI assistants can discuss geospatial concepts, but they can’t run a live STAC query, reproject a geometry, or compute a real zonal statistic. The Geospatial Power Pack makes authenticated, structured calls and runs actual geospatial operations that return machine-readable results, providing real data rather than summaries from a training corpus.

Architecture for geospatial engineers

Each MCP server is a standalone Python package built on a shared geo-common base that provides one async HTTP client (built on httpx) with retry and exponential backoff, a common error taxonomy, rate-limit handling, and the BaseGeoServer contract every server inherits. Behavior is consistent across every domain because it’s implemented one time.

Servers run using uvx—no Docker or infrastructure to manage. A machine-readable bundle manifest declares every server, skill, and steering workflow, so it’s straightforward to check status and configure a setup. Property-based testing with Hypothesis backs the logic-bearing components, giving confidence the tools behave correctly on unexpected inputs.

Two principles run through the architecture. It’s cloud-optimized by default, meaning that the pack reads COG byte ranges, GeoParquet, Zarr, and COPC directly rather than downloading whole files. And it follows the principle of bringing the compute to the data—read only the byte ranges you need from Amazon S3, and delegate heavy or distributed jobs to aws-geo-compute, which maps a task type to the right execution target across AWS Batch, AWS Fargate, Amazon EMR with Apache Sedona, and Amazon SageMaker AI.

The result spans roles. Analysts retire wrapper scripts and let Kiro handle the integration layer. GIS engineers cross-reference data sources and run processing in one conversation instead of stitching together half a dozen tools. Teams work from the same declarative tooling, which cuts down the reproducibility problem that comes with mismatched local GIS installs.

Getting started

Install the shared base and the hub, add the servers you want, register them in mcp.json, and start asking questions. The onboarding dashboard shows what’s available, what needs credentials, and what’s ready to use.

The following is a minimal mcp.json for a working discovery, processing, and analysis pipeline:

{
  "mcpServers": {
    "geo-stac":   { "command": "/abs/path/.venv/bin/geo-stac" },
    "geo-vector": { "command": "/abs/path/.venv/bin/geo-vector" },
    "geo-ops":    { "command": "/abs/path/.venv/bin/geo-ops" },
    "geo-foundation-models": { "command": "/abs/path/.venv/bin/geo-foundation-models" }
  }
}

With those servers configured, you can already search imagery across multiple STAC catalogs, pull OpenStreetMap vector features, reproject and run geometry operations, and compute FM embeddings from a single chat interface. Add credentialed servers like geo-warehouse or geo-commercial-imagery by supplying their keys using env.

Conclusion

Geospatial work has had a dual fragmentation problem. The data is scattered across catalogs and APIs, and the processing is scattered across libraries and compute backends that don’t talk to each other. For public sector organizations—whether they’re monitoring wildfire recovery, tracking watershed health, or planning infrastructure investments— this fragmentation slows progress.

The Geospatial Power Pack collapses that integration tax into one interface, one credential surface, and one conversation, where you can move from discovery to processing to analysis in minutes. The authoritative catalogs and APIs remain the source of truth; Kiro becomes the single point of access that coordinates them. And because its default discovery and GeoAI paths read directly from the Registry of Open Data on AWS, anyone can run this walkthrough with no account, no key, and no egress cost.

As open geospatial datasets grow and FMs improve, the same architecture scales with them—new data sources become new MCP servers, and new models slot into the GeoAI pillar without rearchitecting the workflow. The goal is straightforward: spend less time wrangling tools and more time answering the questions that matter.

Want to learn more?

To get started, find the full power package with all the MCP servers, skills, steering workflows, and example configurations in the Geospatial Kiro power pack repository.

Learn more about open data on AWS. To learn about using open data on AWS datasets, visit the open data topic in the AWS Public Sector Blog.