Skip to main content
Glama

AQUAVIEW MCP

by org.aquaview.mcp

aggregate

Run aggregation queries on the AQUAVIEW catalog — get counts, spatial distributions, temporal distributions, and per-collection breakdowns without fetching individual items.

Args: aggregations: Comma-separated aggregation types (required). Valid types: total_count, datetime_max, datetime_min, datetime_frequency, collection_frequency, geometry_geohash_grid_frequency, geometry_geotile_grid_frequency. collections: Comma-separated collection IDs to scope the aggregation (e.g., "NOAA,NDBC"). exclude_collections: Comma-separated collection IDs to omit from the aggregation (e.g., "INCIDENT_NEWS"). Applied as a CQL2 NOT filter, so it composes with filter. bbox: Bounding box as "west,south,east,north". datetime: Temporal filter (same format as search_datasets). q: Free-text search to scope the aggregation. Multi-word queries are tokenised on whitespace and OR-combined to mirror search_datasets semantics (aggregate compiles q to CQL2 LIKE clauses on title/description; a raw %multi word% substring match would return 0 for most queries). filter: CQL2-JSON filter as an object or JSON-encoded string. Flat example: {"op": "=", "args": [{"property": "aquaview:institution"}, "NOAA"]}. Nested example: {"op": "<=", "args": [{"property": "aquaview:column_stats_summary.variables.Pressure.min"}, 10]}. license: Comma-separated SPDX license id(s) to scope the aggregation (e.g., "CC-BY-4.0,CC0-1.0"), or one of "public-domain", "proprietary", "various", "unknown". Matched against aquaview:license. precision: Grid precision for geo aggregations (1-12, higher = finer grid). Applied to whichever geo aggregation type is requested. datetime_frequency_interval: Interval for datetime_frequency (e.g., "month", "year", "day"). output_format: "csv" (default, sectioned CSV — ~50% fewer tokens than TOON for bucket responses), "json" (structured STAC API response), or "toon". Use "json" for deterministic/structured consumers.

Returns: Aggregation results. In CSV mode: one ## <name> section per aggregation; scalars render on a single line; bucket aggregations render as CSV with a # rows: N header, a # key=value line for columns that are constant across all rows, and a conventional CSV table of the varying columns. In JSON/TOON mode: the raw SFEOS response with name, data_type, and value/buckets for each requested aggregation.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNo
bboxNo
filterNo
licenseNo
datetimeNo
precisionNo
collectionsNo
aggregationsYes
output_formatNocsv
exclude_collectionsNo
datetime_frequency_intervalNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed12 schema fields changed
    • removedInput schema / additionalProperties
      Removed value: -false
    • removedInput schema / properties / aggregations / description
      Removed value: -"Comma-separated aggregation types (required). Valid types: total_count, datetime_max, datetime_min, datetime_frequency, collection_frequency, geometry_geohash_grid_frequency, geometry_geotile_grid_frequency."
    • removedInput schema / properties / bbox / description
      Removed value: -"Bounding box as \"west,south,east,north\"."
    • removedInput schema / properties / collections / description
      Removed value: -"Comma-separated collection IDs to scope the aggregation (e.g., \"NOAA,NDBC\")."
    • removedInput schema / properties / datetime / description
      Removed value: -"Temporal filter (same format as search_datasets)."
    • removedInput schema / properties / datetime_frequency_interval / description
      Removed value: -"Interval for datetime_frequency (e.g., \"month\", \"year\", \"day\")."
    • removedInput schema / properties / exclude_collections / description
      Removed value: -"Comma-separated collection IDs to omit from the aggregation (e.g., \"INCIDENT_NEWS\"). Applied as a CQL2 NOT filter, so it composes with `filter`."
    • removedInput schema / properties / filter / description
      Removed value: -"CQL2-JSON filter as an object or JSON-encoded string. Flat example: {\"op\": \"=\", \"args\": [{\"property\": \"aquaview:institution\"}, \"NOAA\"]}. Nested example: {\"op\": \"<=\", \"args\": [{\"property\": \"aquaview:column_stats_summary.variables.Pressure.min\"}, 10]}."
    • removedInput schema / properties / license / description
      Removed value: -"Comma-separated SPDX license id(s) to scope the aggregation (e.g., \"CC-BY-4.0,CC0-1.0\"), or one of \"public-domain\", \"proprietary\", \"various\", \"unknown\". Matched against `aquaview:license`."
    • removedInput schema / properties / output_format / description
      Removed value: -"\"csv\" (default, sectioned CSV — ~50% fewer tokens than TOON for bucket responses), \"json\" (structured STAC API response), or \"toon\". Use \"json\" for deterministic/structured consumers."
    • removedInput schema / properties / precision / description
      Removed value: -"Grid precision for geo aggregations (1-12, higher = finer grid). Applied to whichever geo aggregation type is requested."
    • removedInput schema / properties / q / description
      Removed value: -"Free-text search to scope the aggregation. Multi-word queries are tokenised on whitespace and OR-combined to mirror search_datasets semantics (aggregate compiles q to CQL2 LIKE clauses on title/description; a raw %multi word% substring match would return 0 for most queries)."
  2. Changed1 schema field changed
    • addedInput schema / properties / license
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Comma-separated SPDX license id(s) to scope the aggregation (e.g., \"CC-BY-4.0,CC0-1.0\"), or one of \"public-domain\", \"proprietary\", \"various\", \"unknown\". Matched against `aquaview:license`."
+}
  3. First observed

TDQS

A4.5/5.0
Behavior4/5

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

No annotations are provided, so the description carries full burden. It discloses the tool's behavior: it runs aggregations, composes q as CQL2 LIKE clauses, and returns various output formats. No destructive behavior is implied, so transparency is good but could mention read-only nature explicitly.

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?

The description is well-structured with a summary, parameter list, and return format explanation. It is front-loaded with purpose. However, it is somewhat lengthy due to detailed parameter explanations; could be slightly more concise.

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?

Given the tool's complexity (11 parameters, multiple aggregation types, output formats), the description covers all necessary aspects: what each parameter does, valid values, return format details, and behavioral notes. It is complete for an aggregation tool.

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 description coverage is 0%, but the description compensates thoroughly by explaining all 11 parameters with valid values, examples, and behavioral notes (e.g., q tokenization, output_format default). This adds significant meaning beyond 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?

The description clearly states the tool runs aggregation queries on the AQUAVIEW catalog, providing counts, spatial/temporal distributions, and per-collection breakdowns without fetching individual items. This distinguishes it from siblings like search_datasets (item retrieval) and list_collections (collection listing).

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?

The description explains when to use the tool for aggregations instead of fetching items. It provides parameter details and notes on composition with filters. However, it does not explicitly state when not to use it or directly compare with siblings for exclusionary guidance.

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

All AQUAVIEW MCP toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool targets a distinct operation: listing collections, searching datasets, fetching item details, and running aggregations. No functional overlap.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern: list_collections, search_datasets, get_item, aggregate.

Tool Count5/5

Four tools cover the core operations of a catalog server without being excessive or insufficient. The scope is well-defined.

Completeness5/5

The tool set provides a complete read-only interface: list collections, search with filters, retrieve items with assets, and aggregate statistics. No obvious gaps.

Resources