AiSeek

Get country Change Heat

get_country_heat

Read-onlyIdempotent

Get SeekEarth's Change Heat per country: how much verified change each country had against its own recent normal, 0 to 100, where 50 is an ordinary day; it measures change, never danger or instability. Use it to see where things are changing; for all country codes use list_countries, for the changes themselves search_changes, for one place at one moment get_earth_view. Parameters: country (e.g. jp or JP) narrows the answer to one country, otherwise the 60 hottest come back; days sets the window, e.g. 1 for today against normal or 30 for a month; domain (e.g. MARKETS) counts one coverage domain. Behavior: a days value above the plan's cap (Free 7, Pro 30, Intelligence and Developer 90) is cut to the cap without an error, and days/maxDays in the answer show what was used; heat is computed once a day (asOf); changes with no single country are left out. One call of the key's quota (Free keys have a daily MCP cap); a rejected argument costs nothing.

Input Schema

Name	Required	Description
`days`	No	Window in days, 1 to 90 (default 7); capped by the key's plan: Free 7, Pro 30, Intelligence and Developer 90
`domain`	No	Only changes of this coverage domain; omit for the connection's default domain, or all domains when none is set
`locale`	No	Language of headlines, summaries and notices in the answer: en, zh or ja; omit for the connection's default language (en unless set)
`country`	No	ISO 3166-1 alpha-2 country code, e.g. JP or US, upper or lower case; omit for every country (the 60 hottest)

Output Schema

Name	Required	Description
`map`	Yes	The SeekEarth page on aiseek.dev for this view
`asOf`	Yes	The last day (UTC, YYYY-MM-DD) the heat was computed for
`days`	Yes	The window used, after the plan's cap
`method`	Yes	Short name of the method version used to compute Change Heat
`maxDays`	Yes	The longest window the plan allows
`countries`	Yes	Countries by heat, highest first (at most 60), or the one country asked for

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 20, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare read-only/idempotent/non-destructive semantics, and the description still adds substantial non-structured behavior: the plan cap clamp (Free 7 / Pro 30 / Intelligence and Developer 90) that truncates silently rather than erroring, days/maxDays echoed in the answer, once-a-day computation (asOf), exclusion of country-less changes, and quota cost per call. These are exactly the traits an agent needs to predict results and avoid surprises.

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?

One dense paragraph, front-loaded with purpose, then usage alternatives, then parameters, then behavior — a logical order with no filler sentences. It is on the long side for a single block, but every clause carries distinct information and nothing is repeated from 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?

With an output schema present, the description need not explain return values, and it covers everything else an agent needs: metric interpretation, when to use it vs siblings, all four parameters with examples, plan-based clamping, quota cost, and data-freshness caveats. Nothing material 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, but the description adds usable semantics beyond the schema: case-insensitive country codes (jp or JP) with the 60-hottest default, and concrete days readings ('1 for today against normal or 30 for a month') that clarify the window's meaning, not just its range.

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 (per-country Change Heat) and instantly defines the metric's scale and meaning (0-100, 50 = ordinary day, measures change not danger). It also explicitly names the siblings it is not (list_countries, search_changes, get_earth_view), so the agent can disambiguate 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 when-to-use ('see where things are changing') and routes three adjacent needs to the correct alternative tools by name. This is routing information an agent can act on directly, not implied usage.

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

All AiSeek tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?