gdex-mcp

find_dataset_files

Search a dataset's file-group hierarchy for files matching a name pattern (e.g. a date like "20220808"), without ever pulling a large, context-blowing file listing.

Automates the pattern described in get_file_groups: recursively calls
get_file_groups, descending into every child gindex, until a gindex
returns no further children (a leaf group) — then calls get_dataset_files
there with filter_wfile=name_pattern and keeps only the matches. Prefer
this over manually drilling with get_file_groups/get_dataset_files when
you don't already know roughly where in the hierarchy to look.

A dataset's hierarchy can be large (hundreds of leaf groups), and this
tool has no way to know in advance which branches might contain a match,
so it may need to visit many groups to be thorough. Pass start_gindex if
you already know a good starting point (e.g. from a prior get_file_groups
call, or a related dataset's structure) to narrow and speed up the
search. If the number of groups visited hits max_groups_visited, the
search stops early and `stopped_early` comes back true — narrow with
start_gindex and retry, or raise the cap.

Args:
    dsid: Dataset ID (dNNNNNN), e.g. d083002
    name_pattern: Filename substring/pattern to match, e.g. "20220808" for a date
    start_gindex: Optional group index to start the search from, instead of the dataset root
    max_groups_visited: Safety cap on groups traversed before giving up (default 300)

Input Schema

TableJSON Schema

Name	Required	Description	Default
`dsid`	Yes
`name_pattern`	Yes
`start_gindex`	No
`max_groups_visited`	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 description carries full burden and does so well: it discloses the recursive traversal behavior, the avoidance of large listings, the possibility of visiting many groups, the early-stop cap, and the stopped_early result flag. This is rich operational detail that annotations would otherwise need to provide.

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?

Although longer than average, every section earns its place: purpose, internal algorithm, usage condition, caveat, start_gindex guidance, early-stop behavior, and parameter details. The single minor redundancy in the example date is not enough to reduce the score.

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?

The description covers the tool's purpose, algorithm, usage context, failure/edge behavior, and all parameter semantics. Since an output schema exists, the description need not enumerate return fields, and nothing decision-relevant appears 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%, and the description fully compensates. It defines each parameter with concrete examples and semantics: dsid as 'Dataset ID (dNNNNNN), e.g. d083002', name_pattern as a substring/pattern, start_gindex as an optional root alternative, and max_groups_visited as a safety cap with its default.

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 uses a specific verb and resource: 'Search a dataset's file-group hierarchy for files matching a name pattern.' It also distinguishes itself from siblings by explicitly contrasting with get_file_groups and get_dataset_files, so an agent can identify what this tool uniquely does.

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 selection guidance: 'Prefer this over manually drilling with get_file_groups/get_dataset_files when you don't already know roughly where in the hierarchy to look.' It also explains when to pass start_gindex and what to do if max_groups_visited is hit, making the when/alternative decision clear.

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.