Skip to main content
Glama
Sign In
dk-tax

dk-tax

by mikaelbdj
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

list_figures

Lists available Danish tax figure keys for a given income year, including name and unit, so you can identify the correct keys before fetching values.

Instructions

List the tax figure keys available for an income year, with name and unit.

Use this to find the right keys, then fetch values with get_figures.
Keys differ between years when the law changed (e.g. 2025 has the old 15 %
topskat; mellemskat and toptopskat start in 2026).

Input Schema

NameRequiredDescriptionDefault
yearYes

Output Schema

NameRequiredDescriptionDefault
yearYes
figuresYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.1

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden, and it does disclose that this is a discovery/listing step returning keys with name and unit rather than values, plus the year-dependent variance in key sets. It omits safety/permission context and pagination or size behavior, which are minor for a small reference listing.

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?

Three short sentences, front-loaded with the core action and return content, then routing guidance, then the year-variance caveat. Nothing is redundant and no sentence could be dropped without losing information.

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?

An output schema exists, so return-value documentation is not required, and the description covers purpose, alternative routing, and year sensitivity. The remaining gap is the semantics of the year argument (calendar vs. income year definition, valid bounds), which the empty schema leaves entirely to the description.

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 coverage is 0% for the single required integer `year`, so the description must supply meaning. It clarifies that the parameter is an income year and that different years yield different keys, but gives no valid range, format, or out-of-range behavior.

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?

States a specific verb and resource ("List the tax figure keys available for an income year") plus what each entry contains (name and unit). The second sentence explicitly distinguishes it from the sibling get_figures, so an agent can separate the two without opening either schema.

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?

Gives an explicit workflow: use this to find keys, then call get_figures to fetch values. It also warns that the valid key set varies by year with concrete examples (2025 topskat vs. 2026 mellemskat/toptopskat), which tells the agent when a cached key list is unsafe to reuse.

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

Deploy Server

Other Tools