Running Cat Geo

Weather, air, heights and rivers over an area

area_report

Read-only

A region at once, for maps and comparisons across an area: the box is cut into a grid of about cells cells and every part is answered for the cell centres or the whole box. The answer: rows and cols of the grid, lon (cols centre longitudes, west to east) and lat (rows centre latitudes, north to south), then one key per part. weather and air: {times: [ISO hour, ...], values: {variable: [[cell values of hour 0], [hour 1], ...]}}, so values.temperatureC[h][r * cols + c] is the value at hour h in row r, column c, row 0 being the northern edge; weather variables are temperatureC, feelsLikeC, precipitationMm, weatherCode, windKmh, windDirDeg, gustKmh, cloudPct, humidityPct, pressureHpa, boundaryLayerM, air variables the same names as in air_quality (pm25, pm10, nitrogenDioxide, ozone, europeanAqi and so on). elevation: {values: [height of each cell in the same order]}. airStations: {stations: [...]} and rivers: {gauges: [...]}, every one in the box. layers: one feature collection per layer named in layers. A part that fails comes back under errors. Boxes up to 3,600 square degrees for weather, air and elevation, 16 for stations, rivers and layers. Use point_report for one place. Counts one request per part (and per layer).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "bbox": "<bbox>"
    },
    "name": "area_report"
  }
}

Input Schema

Name	Required	Description
`bbox`	Yes	[west, south, east, north] in degrees
`cells`	No	About how many grid cells; the grid keeps cells near square
`hours`	No	Forecast hours from now for weather and air
`layers`	No	Map layers to include when include has layers: route, protected_area, piste, aerialway, boundary
`include`	No	Parts: weather, air, airStations, elevation, rivers, layers; all but layers by default

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnly and openWorld, so the safety profile is covered. The description adds genuinely useful behavior beyond that: per-part failure reporting via an errors key, and a quota note that one request is counted per part and per layer. It stops short of explaining what an over-limit box returns or how partial failures affect the quota.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The output-format explanation is load-bearing given there is no output schema, but it is delivered as one dense run-on paragraph with garbled phrasing ("about cells cells", "one key per part"). Front-loading is partial: the purpose is stated vaguely before the precise content arrives.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-value burden and does so thoroughly: grid dimensions, lon/lat ordering, the h/r*cols+c indexing rule, per-part structures, and an errors channel. Limits and quota are also covered; only the over-limit behavior is left open.

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 schema already documents bbox, cells, hours, layers and include including defaults. The description echoes the variable/part names and the near-square grid behavior but adds little parameter meaning beyond the schema; its added value is mostly about output shape, not inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description makes clear this is a multi-domain (weather, air, elevation, stations, rivers, layers) report computed over a bounding box cut into a grid, and it names point_report as the single-place alternative. The opening phrase "A region at once, for maps and comparisons" is vague, but the specifics of what each part returns resolve the purpose quickly.

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?

It explicitly routes single-location queries to point_report and gives box-size caps per part (3,600 sq deg for weather/air/elevation, 16 for the rest), which tells an agent when the tool is applicable and when it will not scale. It does not say what happens if a box exceeds those caps (rejection vs. clamping).

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

All Running Cat Geo 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?