From a World Event to the Satellite Scenes Over It: One API & MCP Workflow

A news event gives you two facts a satellite tape cannot: what happened and roughly where. But turning that into imagery — finding the actual Sentinel scenes over the spot, on the right dates, clear of cloud — is normally a separate hunt in a different catalog. This post shows how to do both in one workflow: query world events, find where they concentrate, then search the satellite scenes over them, over a REST API for your code and a Model Context Protocol (MCP) server for AI agents. It is the sequel to giving an AI agent live world-event awareness, extended from "what is happening" to "what can I see from orbit."

How do you go from a world event to the satellite imagery over it?

You chain three calls. First, query_signals returns geolocated events, each with coordinates and a recommended sensor. Second, query_hotspots (or query_stats) tells you where activity is concentrating, so you pick a meaningful area rather than a single wire report. Third, search_imagery takes that area's bounding box and returns the satellite scenes covering it, filtered by date and cloud cover. The same three steps exist as MCP tools, so an AI agent runs the loop conversationally. Each step is a plain HTTP request under /api/v1, authenticated with a bearer API key and metered on your token balance.

Step	Endpoint	Answers
1. Find events	GET /api/v1/signals	What is happening, where, how severe
2. Locate concentration	GET /api/v1/signals/hotspots · /stats	Where activity is clustering; how much, of what
3. Find imagery	GET /api/v1/imagery	Which satellite scenes cover that spot

What does query_signals return, and how do you filter it?

GET /api/v1/signals returns geolocated world events — geopolitical, security, disaster, and infrastructure — distilled from global news media and enriched with a verified location, a severity and GEOINT score, an escalation trend, source links, and a satellite-collection recommendation. You filter by bounding box, date window, and category, and now also by minimum severity, whether an event is escalating, and market exposure (oil, grain, shipping, …); you can sort by severity, recency, or number of sources. It returns up to 500 rows per page, cursor-paginated.

# High-severity, escalating security events near a bounding box, worst first
curl -H "Authorization: Bearer ond_..." \
  "https://offnadir-delta.com/api/v1/signals?bbox=30.0,50.0,31.0,51.0&days=7&categories=security&min_severity=7&escalating=true&sort=severity"

Each signal carries a collection block — a recommended remote-sensing level and sensor (SAR or optical) for that event — so the response already hints at what to image next. Every signal also links back to its original sources and a verified location, which is what makes the feed evidence-based rather than a black box.

How do you find where events are concentrating, not just list them?

Use aggregates instead of rows. GET /api/v1/signals/stats returns a total event count plus a per-category and per-day breakdown — the day-over-day series is your trend line. GET /api/v1/signals/hotspots grid-bins the events into cells and ranks them by event count, each cell carrying its peak severity and the categories present. Both are cheaper than paging full signals because they return roll-ups, not records.

# Where is activity concentrating this week? (1° grid, severity >= 6)
curl -H "Authorization: Bearer ond_..." \
  "https://offnadir-delta.com/api/v1/signals/hotspots?days=7&precision=1&min_severity=6"

The grid cell size is set by precision in decimal degrees (roughly 111 km per degree at the equator), so a precision=1 cell is about 111 km across and a precision=0.25 cell about 28 km. Pick the top-ranked cell's coordinates as the center of the area you want to image.

How do you find the satellite scenes over an event?

Call GET /api/v1/imagery with the event's (or hotspot's) bounding box. It searches the imagery catalog and returns the scenes covering that area within a date window. Supported collections are Sentinel-1 GRD and RTC (C-band SAR), Sentinel-2 L2A (optical), and OPERA RTC-S1 (analysis-ready SAR). Sentinel-2 carries a cloud_cover_max filter; the SAR collections see through cloud and darkness, which is why the signal's recommended sensor matters.

# Sentinel-2 optical scenes over the area, last 14 days, under 30% cloud
curl -H "Authorization: Bearer ond_..." \
  "https://offnadir-delta.com/api/v1/imagery?bbox=30.3,50.3,30.7,50.6&collection=sentinel-2-l2a&days=14&cloud_cover_max=30"

The response is scene metadata only — id, collection, acquisition datetime, footprint, cloud cover, platform, and a preview URL — with no imagery bytes and no signed URLs. That keeps the payload small and avoids redistributing provider access tokens. To understand the identifiers you get back, the imagery catalog follows the open STAC (SpatioTemporal Asset Catalog) specification; Sentinel-1 and Sentinel-2 are part of the European Union's Copernicus programme, and OPERA RTC-S1 is a NASA/JPL analysis-ready SAR product. Sentinel-2 images at 10 m resolution with a 5-day revisit from its two-satellite constellation — enough to catch week-to-week change over most events. For how to choose between radar and optical for a given event, see SAR vs optical: when to use which.

How does the same workflow run over MCP for an AI agent?

The MCP server at /api/v1/mcp exposes the same surface as tools, so an agent runs the loop without any glue code. The tools are query_signals, query_stats, query_hotspots, search_imagery, and get_world_brief, plus assess_signal and ask_analyst on Pro. It also exposes resources — brief://latest, brief://{date}, signals://schema, usage://current, and imagery://collections — and ready-made prompts such as aoi-watch and market-exposure-check. The Model Context Protocol is an open standard for connecting AI applications to external tools and data; see the MCP specification.

# Register the server once (Claude Code); the agent discovers the tools
claude mcp add --transport http off-nadir-delta \
  https://offnadir-delta.com/api/v1/mcp \
  --header "Authorization: Bearer ond_..."

Once registered, a single instruction like "find the most severe escalating event in the Black Sea this week and list the Sentinel-1 scenes over it" makes the agent call query_signals, then search_imagery, and answer with sourced events and real scene IDs — grounded in retrieved facts instead of its training snapshot. This is the agent-facing half of the live world-event awareness workflow.

How is usage metered, and how do you check your balance?

Everything runs on one token balance — the same wallet the app uses. The Daily World Brief (GET /api/v1/brief) and the usage endpoint (GET /api/v1/usage) are free; query_signals, query_stats, query_hotspots, and search_imagery are metered per query; and the AI assess and analyst endpoints (and their MCP tools) require a plan with AI access. Call GET /api/v1/usage — or read the usage://current MCP resource — to see your remaining balance and plan capabilities before spending on a metered call.

# Pre-flight: how many tokens are left, and do I have AI access?
curl -H "Authorization: Bearer ond_..." \
  "https://offnadir-delta.com/api/v1/usage"

Successful responses also carry rate-limit headers (X-RateLimit-Remaining, X-RateLimit-Reset), and query_signals is cursor-paginated via meta.next_cursor. The exact parameters, response shapes, and a machine-readable OpenAPI 3.1 spec live in the API & MCP reference.

Why chain events to imagery instead of using them separately?

Because the value is in the join. An event feed on its own tells you what happened; an imagery catalog on its own makes you already know where to look. Chaining them means the event decides the query — its coordinates become the bounding box, its recommended sensor becomes the collection, its date becomes the window — so you go from a headline to a shortlist of verifiable satellite scenes in three calls. That is the difference between a news API and a geospatial intelligence API: the second one hands the next step, from open-source signal to overhead collection, to whatever is calling it — your code or your agent. For the broader picture of turning open sources into geolocated intelligence, see what is geospatial OSINT.