Oceanum MCP

Official

by oceanum-io

Overview Schema Source Related Servers Discussions Admin

Python

Remote

Datamesh Query Data

datamesh_query_data

Read-only

Query a datasource and return small results inline.

Instructions

Query a datasource and return small results inline.

The query is staged first; results larger than the inline limit are not downloaded (datasets are summarized lazily, tabular queries are refused with alternatives), and results above 1 GB are refused with narrowing advice and each variable's dims, unless limit is combined with time_resolution/aggregate_operations (the limited slice may be small, so a dataset is then opened lazily). Use stage_query to size a query before calling this.

Inline values are a preview when preview is true (returned of total records): never compute statistics from a preview; use aggregate_operations or time_resolution instead.

limit keeps the last N records (Datamesh semantics: the last N steps along time/ensemble). Combined with time_resolution or aggregate_operations, limit is applied by this server AFTER resampling/aggregation (to the last N resampled steps, or the last N rows of a table) rather than sent to Datamesh. A limited result is a subset of the requested range, so it is flagged as a preview, with a limit_note.

A variable given as the exact CF standard_name of exactly one of the datasource's variables (e.g. "sea_surface_wave_significant_height" for "hs") is resolved to that variable; the response then includes resolved_variables ({requested: used}) and echoes the resolved names.

Input Schema

Name	Required	Description
`crs`	No	CRS for filter coordinates and returned data (EPSG code or CRS string).
`bbox`	No	Bounding box [xmin, ymin, xmax, ymax] in WGS84 (or crs units if crs is set).
`limit`	No	Keep only the last N records (Datamesh semantics: the last N steps along time/ensemble). Combined with time_resolution or aggregate_operations it is applied AFTER resampling/aggregation (by this server, not sent to Datamesh), so stage_query sizes the unlimited result as an upper bound; hosted export_query refuses that combination.
`times`	No	Discrete times to select (series selection). Mutually exclusive with time_start/time_end.
`levels`	No	Discrete vertical levels to select (series selection). Mutually exclusive with level_min/level_max.
`time_end`	No	ISO 8601 end of a time range. Open-ended if omitted.
`level_max`	No	Maximum vertical level of a range.
`level_min`	No	Minimum vertical level of a range.
`variables`	No	List of variable names to select (e.g. ["temperature", "salinity"]).
`time_start`	No	ISO 8601 start of a time range (e.g. "2023-01-01T00:00:00Z"). Open-ended if omitted.
`level_interp`	No	Interpolation for level series selection: nearest or linear.
`coord_filters`	No	Additional coordinate selections, e.g. [{"coord": "station", "values": ["A1", "B2"]}].
`datasource_id`	Yes	The datasource to query.
`time_resample`	No	Resampling method when time_resolution is set: mean, nearest, or linear.
`time_resolution`	No	Downsample a time range server-side to this resolution (pandas frequency string, e.g. "1h", "6h", "1D", "7D", or "30D" for roughly monthly). Drastically shrinks long time series. Monthly/quarterly/yearly calendar aliases (MS, ME, QS, YS) are not supported until a Datamesh engine fix ships: use "30D", "90D" or "365D". Finer than 1 minute is refused.
`geofilter_interp`	No	Interpolation for feature selection: nearest or linear (default linear).
`aggregate_spatial`	No	Aggregate over spatial dimensions (default true).
`geofilter_feature`	No	GeoJSON Feature object (Point, MultiPoint, or Polygon geometry) for spatial selection/interpolation. Mutually exclusive with bbox.
`aggregate_temporal`	No	Aggregate over the temporal dimension (default true).
`aggregate_operations`	No	Aggregations to apply after filtering: mean, min, max, std, sum.
`geofilter_resolution`	No	Maximum spatial resolution for downsampling, in CRS units.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.5.2Oct 16, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Despite annotations already signaling a read-only, open-world operation, the description adds extensive behavioral detail: staging happens first, oversized results are refused with narrowing advice, tabular queries may be refused, limited results are flagged as previews, and variable resolution is reported via resolved_variables. None of this contradicts the annotations.

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 most important constraints — small inline results, staging, size refusals, and preview warnings — are front-loaded. The description is long but largely earns its length for a 21-parameter tool, though some limit and resampling details duplicate the schema.

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 the complex schema, annotations, and available output schema, the description covers the critical operational behavior: sizing, refusal conditions, preview limitations, and variable resolution. It could be more complete by explicitly directing large-result use cases to export_query, but nothing essential for correct invocation is missing.

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 all 21 parameters thoroughly, including limit and time_resolution interactions. The description adds meaningful semantics for CF standard_name variable resolution and preview behavior, but much of its parameter discussion repeats what is already in the schema.

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 states a specific verb and resource — query a datasource and return small results inline — and clarifies the inline-size scope. It also mentions stage_query for sizing, but does not explicitly distinguish this tool's purpose from the sibling export_query, leaving some sibling selection ambiguity.

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 gives clear operational context: use stage_query before calling, previews should not be used for statistics, and aggregate_operations or time_resolution should be used instead. It also explains when large results are refused, but it does not explicitly name export_query as the alternative for larger exports, leaving one key routing decision implicit.

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

Deploy Server