AQUAVIEW MCP
Server Details
AQUAVIEW MCP is a hosted Model Context Protocol server that gives any LLM agent direct access to 700,000+ oceanographic, atmospheric, and marine datasets from 68 authoritative sources — NOAA, IOOS, World Ocean Database, Argo, GOES-R, NEXRAD, ESA Sentinel, and more. Ask in plain English; the server returns structured results with direct download links for NetCDF, GRIB2, GeoTIFF, and CSV files.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 4 of 4 tools scored.
Each tool has a clearly distinct purpose: search, list collections, fetch item, and aggregate. No overlap or confusion between them.
All tool names follow a consistent verb or verb_noun pattern (aggregate, get_item, list_collections, search_datasets), all in snake_case.
4 tools is slightly minimal for a catalog, but it covers the essential operations (search, list, get, aggregate) without being too sparse.
Covers main STAC-like operations but lacks a dedicated get_collection endpoint; list_collections provides summaries, which may suffice. Minor gap.
Available Tools
4 toolsaggregateAInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| bbox | No | ||
| filter | No | ||
| license | No | ||
| datetime | No | ||
| precision | No | ||
| collections | No | ||
| aggregations | Yes | ||
| output_format | No | csv | |
| exclude_collections | No | ||
| datetime_frequency_interval | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: explains the read-only nature, parameter effects (e.g., q tokenisation, CQL2 semantics), output format characteristics (CSV token efficiency, JSON structure), and valid aggregation types. No contradictions or omissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args and Returns sections, but slightly verbose with some redundant explanations (e.g., q semantics repeated). Every sentence adds value, but minor trimming could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 11 parameters, 1 required, and an output schema, the description covers all aspects: input semantics, output format details, aggregation types, and edge cases (e.g., q tokenisation, CQL2 filter). Fully sufficient for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description extensively explains all 11 parameters with examples, valid values, and constraints (e.g., aggregations types, q tokenisation, filter format, output_format enum). This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs aggregation queries on the AQUAVIEW catalog, listing specific aggregation types (counts, spatial/temporal distributions, per-collection breakdowns) and contrasting with fetching individual items. This distinguishes it from sibling tools like search_datasets and get_item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining aggregated statistics without fetching items but does not explicitly state when to use this tool over alternatives like search_datasets. No direct when-not or comparisons to siblings are provided, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_itemAInspect
Fetch a single AQUAVIEW dataset item with full details, properties, and download links (assets).
STAC items embed assets inline — each asset includes an href (download URL) and media type, so there is no need for a separate "files" call.
Args: collection: The collection ID the item belongs to (e.g., "NOAA", "NDBC", "WOD"). Available from search results or list_collections. item_id: The unique item identifier (e.g., "wod_xbt_ZZ144579"). Available from search results. output_format: "toon" (default) or "json".
Returns: Full STAC item with geometry, properties (title, description, datetime, institution, variables, etc.), and assets (download links with media types).
| Name | Required | Description | Default |
|---|---|---|---|
| item_id | Yes | ||
| collection | Yes | ||
| output_format | No | toon |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description mentions that the tool fetches a single item and returns STAC items with assets. It does not disclose potential errors, authentication requirements, or rate limits. However, for a read-only fetch, the description is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an opening summary, then Args and Returns sections. It is front-loaded and concise, though slightly verbose with the STAC explanation. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters and an output schema exists, the description covers the purpose, parameters, and return structure. It explains the STAC item format and assets, making it complete for a single-item fetch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds significant meaning: it provides examples for collection (e.g., 'NOAA') and item_id (e.g., 'wod_xbt_ZZ144579'), explains output_format defaults to 'toon', and states where to get these values. This compensates well for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch a single AQUAVIEW dataset item with full details, properties, and download links (assets).' It uses a specific verb ('fetch') and resource, and differentiates from sibling tools like search_datasets or list_collections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that assets are embedded inline, so no separate 'files' call is needed. It also tells where to obtain collection and item_id ('from search results or list_collections'). It doesn't explicitly state when to use this tool over alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_collectionsAInspect
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.
Args: 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.
| Name | Required | Description | Default |
|---|---|---|---|
| output_format | No | csv |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explains the return format and fields but does not explicitly state that the operation is read-only, idempotent, or free of side effects. While listing is generally understood as safe, the absence of explicit disclosure is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, return details, and argument explanations. However, the return format is described both in text and presumably in an output schema, leading to slight redundancy. Still, it is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one optional parameter, output schema exists), the description covers the tool's purpose, parameter usage, and return structure comprehensively. It does not mention error cases or empty results, but these are minor omissions for a listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter output_format is thoroughly described beyond the schema: it explains that csv is token-efficient (~20% fewer tokens than toon), json is for deterministic consumers, and the default is csv. This adds significant value beyond the enum and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all available AQUAVIEW data collections (sources). It specifies the verb 'list' and the resource 'collections', and the context from sibling tools (search_datasets, get_item) helps differentiate its purpose as a high-level listing tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions using the output_format based on needs (csv for token efficiency, json for structured consumers) and hints that collection IDs from this tool are used to filter searches. It lacks explicit statements about when not to use this tool versus siblings, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_datasetsAInspect
Search the AQUAVIEW catalog — a comprehensive collection of 268K+ global oceanographic, atmospheric, and marine datasets from 15 sources (NOAA, NDBC, IOOS, WOD, CoastWatch, etc.), intended for scientific research, data analysis, and environmental monitoring.
You must provide at least one of: q, bbox, datetime, collections, filter, or token. Hint: When the user asks for a region, prefer the 'bbox' parameter over including region name in 'q'. Use the geo_hints resource for common bounding boxes.
Args:
q: Free-text search across title, description, and keywords (e.g., "sea surface temperature"). Case-insensitive, OR logic across terms.
bbox: Bounding box as "west,south,east,north" (e.g., "-98,24,-80,31" for Gulf of Mexico).
datetime: Temporal filter. Single datetime, range ("2020-01-01T00:00:00Z/2024-12-31T23:59:59Z"), or open-ended ("../2024-01-01T00:00:00Z" or "2020-01-01T00:00:00Z/..").
collections: Comma-separated collection IDs to search within (e.g., "NOAA,NDBC,WOD"). Use list_collections to see available IDs.
exclude_collections: Comma-separated collection IDs to omit from results (e.g., "INCIDENT_NEWS" to drop oil-spill reports from free-text searches). Applied as a CQL2 NOT filter, so it composes with filter.
filter: CQL2-JSON filter as an object or JSON-encoded string. Supports flat and nested property paths. Flat example: {"op": "=", "args": [{"property": "aquaview:institution"}, "NOAA/NCEI"]}. Nested example (filter by per-variable stats summary): {"op": "<=", "args": [{"property": "aquaview:column_stats_summary.variables.Pressure.min"}, 10]}. Supported operators: =, <>, <, >, <=, >=, like, between, in, and, or, not.
license: Comma-separated SPDX license id(s) to match exactly (e.g., "CC-BY-4.0,CC0-1.0"). Also accepts the controlled extra values "public-domain", "proprietary", "various", "unknown". Matched against aquaview:license, which is normalized on every item regardless of source.
sortby: Sort specification as "+field,-field" (e.g., "+properties.datetime,-id"). + = ascending, - = descending.
limit: Number of results to return, 1-100. Defaults to 10.
token: Pagination token from a previous response's 'next_token' field. Pass this to get the next page of results.
fields: Comma-separated list of fields to include in results (e.g., "id,geometry,properties.title"). Reduces response size. When set in CSV mode, emits projected columns (no canonical columns, no asset_keys, no ## assets section).
include_assets: If False (default), asset download records are omitted to save ~60-70% of response tokens; CSV mode still emits a capped asset_keys hint column (e.g. column_stats;overview;gdac_prof;+[N]) so an agent can see what kinds of assets exist. To get full URLs, call get_item(collection, item_id) for the specific id. If True, assets are included inline (full dict for JSON/TOON; ## assets section with item_id,key,href,type,title rows for CSV).
output_format: "csv" (default, sectioned CSV — canonical columns including asset_keys hint), "json", or "toon".
Returns:
Search results with metadata (total matched, returned, next_token) and items.
CSV mode emits ## metadata + ## items sections and a ## assets section
when include_assets=True; columns are id,collection,bbox,datetime,title,institution,
platform_type,cdm_data_type,variables,keywords,source_url,description,
column_stats_summary,geometry,asset_keys. JSON/TOON return the STAC feature shape,
with the assets dict present only when include_assets=True.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| bbox | No | ||
| limit | No | ||
| token | No | ||
| fields | No | ||
| filter | No | ||
| sortby | No | ||
| license | No | ||
| datetime | No | ||
| collections | No | ||
| output_format | No | csv | |
| include_assets | No | ||
| exclude_collections | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It does not mention read-only operation, side effects, authentication, or rate limits. The only hint is that it searches, but this is insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with intro, hints, Args, and Returns. Front-loaded with purpose. Some redundancy in Returns section (e.g., explaining CSV columns when output schema exists), but overall efficient and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all 13 parameters with usage details, explains output formats and fields, and provides guidance on parameter combinations. Complete for an agent to effectively use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema lacks parameter descriptions (0% coverage). The description's Args section provides detailed explanations, examples, and constraints for each of the 13 parameters, fully compensating for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the AQUAVIEW catalog of 268K+ oceanographic datasets, specifying the verb 'search' and resource. It differentiates from siblings like aggregate, get_item, and list_collections by its search-focused role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly requires at least one of q, bbox, datetime, collections, filter, or token. Provides hints like preferring bbox over q for region queries and directing to geo_hints resource. This guides correct selection of parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!