gdex-mcp

get_file_groups

Return file groups for a dataset. Pass gindex to get child groups under a parent.

Groups nest (dataset -> format -> year -> month, or similar, varying by
dataset) and there's no way to predict a child's gindex in advance — each
group's gindex/url is dataset-specific and only knowable from the parent
response. To drill down, read the gindex (or url) off a row in this
response and pass that as the next call's gindex.

This never returns file rows, only groups — every response stays small
regardless of how many files the dataset holds, unlike get_dataset_files.
Descend until a call returns empty ({} or []): that means the gindex you
just called with is a leaf with no further subgroups, so it's safe to
call get_dataset_files there for the actual files. find_dataset_files
automates exactly this walk if you'd rather not do it by hand.

At the top level, watch for a "Kerchunk Reference Files" (or similar
ARCO-related) group alongside the raw-format groups. For an analysis
task, prefer pulling from there (see also has_arco/get_arco_variables)
over a raw data file when one's available — it avoids downloading a
whole file just to read a subset of it.

Args:
    dsid: Dataset ID (dNNNNNN), e.g. d083002
    gindex: Optional group index to fetch child groups

Input Schema

TableJSON Schema

Name	Required	Description	Default
`dsid`	Yes
`gindex`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 24, 2026

TDQS

A5/5.0

Behavior5/5

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

With no annotations, the burden is on the text. It fully discloses that only groups are returned, responses stay small, gindex values are unpredictable/dataset-specific, empty responses indicate leaf nodes, and the top level may include ARCO-related groups. This goes well beyond basic mutation/read cues.

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?

Though longer than typical, every sentence contributes: first line states purpose, subsequent paragraphs explain traversal, leaf detection, sibling alternatives, and ARCO recommendation, closing with clean Args. It is front-loaded and well-organized.

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?

Given the tool's hierarchical complexity and only two parameters, the description covers the entire workflow: how to start, how to recurse, how to know when to stop, which sibling to call next, and which group variant to prefer. The presence of an output schema removes the need to document return values.

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 alone explains both parameters. It gives a precise dsid format (dNNNNNN) with example d083002 and defines gindex as an optional group index whose value must be taken from the parent response.

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 description opens with a specific verb and resource ('Return file groups for a dataset') and clarifies the recursion via gindex into child groups. It also names sibling tools (get_dataset_files, find_dataset_files) and differentiates the group-only scope from file listing.

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 explicit walk-through: call, read gindex/url from parent response, pass it next, stop at empty return, then use get_dataset_files. It also points to find_dataset_files as an automation alternative and recommends the Kerchunk group for analysis over raw data.

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

All gdex-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.