AQUAVIEW MCP

list_collections

List all available AQUAVIEW data collections (sources).

Returns a summary of each collection with ID, title, description, spatial/temporal extent, and keywords. Use collection IDs to filter searches.

These are CATALOG collections. Several are also queryable row by row — see list_data_sources for the sources get_data can pull observations from.

A collection's bbox and temporal range are OUTER BOUNDS, not a promise of coverage. They are the envelope around everything in the collection, so most of the box usually holds no data at all — an Argo collection spans the global ocean, a partner collection with one point either side of the date line spans the whole planet. An empty result for a point or window inside the extent is the normal answer, not a failure: report "no data there", not "the query did not work", and do not widen a search on the strength of a bbox alone.

Args: tag: Only collections with this tag, e.g. "uxs" for uncrewed systems. Pass the returned IDs as collections to search_datasets to search only those. output_format: "csv" (default, sectioned CSV — ~20% fewer tokens than TOON for this tabular response), "json", or "toon". Use "json" for deterministic/structured consumers.

Returns: List of collections with count. CSV mode emits a single ## collections section with columns id,title,bbox,temporal,keywords,description; bbox is rendered as "west,south,east,north"; temporal as "min|max"; keywords ";"-joined.

Input Schema

Name	Required	Description	Default
`tag`	No
`output_format`	No		csv

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 7, 2026

addedInput schema / properties / tag

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

Changed2 schema fields changedJul 17, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```

removedInput schema / properties / output_format / description

Removed value: -"\"csv\" (default, sectioned CSV — ~20% fewer tokens than TOON for this tabular response), \"json\", or \"toon\". Use \"json\" for deterministic/structured consumers."

First observedMay 9, 2026

TDQS

A4.6/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 behavioral burden and does so with non-obvious, high-value detail: bbox/temporal are OUTER BOUNDS, not coverage promises, and an empty result inside the extent is the normal answer rather than a failure. It also warns not to widen a search on bbox alone, which directly prevents a common agent error.

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 the core purpose and scope, and every section earns its place. There is mild redundancy between the summary sentence listing fields (ID, title, description, extent, keywords) and the Returns section repeating the CSV column list, which slightly inflates length.

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?

Given an output schema exists, the detailed Returns block partially duplicates structured data, but the description still covers everything an agent needs: purpose, sibling routing, parameter semantics, and the critical extent-is-envelope behavior. Only minor gaps remain (no pagination or auth notes, though neither appears relevant here).

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%, so the description must compensate, and it does: `tag` is documented with an example ('uxs') and its downstream use as `collections` in search_datasets, and `output_format` explains the csv default, token tradeoff, and when to choose json. Both parameters gain meaning beyond the bare enum/string 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?

States a specific verb and resource ('List all available AQUAVIEW data collections') and explicitly distinguishes the resource from siblings by noting these are CATALOG collections and pointing to list_data_sources for queryable sources. An agent can tell it apart from search_datasets, get_data, and list_data_sources 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 Guidelines4/5

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

Gives clear routing: pass returned IDs as `collections` to search_datasets to filter, and see list_data_sources for sources get_data can pull from. It explains the downstream use well but states no explicit exclusions or when-not-to-use conditions beyond the sibling pointer.

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

All AQUAVIEW MCP 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?