Skip to main content
Glama

Get SeekEarth at a place and moment

get_earth_view
Read-onlyIdempotent

Get SeekEarth for one place and moment: the published changes placed there, the Change Heat of its countries, and the Earth's layer items in force (disaster alerts, cyclones, official warnings, conflict, outbreaks, river levels and more), each with its nature and source to credit. Use it for where-and-when questions; for heat across all countries use get_country_heat, for the country list list_countries, for changes by subject search_changes. Parameters: give country, or lat with lon and a radius_km circle; at sets the moment and days the window before it; mode NOW reads today's knowledge of those days, KNOWN what readers could see at the time; layers narrows the Earth layers. Behavior: at most 30 changes, most important first; in KNOWN mode changes withdrawn since are only counted (withdrawnLater); a place is required. One call of the key's quota (Free keys have a daily MCP cap); a rejected argument costs nothing.

Input Schema

NameRequiredDescriptionDefault
atNoThe moment to read, ISO 8601 date or date-time with a zone (default now); not in the future and within the plan's reach
latNoLatitude of the place in degrees (with lon); the place is a circle of radius_km around it
lonNoLongitude of the place in degrees (with lat)
daysNoWindow in days before `at`, 1 to 180 (default 7); capped by the key's plan
modeNoNOW (default): today's knowledge of the window; KNOWN: what readers could see at `at`NOW
layersNoWhich Earth layers to include (e.g. gdacs, nhc, jma, ucdp, aftershock); omit for every event layer
localeNoLanguage of headlines, summaries and notices in the answer: en, zh or ja; omit for the connection's default language (en unless set)
countryNoISO 3166-1 alpha-2 country code, e.g. JP; give either this or lat and lon
radius_kmNoRadius of the circle around lat and lon, 10 to 3000 km (default 500)

Output Schema

NameRequiredDescriptionDefault
atYesThe moment read, ISO 8601 UTC
urlYesThe SeekEarth page on aiseek.dev for this place
daysYesThe window in days, after the plan's cap
fromYesStart of the window, ISO 8601 UTC, after the plan's cap
heatYesChange Heat of the place's countries on the UTC day of `at`
modeYesKNOWN: what readers could see at `at`; NOW: today's knowledge of the same days
placeYesThe place asked about: {country} or {lat, lon, radiusKm}
eventsYesItems of the Earth's layers in force there (disasters, warnings, forecasts, conflict, displacement, outbreaks, power plants...), each with its layer's nature and source
changesYesPublished changes placed there in the window, most important first (at most 30); knownAfter and wordingChangedLater mark NOW-only differences
maxDaysYesThe longest window the plan allows
sourcesYesWhere each layer comes from and how to credit it
withdrawnLaterYesKNOWN only: changes readers could see then that have been withdrawn since (counted, never shown)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / layers / items / enum
      Previous value: -[
      -  "gdacs",
      -  "eonet",
      -  "nhc",
      -  "jtwc",
      -  "tsunami",
      -  "pager",
      -  "volcano-us",
      -  "drought-us",
      -  "nws",
      -  "jma",
      -  "dwd",
      -  "space-weather",
      -  "sea-ice",
      -  "ucdp",
      -  "unhcr",
      -  "ecdc",
      -  "gem-power",
      -  "sanctions",
      -  "chokepoints",
      -  "ports",
      -  "eia-energy",
      -  "lpi",
      -  "aftershock",
      -  "flood-uk",
      -  "rivers-de",
      -  "rivers-us",
      -  "tides"
      -]New value: +[
      +  "gdacs",
      +  "eonet",
      +  "nhc",
      +  "jtwc",
      +  "tsunami",
      +  "pager",
      +  "volcano-us",
      +  "drought-us",
      +  "nws",
      +  "jma",
      +  "dwd",
      +  "space-weather",
      +  "sea-ice",
      +  "ucdp",
      +  "unhcr",
      +  "ecdc",
      +  "gem-power",
      +  "sanctions",
      +  "chokepoints",
      +  "ports",
      +  "eia-energy",
      +  "lpi",
      +  "aftershock",
      +  "flood-uk",
      +  "rivers-de",
      +  "rivers-us",
      +  "tides",
      +  "air-quality"
      +]
    • changedInput schema / properties / layers / maxItems
      Previous value: -27New value: +28
  2. Changed2 schema fields changed
    • changedInput schema / properties / layers / items / enum
      Previous value: -[
      -  "gdacs",
      -  "eonet",
      -  "nhc",
      -  "jtwc",
      -  "tsunami",
      -  "pager",
      -  "volcano-us",
      -  "drought-us",
      -  "nws",
      -  "jma",
      -  "dwd",
      -  "space-weather",
      -  "sea-ice",
      -  "ucdp",
      -  "unhcr",
      -  "ecdc",
      -  "gem-power",
      -  "sanctions",
      -  "chokepoints",
      -  "ports",
      -  "eia-energy",
      -  "lpi",
      -  "aftershock"
      -]New value: +[
      +  "gdacs",
      +  "eonet",
      +  "nhc",
      +  "jtwc",
      +  "tsunami",
      +  "pager",
      +  "volcano-us",
      +  "drought-us",
      +  "nws",
      +  "jma",
      +  "dwd",
      +  "space-weather",
      +  "sea-ice",
      +  "ucdp",
      +  "unhcr",
      +  "ecdc",
      +  "gem-power",
      +  "sanctions",
      +  "chokepoints",
      +  "ports",
      +  "eia-energy",
      +  "lpi",
      +  "aftershock",
      +  "flood-uk",
      +  "rivers-de",
      +  "rivers-us",
      +  "tides"
      +]
    • changedInput schema / properties / layers / maxItems
      Previous value: -23New value: +27
  3. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description still adds real operational context: a cap of 30 changes ordered by importance, KNOWN mode counting withdrawn changes separately (withdrawnLater), a required place, quota consumption per call, and that a rejected argument costs nothing. The only missing behavioral detail is the shape/sectioning of the combined answer, which the output schema presumably covers.

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-loaded with purpose, then routing, then parameters, then behavior — a sensible order with no filler sentences. It is dense and slightly repetitive with the schema (parameters, mode, layers), which keeps it from a 5.

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 9-parameter tool with an output schema, the description covers the things structure cannot: quota cost, required input, result truncation, and mode semantics. An agent has everything needed to call it correctly and interpret the caps.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description usefully consolidates the place contract ('give country, or lat with lon and a radius_km circle') and the at/days and NOW-vs-KNOWN relationship, but these restate what the schema properties already say rather than adding new constraints or formats.

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 and resource — 'Get SeekEarth for one place and moment' — and immediately enumerates the composite payload (published changes placed there, Change Heat of its countries, Earth layer items in force). It names the sibling tools it is not (get_country_heat, list_countries, search_changes), so an agent can distinguish it without opening any schema.

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

Usage Guidelines5/5

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

Gives an explicit use case ('where-and-when questions') and then routes to three named alternatives with the condition that selects each. Nothing about tool selection is left to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources