Skip to main content
Glama
nescoffee-create

SDMX MCP Gateway

get_metadata_attribute

Get every value of a reference metadata attribute with the applicable dimension slice, providing the detailed breakdown when summary metadata indicates more detail is available.

Instructions

Get every value of one reference metadata attribute, with the slice each applies to.

Use after get_reference_metadata() reports drill_down=true for an
attribute, which means more detail remains than the summary shows. This
can happen because the attribute's values differ across the dataflow (for
example recommended-uses text that differs per country), or because a
single value was identical on every row this query returned but drill_down
stays true since other rows queried differently might differ.

Args:
    dataflow_id: The dataflow to read
    attribute_id: An attribute id from get_reference_metadata()
    key: Optional dimension key to narrow the query. Strongly recommended
        for large dataflows: an unfiltered request that is too large to
        return is reported back rather than guessed at, but supplying a
        key (for example a single indicator or reference area) up front
        avoids that round trip.
    agency_id: The agency that owns the dataflow
    endpoint: Optional endpoint key for this call only

Returns:
    Every value of the attribute, each with the dimension key it applies to

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyNo
endpointNo
agency_idNo
dataflow_idYes
attribute_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
labelNoHuman-readable label
notesNoRemarks for the caller
totalNoCount of (value, key_context) pairs found
statusYesOne of four outcomes, mirroring the populated/declared_empty vocabulary on MetadataAttribute: 'values' -- the attribute has values, returned in `values`. 'declared_empty' -- the provider declares this attribute for this dataflow and published no value. 'unknown_attribute' -- no such attribute in the declared set; the declared ids are named in `notes`. 'unestablished' -- no channel resolved to a declared set, so nothing can be concluded about whether the attribute exists. This last value must never be rendered as 'no metadata': it is not an observation that the attribute is absent, only that this provider's channels could not confirm one way or the other.
valuesNoValues found
truncatedNoTrue when values holds fewer than total
value_kindNoprose, url, date or unknownunknown
dataflow_idYesDataflow queried
attribute_idYesAttribute queried
distinct_valuesNoCount of distinct value texts among the values found. `total` counts (value, key_context) pairs and answers a different question: three countries publishing the same source organisation give total: 3, distinct_values: 1. Counted over the full uncapped set, not the capped 200, so it stays truthful when `truncated` is true. 0 for the three non-'values' statuses.
Behavior4/5

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

With no annotations, the description discloses important behavior: unfiltered requests too large to return are 'reported back rather than guessed at,' and supplying a key avoids that round trip. It also explains why drill_down may remain true. However, it does not mention potential errors, rate limits, or auth, though these are less critical for a read-only metadata retrieval.

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?

The description is well-structured: a concise summary sentence, a brief use-case paragraph, a labeled Args list, and a Returns line. Every sentence carries useful information without fluff. The front-loaded purpose is immediately clear.

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?

For a 5-parameter tool with no annotations, the description covers all parameters, explains when to use it, describes its return value, and provides practical tips for large dataflows. The presence of an output schema reduces the need to describe return format in more detail. This is sufficiently complete for an agent to invoke correctly.

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 coverage is 0%, but the description provides meaningful documentation for every parameter: 'dataflow_id: The dataflow to read', 'attribute_id: An attribute id from get_reference_metadata()', and especially 'key' with guidance on large dataflows. This goes far beyond the raw schema by explaining relationships and usage context.

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: 'Get every value of one reference metadata attribute, with the slice each applies to.' It clearly distinguishes this from the sibling get_reference_metadata() by explaining it is for drilling down when drill_down=true, making the purpose unmistakable.

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?

Explicitly states when to use: 'Use after get_reference_metadata() reports drill_down=true.' It also provides practical guidance on the 'key' parameter for large dataflows to avoid round trips, which directly informs when and how to use this tool over alternatives.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nescoffee-create/sdmx-mcp-gateway'

If you have feedback or need assistance with the MCP directory API, please join our Discord server