Skip to main content
Glama
nescoffee-create

SDMX MCP Gateway

get_structure_diagram

Generate SDMX-aware Mermaid diagrams to visualize structural relationships and impact across dataflows, DSDs, codelists, and concept schemes.

Instructions

Generate an SDMX-aware Mermaid diagram for any structural artifact.

The visualization adapts based on the artifact type to show the most
relevant information following the SDMX information model:

**Dataflow**: Shows full SDMX hierarchy (entry point view)
    - Dataflow → DSD → Components (Dimensions, Attributes, Measure)
    - Components → Concepts (semantic meaning from ConceptSchemes)
    - Components → Representations (Codelists or free text)

**DSD/DataStructure**: Shows component structure + relationships
    - Parent dataflows that use this DSD
    - Child codelists and concept schemes referenced

**Codelist**: Shows impact/usage view (building block)
    - Parent DSDs/dimensions that reference this codelist
    - Useful for impact analysis (what breaks if I change this?)

**ConceptScheme**: Shows usage across structures
    - Parent DSDs/components that use these concepts

Args:
    structure_type: Type of structure - one of:
        - "dataflow": Statistical data publication (shows full hierarchy)
        - "datastructure" or "dsd": Data Structure Definition
        - "codelist": Code list (enumeration of valid values)
        - "conceptscheme": Concept scheme (definitions)
        - "categoryscheme": Category scheme (classification)
    structure_id: The structure identifier
    agency_id: Agency ID (uses current endpoint's default if not specified)
    version: Version string (default "latest") - query a specific version
    direction: Relationship direction to explore (ignored for dataflow):
        - "parents": Show structures that USE this one
        - "children": Show structures this one REFERENCES
        - "both": Show both directions (default)
    show_versions: If True, display version numbers on each node
    endpoint: Optional endpoint key (e.g. "FBOS", "ECB") to target a
        specific provider for this call only. Defaults to the session's
        current endpoint.

Returns:
    StructureDiagramResult with:
        - mermaid_diagram: Ready-to-render Mermaid code
        - nodes: All structures in the relationship graph
        - edges: Relationships between structures
        - interpretation: Human-readable explanation

Examples:
    >>> get_structure_diagram("dataflow", "DF_SDG")
    # Shows complete SDG dataflow structure with SDMX hierarchy

    >>> get_structure_diagram("codelist", "CL_FREQ", show_versions=True)
    # Shows what structures use CL_FREQ (impact analysis)

    >>> get_structure_diagram("dsd", "DSD_POP", direction="children")
    # Shows codelists and concept schemes used by DSD_POP

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
versionNolatest
endpointNo
agency_idNo
directionNoboth
structure_idYes
show_versionsNo
structure_typeYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNoAdditional notes or warnings
depthYesTraversal depth used
edgesYesAll edges (relationships) in the graph
nodesYesAll nodes in the relationship graph
targetYesThe queried target structure
directionYesDirection queried: 'parents', 'children', or 'both'
api_calls_madeYesNumber of SDMX API calls made
interpretationYesHuman-readable explanation of the relationships
discovery_levelNoDiscovery workflow levelstructure_relationships
mermaid_diagramYesReady-to-render Mermaid diagram code showing structure relationships
Behavior4/5

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

With no annotations, the description carries full behavioral burden. It transparently explains how output adapts per artifact type, the meaning of direction, the default version/agency/endpoint behavior, and what the result contains. It does not mention side effects or error conditions, but the read-only nature is implied by 'Generate' and 'Returns'.

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 long but well-structured with a clear summary, type-specific bullets, Args, Returns, and Examples. Each section adds necessary detail without redundancy, and the main purpose is front-loaded.

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 tool with 7 parameters and type-dependent behavior, the description is exceptionally complete. It covers all parameter semantics, behavioral variations, output structure, and includes three diverse examples. The presence of an output schema further reduces the need to document return fields, yet the description still does.

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%, so the description must compensate. It provides a dedicated Args section explaining every parameter, including allowed values for structure_type, defaults for version/agency_id/direction/show_versions/endpoint, and the meaning of direction. Examples further clarify parameter usage.

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: 'Generate an SDMX-aware Mermaid diagram for any structural artifact.' It further distinguishes itself from sibling tools by detailing type-specific visualization views (dataflow, DSD, codelist, concept scheme), making its unique role clear.

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 clear usage context, such as 'impact analysis' for codelists and 'shows complete SDG dataflow structure' in examples. However, it does not explicitly name alternative tools or state when not to use this tool, so it stops short of a 5.

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