apibase

Statistics Denmark Subject Areas

statistics-denmark.data.subjects

Read-onlyIdempotent

List the subject/topic areas covered by Statistics Denmark (StatBank) — People, Labour and income, Economy, Social conditions, Education and research, Business, Transport, Culture and leisure, Environment and energy, About Statistics Denmark. Set recursive=true to drill down into the full nested topic tree (e.g. People → Population → Population figures) used to browse toward specific tables. Statistics Denmark (Danmarks Statistik) is the Danish national statistics authority.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "statistics-denmark.data.subjects"
  }
}

Input Schema

Name	Required	Description	Default
`recursive`	No	If true, return the full nested subject tree down to leaf topics (e.g. People → Population → Population figures). If false (default), return only the 10 top-level subject areas (People, Labour and income, Economy, Social conditions, Education and research, Business, Transport, Culture and leisure, Environment and energy, About Statistics Denmark).

Output Schema

Name	Required	Description	Default
`error`	No	Present only when the call failed. Includes error code, message, request_id, and any provider-specific extras.
`result`	No	Tool response payload. Shape varies per tool — consult the tool description and inputSchema. May be an object, array, string, or number depending on the upstream provider response.

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 22, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already establish read-only, idempotent, and non-destructive behavior, so the description does not need to restate safety. It adds valuable behavioral context by explaining the difference between the flat top-level list and the recursive nested topic tree, with a concrete example (People → Population → Population figures). No annotation contradiction exists.

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 and front-loaded: it states the core action and subject list first, then parameter guidance, then context. The final sentence about Statistics Denmark being the national authority is mildly non-essential but not harmful. Overall it is concise and readable.

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 simple read-only listing tool with one optional boolean parameter and a rich output schema, the description is complete. It covers the default behavior, the recursive behavior, the exact subjects returned, and the browsing use case. No critical information is missing for an agent to invoke the tool correctly.

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?

The schema description covers 100% of the single recursive parameter and already explains both true and false behavior with the same example. The prose description reinforces this but adds little new parameter-level meaning beyond contextualizing the parameter as a way to browse toward tables. With full schema coverage, baseline 3 is appropriate.

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 states a specific verb and resource: it lists subject/topic areas covered by Statistics Denmark (StatBank), and enumerates the exact ten top-level subjects. This clearly distinguishes it from sibling tools like statistics-denmark.data.query, data.tables, and table_info, which operate at the data/table level rather than the topic-tree level.

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 context for use: it is the tool to browse the subject-area hierarchy before selecting specific tables. It also explains the recursive=true option and what it changes. It does not explicitly mention when not to use it or name an alternative tool, but the use case is unambiguous enough for an agent to route correctly.

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

All apibase tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.