Skip to main content
Glama

get_dataset_info

Read-onlyIdempotent

Get full metadata for a specific dataset including title, description, publisher (World Bank, FRED, Eurostat, OECD, WHO, IMF, ECB, US Census, SEC, or your own connector), category, keywords, row count, creation date, AND ontology fields (topic, subtopic, unit, frequency, entity_type, indicator_id, source_time_col, source_value_col, source_entity_col, data_granularity). The unit field carries the canonical measurement label (e.g. "Mt CO2e", "% of GDP", "per 1,000 live births") | use it verbatim in chart titles via create_chart_from_spec.title. Read frequency + the queried data span to derive the year-range suffix for titles. On one of YOUR private or derived tables (a connector report, an upload, marketing_daily, an app result) it also carries lineage: upstream = where the table comes from (connector + report, upload, app result, the tables a derived one folds) and downstream = what reads it (derived tables, apps, charts, project KPIs, its share), each node with kind, label and the autario page. A table shared with you shows only the kind of each source.

Input Schema

NameRequiredDescriptionDefault
formatNoOutput wire format for this MCP call. Default 'toon' (Token-Oriented Notation, fewest tokens, best for tabular rows). 'compact' = minified JSON. 'json' = pretty JSON for readability. The REST API always returns JSON regardless.
dataset_idYesThe UUID of the dataset to retrieve metadata for

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / format / description
      Previous value: -"Output wire format. 'compact' (default) = minified JSON, token-efficient. 'json' = pretty JSON for readability. 'toon' = Token-Oriented Notation, fewest tokens for tabular rows."New value: +"Output wire format for this MCP call. Default 'toon' (Token-Oriented Notation, fewest tokens, best for tabular rows). 'compact' = minified JSON. 'json' = pretty JSON for readability. The REST API always returns JSON regardless."
    • changedInput schema / properties / format / enum
      Previous value: -[
      -  "compact",
      -  "json",
      -  "toon"
      -]New value: +[
      +  "toon",
      +  "compact",
      +  "json"
      +]
  2. Changed1 schema field changed
    • addedInput schema / properties / format
      Added value: +{
      +  "description": "Output wire format. 'compact' (default) = minified JSON, token-efficient. 'json' = pretty JSON for readability. 'toon' = Token-Oriented Notation, fewest tokens for tabular rows.",
      +  "enum": [
      +    "compact",
      +    "json",
      +    "toon"
      +  ],
      +  "type": "string"
      +}
  3. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already establish that this is a safe, idempotent read operation. The description adds meaningful behavioral detail beyond annotations, especially that private or derived tables include `lineage` with upstream and downstream nodes while shared tables show only source kinds. It also explains the meaning of key returned fields, which is valuable because there is no output schema.

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

Conciseness3/5

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

The purpose is front-loaded and the lineage caveat is useful, but the description is a dense run-on with long field enumerations and chart-title advice. Some of that guidance is helpful, but it could be separated or trimmed for faster scanning. It is adequately structured but not efficiently 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?

There is no output schema, so the description must carry the burden of explaining returned data, and it does so thoroughly by listing metadata fields, ontology fields, and lineage behavior. It covers private versus shared table differences clearly. It is complete enough for an agent to call and interpret the result, though it could be organized more cleanly.

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%, and both parameters are documented in the schema. The description does not add further meaning about `dataset_id` or the `format` enum. With the schema already doing the parameter documentation, the baseline of 3 is appropriate.

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 and resource: get full metadata for a specific dataset. It clearly scopes what is returned, including ontology fields and lineage. It does not explicitly distinguish itself from close siblings such as get_dataset_schema or search_datasets, so it stops short of a 5.

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?

The description gives downstream usage advice, such as using `unit` verbatim in chart titles and deriving title suffixes from `frequency` plus the queried span. However, it does not say when to choose this tool over alternatives like get_dataset_schema or search_datasets. Usage is implied by the purpose rather than selected explicitly.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources