Skip to main content
Glama

get_related_datasets

Read-only

Find similar datasets in the same category by dataset ID, ranked by tag overlap, to cross-reference data, discover alternatives, or enrich analysis.

Instructions

Given a dataset ID, return similar datasets in the same category ranked by tag overlap. Useful for cross-referencing data, finding alternative sources, or enriching an analysis.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoNumber of related datasets to return (default 5)
dataset_idYesThe dataset to find relatives for

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.5.1

TDQS

A3.6/5.0
Behavior3/5

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

readOnlyHint=true already tells the agent this is a safe read. The description usefully adds that results are constrained to the same category and ordered by tag overlap, but says nothing about result count, pagination, or what fields come back. Comparable in weight to the scoping constraint credited in the calibration example.

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?

Two tight sentences with the core behavior front-loaded and the ranking criterion immediately after. Every clause carries information; there is no filler or restatement of the tool name.

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?

For a simple read-only lookup with no output schema, the description covers input semantics, scope, and ranking, which is enough to call it correctly. It could be slightly more complete by noting the result cap or that results are lightweight references, but nothing essential is missing.

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 description coverage is 100%, so both dataset_id and limit are already documented in the schema, including the default of 5 and the 1-20 range. The description restates the dataset_id input but adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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 names a specific verb and resource ('return similar datasets') and adds a concrete mechanism ('same category ranked by tag overlap'), which clearly separates it from a plain get_dataset or search_datasets lookup. It stops short of naming any sibling explicitly, so differentiation still requires the agent to reason about it.

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 offers motivation ('useful for cross-referencing data, finding alternative sources, or enriching an analysis') rather than routing guidance. It never says when to prefer this over search_datasets or find_data_for_task, and states no exclusions or prerequisites, so usage is only implied.

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