Tanod MCP server

skypeek: satellite image of a place (Sentinel-2 true color, NDVI, NDWI)

get_satellite_image

Read-onlyIdempotent

Retrieve a recent satellite image of a place or coordinates as a base64 PNG with capture date, cloud cover, source, and attribution.

Instructions

skypeek: Get a recent satellite image of a place or coordinates. For the forecast use get_weather. Returns a recent satellite picture of a place as a base64 PNG, with the capture date, cloud cover, source and attribution: the least cloudy recent Sentinel-2 L2A scene at 10 m per pixel as true colour, NDVI (vegetation) or NDWI (water), clouds painted grey in the index views; NASA GIBS true colour (about 250 m) for areas wider than 10 km or when Sentinel-2 has no scene. Not real time (date is the scene day); clouds can hide the ground (404 too_cloudy, no_scene, no_imagery: not charged). Sentinel-2 data is free to use with credit; NASA GIBS has no restrictions. Not for navigation or safety. Typically 5 to 25 s (a few Sentinel-2 tiles are read and rendered). Price: USD 0.01. Free: 5 skypeek calls per IP per UTC day. Docs: https://tanod.dev/learn/satellite-image-api.html

Input Schema

TableJSON Schema

Name	Required	Description	Default
`lat`	No	Latitude in degrees (-90 to 90). Send lat and lon, or place.
`lon`	No	Longitude in degrees (-180 to 180). Send lat and lon, or place.
`date`	No	Target day YYYY-MM-DD (2015-07 onward, not in the future): the nearest scene within 15 days that is clear enough. Default: the newest clear scene of the last 60 days.
`size`	No	Width and height of the PNG in pixels (128-1024, default 512).
`view`	No	true_color (a natural-colour picture), ndvi (vegetation) or ndwi (open water), both computed from the same Sentinel-2 scene with clouds painted grey.	true_color
`place`	No	City name, optionally with a country code (such as Manila, PH); cities of 15,000+ people. Send place, or lat and lon.
`radius_m`	No	Half the side of the pictured square, in metres (250-100000, default 2560: about 10 m per pixel at 512 px). Over 10000 is NASA 250 m true colour only.
`max_cloud`	No	Most cloud accepted, as a percent of the pictured area (0-100, default 30). No scene that clear is a 404 too_cloudy (not charged).

Output Schema

TableJSON Schema

Name	Required	Description
`lat`	No
`lon`	No
`bbox`	No
`date`	No
`note`	No
`view`	No
`error`	No	Only on an error result: an object {code, message}, or the reason string of an x402 PaymentRequired object.
`image`	No
`place`	No
`scene`	No
`legend`	No
`source`	No
`fallback`	No
`radius_m`	No
`upstream`	No
`attribution`	No
`captured_at`	No
`resolution_m`	No
`cloud_cover_scene_pct`	No
`cloud_cover_window_pct`	No
`cloud_shadow_window_pct`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Oct 15, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes far beyond the annotations: latency (5-25 s), price and free-tier quota (USD 0.01, 5 calls/IP/UTC day), failure modes that are not charged (404 too_cloudy, no_scene, no_imagery), the non-real-time caveat about `date`, cloud occlusion behavior, the NASA GIBS fallback for wide areas, and licensing/attribution terms. This is exactly the operational context annotations cannot carry.

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?

Front-loads the purpose and the sibling disambiguation in the first sentence, then layers behavior, cost, and licensing. It is a dense single paragraph with some packing, but nearly every clause earns its place and nothing is redundant with the schema.

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?

Despite 8 parameters and an output schema, the description supplies the operational context an agent needs (cost, quota, latency, error semantics, source fallback, licensing), while the output schema covers the return shape. Nothing needed to invoke it correctly is missing.

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 adds cross-parameter meaning, e.g. that index views paint clouds grey and that radius over 10 km forces NASA 250 m true colour only, plus the scene-selection window implied by `date`. It stops short of documenting several parameters (size, max_cloud tolerances) in prose, but those are well covered by the schema.

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+resource (get a satellite image of a place or coordinates) and immediately names the sibling it is not (get_weather for forecasts). It further specifies the source imagery, view modes, and resolution, so an agent can distinguish it from every sibling in the set.

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?

Explicitly routes the agent away from this tool for forecasts ('For the forecast use get_weather') and clarifies acceptable inputs (place, or lat and lon). It does not spell out when-not conditions beyond that or compare against siblings like geocode/find_places_nearby for locating a place first.

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

Deploy Server