Skip to main content
Glama

gdex-mcp

by io.github.rpconroy
OverviewDiscussionsAdmin

list_datasets

List datasets available on GDEX, with their IDs and titles.

The full catalog has ~1700 datasets — far too many to return at once.
Always pass `query` to filter by keyword unless the user specifically
wants to browse the whole catalog page by page.

Args:
    query: Keyword(s) to filter by, matched case-insensitively as a substring
           against dataset id and title. Leave empty to browse unfiltered.
    limit: Max number of datasets to return (default 50, capped at 500)
    offset: Number of matching datasets to skip, for paging through results

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
queryNo
offsetNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses the large catalog size (~1700 datasets) and the need to filter, which is useful behavioral context. However, it doesn't mention authentication, rate limits, or other potential behaviors. It does explain the default limit and cap, but could be more thorough given no annotation support.

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 description is well-structured: a clear opening sentence, a practical note about catalog size and filtering guidance, and a compact Args block. It's not overly verbose and every sentence serves a purpose, though the Args section could be slightly more concise.

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 tool's simplicity and the presence of an output schema, the description covers the essential usage: parameters, filtering, paging, and the reason for filtering. It doesn't explain return format (covered by output schema) or prerequisites, but it's complete enough for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It does so with an 'Args' section explaining each parameter: query (case-insensitive substring match against id and title), limit (default 50, cap 500), and offset (paging). This adds meaning beyond the bare schema definitions.

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 clear verb and resource: 'List datasets available on GDEX, with their IDs and titles.' This is specific and not a tautology. It distinguishes from sibling tools like describe_dataset or get_dataset_metadata, though it doesn't explicitly name them, the purpose is unambiguous.

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?

The description gives explicit guidance: 'Always pass `query` to filter by keyword unless the user specifically wants to browse the whole catalog page by page.' It also explains paging with limit and offset. It doesn't mention when to use alternative tools, but the context of catalog listing vs. specific dataset retrieval is clear from the purpose.

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

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

Resources