Skip to main content
Glama

get_data

Pull actual observation rows from an AQUAVIEW data source — not catalog metadata.

Use this whenever the question needs the measurements themselves (temperature profiles, float positions, buoy readings), rather than which datasets exist. Call list_data_sources first for a source's canonical variable names, its qc_modes, and its engine (gridded "xarray" sources have no rows to pull).

READ 'returned' FIRST. It is one of three values:

  • 'complete': 'rows' holds EVERY matching row (or your whole 'limit'). Safe to compute anything from.

  • 'head': 'rows' holds the FIRST rows in the source's natural order (see 'head.order'), out of 'head.of' total. These are not a random sample — later rows differ systematically — so never average or take a maximum from them. To get more, set 'limit' up to 'head.max_inline'; beyond that, narrow the request or fetch 'download_url'.

  • 'none': no rows. 'refusal.reason' says why. 'unscoped_query' means add a bbox/datetime/depth/filter. 'no_natural_order' means the source has no column to order a partial read by, so no partial set can be given honestly — narrow until it fits, or use 'stats'. The rest are transient; retry.

OTHER FIELDS:

  • 'stats': exact minimum, maximum, mean and spread computed over EVERY matching row. Use these for any numeric claim — exact at any data size.

  • 'stats_basis': what shaped those numbers. If 'qc' is null the values are UNSCREENED and may include implausible outliers from bad sensor readings; say so, or re-run with a quality filter. When a mode was applied, 'qc_screened' lists the variables it actually checked — a variable not in it was NOT flag-checked, and an empty list means nothing was screened despite 'qc' naming a mode. 'qc_note', when present, explains that the screen drops whole rows, so it shapes every variable's figures.

  • 'structure': how many distinct floats/stations/profiles matched — often the real answer ("16 profiles from 5 floats"), which no row count gives.

  • 'sample': a genuinely random sample, included only when rows were withheld. For seeing what the data looks like — do NOT compute from it.

  • 'download_url': the full result as a file, in 'download_format'. Fetch it if you can run code; otherwise give it to the user. Absent for restricted sources and for matches too large to stage synchronously.

  • 'schema': each column's real type. Needed when reading the CSV download, which stores no types — without it a reader infers them and can get them wrong (an id column read as a number loses leading zeros).

  • 'omitted': names any part that could not be computed. An absent field is unknown, NOT zero.

Args: source: Source id from list_data_sources (e.g. "gadr", "wod", "ndbc"). variables: Comma-separated canonical variable names (e.g. "temperature,salinity,depth"). bbox: Bounding box "west,south,east,north" (e.g. "-161,18,-154,23"). datetime: ISO-8601 instant or range ("2022-06-01/2022-06-30"; ".." for an open end). depth: Depth range in metres below surface, "min,max" (e.g. "0,200"). filters: JSON object of extra column filters on ordinary columns, e.g. {"data_mode": "D"}. For QUALITY screening prefer qc below — a source that defines modes applies them to each measurement correctly, where filtering a raw flag column yourself is easy to get wrong. qc: Named quality mode, and the right way to screen. Unfiltered ocean data contains sentinel values that make maxima and means physically implausible, so screen before any scientific claim. list_data_sources reports each source's qc_modes; pass one of those here. Passing a mode to a source with none is an error. A source with no modes may still expose per-measurement quality columns you can filter directly via filters — list_data_sources shows its variables. limit: Maximum rows to return, honored up to what fits inline. Omit for a default-sized head. When a response comes back as a head, head.max_inline tells you the largest limit worth asking for on that request. format: Encoding of download_url. Default "parquet" — it keeps every column's type, is ~5x smaller and ~2x faster, and pd.read_parquet(url) reads it. Choose "csv" when the link is going to a person who will open it by hand rather than into code, or when you can fetch a URL but cannot run code; then use schema to set the column types yourself. include_sample: Set False to skip the random sample and return slightly faster. output_format: 'csv' (compact, default), 'json', or 'toon'.

Input Schema

NameRequiredDescriptionDefault
qcNo
bboxNo
depthNo
limitNo
formatNoparquet
sourceYes
filtersNo
datetimeNo
variablesYes
output_formatNocsv
include_sampleNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.9/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 explains the three-valued 'returned' contract, warns that 'head' rows are order-biased and must never be averaged or maximized, lists refusal reasons with remedies, and flags that unscreened qc values may be implausible and that absent fields mean unknown rather than zero. This is exactly the behavioral context a caller needs before trusting results.

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?

Heavily front-loaded with 'READ 'returned' FIRST' and organized under labeled sections, so it scans well. It is nonetheless long, and the 'OTHER FIELDS' block re-describes return fields that an output schema already covers, which is more verbosity than strictly required.

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 an 11-parameter, no-annotation tool with a rich result contract, the description covers invocation, filtering, screening, truncation behavior, and download paths. Nothing an agent needs to call it correctly or interpret the response appears to be missing.

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% across 11 parameters, so the description must compensate and it does for every arg: formats for bbox, datetime (including '..' open ends), depth, filters JSON, and the qc/limit/format semantics. It adds meaning beyond the schema's bare types, e.g. why to prefer 'qc' over filtering a raw flag column, and when to pick csv vs parquet.

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 opening line states a specific verb+resource ('Pull actual observation rows from an AQUAVIEW data source') and explicitly negates the sibling category ('not catalog metadata'), which cleanly separates it from list_data_sources/search_datasets. An agent can route to it without opening the 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?

It gives an explicit trigger ('whenever the question needs the measurements themselves'), a prerequisite ('Call list_data_sources first for canonical variable names, qc_modes, engine'), and routes the agent away from unusable sources ('gridded "xarray" sources have no rows to pull'). Alternatives are named for edge cases ('narrow until it fits, or use stats').

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources