Skip to main content
Glama
Sign In
erddap-mcp

erddap-mcp

by mrfentmen
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

query_tabledap

Queries ERDDAP tabular datasets such as sensor, buoy, float, and glider observations by variables, time range, optional lat/lon bounds, and extra constraints.

Instructions

Query a tabular dataset (sensors, buoys, floats, gliders): variables + time range + optional lat/lon box and extra constraints.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "query_tabledap"
  }
}

Input Schema

NameRequiredDescriptionDefault
serverNoServer nickname or URL.
lat_maxNoOptional latitude upper bound.
lat_minNoOptional latitude lower bound.
lon_maxNoOptional longitude upper bound.
lon_minNoOptional longitude lower bound.
distinctNoDeduplicate rows (default false).
max_rowsNoMax rows shown (default 50, hard cap 500).
time_maxNoISO end.
time_minNoISO start, e.g. 2026-10-20T00:00:00Z.
variablesNoVariables to return, e.g. ['station','WTMP']. Must include 'time' for time-series data.
dataset_idNoDataset ID.
constraintsNoOptional extra filters as {variable: 'op value'} pairs, e.g. {'WTMP': '!=NaN'} — operators = != < > <= >= =~ .

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

No annotations are supplied, so the description carries the full burden. 'Query' implies a read-only operation and the schema's max_rows note discloses the hard cap of 500 rows, but nothing in the description states error behavior, whether a server/dataset must pre-exist, or how results are limited/truncated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence naming the resource first, then the composable query parts with optionality marked parenthetically. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter tool with a nested object, no annotations, and no output schema, the description is thin: it does not clarify that server and dataset_id are effectively required despite zero declared required parameters, nor what the response looks like. The schema does much of the work, but the ambiguity around practical required inputs is left unaddressed.

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 coverage is 100%, so every parameter including the nested constraints operator syntax is already documented. The description only restates the grouping of parameters (variables, time range, lat/lon box, constraints) without adding format or precedence details beyond 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 (query) and resource (tabular dataset) and enumerates the entity types it covers (sensors, buoys, floats, gliders) plus the query dimensions. That makes it distinguishable from the sibling query_griddap at a high level, though it never names the sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

It implies usage by listing what can be combined (variables + time range + optional lat/lon box and constraints) and marks which parts are optional, but it gives no explicit when-to-use versus query_griddap, search_datasets, or dataset_info.

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

Deploy Server

Other Tools