geolens-mcp

Official

Overview Schema Source Related Servers Discussions Admin

aggregate

Compute exact counts, summaries, histograms, and grouped breakdowns over dataset rows without SQL, with optional CQL2-JSON filters and bounding-box constraints.

Instructions

Compute an exact aggregate over a dataset's rows: counts, summaries and breakdowns without writing SQL. Use query for anything else.

request is the JSON body of the aggregate route, chosen by op. Every op takes an optional CQL2-JSON filter and an optional bbox [west, south, east, north] in WGS 84. Unknown keys are refused.

{"op": "count"}
{"op": "stats", "column", "stats": [count|sum|avg|min|max, ...]}
{"op": "value_counts", "column", "limit"} (limit 1-50, default 10)
{"op": "histogram", "column", "bins"} (bins 1-50, default 10)
{"op": "group_by", "group_column", "stat", "column"} or "stats": [{"stat", "column"}], plus optional date_bucket (day|week|month|year), sort_by, sort and limit (1-50)
{"op": "rows", "columns": [up to 20], "sort_column", "sort", "limit", "cursor"} lists features a page at a time (limit 1-100, default 25), each with its gid and bbox, never a geometry; pass the previous page's next_cursor as cursor under the same sort.

Returns {op, result, approximate, cached}. Refusals keep the route's HTTP status and a code in the error detail:

422 too_wide: the bbox view holds over 500,000 rows. Narrow the bbox or drop it.
422 invalid_column, invalid_cursor, invalid_filter, no_geometry, query_timeout, query_data_error, result_too_large: fix the request and retry.
429 query_busy (two aggregates already running for you) or query_at_capacity: retry after 200-400 ms with jitter.
503 query_unavailable: retry after the Retry-After delay. Datasets you can't read answer 404. The route allows 10 requests a second.

Args: dataset_id: Dataset id with a feature table (not a raster). request: The aggregate body described above.

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": {
      "dataset_id": "<dataset_id>",
      "request": "<request>"
    },
    "name": "aggregate"
  }
}

Input Schema

Name	Required	Description	Default
`request`	Yes
`dataset_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.30.1Nov 9, 2026

TDQS

A5/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses rate limiting (10 req/s), concurrency limits (two aggregates running), a 500,000-row bbox ceiling, cursor-based pagination semantics tied to sort stability, that `rows` never returns geometry, and the exact HTTP status plus error `code` for each refusal class with retry guidance (200-400 ms with jitter, `Retry-After`). This is far beyond what annotations would normally supply.

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

Conciseness5/5

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

Front-loaded with the one-line purpose and the alternative, then bulleted per-op grammar, then a single return-shape sentence, then a compact error table. The length is driven by the size of the request grammar rather than padding; every sentence conveys a constraint an agent must act on.

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 two-parameter tool with an untyped nested request object and no output schema, the description supplies the missing request grammar, the return envelope (`{op, result, approximate, cached}`), and the full failure taxonomy. Nothing an agent needs in order to construct a valid call or recover from an error is absent.

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

Parameters5/5

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

Schema coverage is 0% and `request` is an open nested object (`additionalProperties: true`), so the schema offers no guidance at all; the description fully compensates by specifying the per-op key grammar, defaults, and valid ranges (limit 1-50 default 10, bins 1-50, rows limit 1-100 default 25, columns up to 20, date_bucket enum, bbox ordering in WGS 84) and noting that unknown keys are refused.

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 ('Compute an exact aggregate over a dataset's rows') and immediately scopes what counts as an aggregate: counts, summaries and breakdowns. It also names the sibling `query` as the fallback for everything else, so an agent can distinguish the two without opening either 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?

Explicit routing rule: use this for aggregates, use `query` for anything else. Within the tool it also states per-op selection by naming each `op` value and its purpose, plus a hard exclusion ('dataset id with a feature table (not a raster)'), so an agent knows both when to call it and which request shape to pick.

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

Deploy Server