Loading ToolBench
MCP server providing access to Swedish government data portals, including property management (fastighetsförvaltning) data and Swedish Parliament (Riksdagen) documents
The server provides 10 tools with partial but inconsistent quality. All tools have descriptions (positive), but parameter documentation is sparse and inconsistent. Input schemas are visible in the provided code for Riksdagen tools and partially for Skatteverket tools, but descriptions lack depth and do not follow LLM-optimization best practices. Most tool descriptions are 1-2 sentences and under 100 characters, failing to explain WHEN to use the tool, what it returns, or how it chains with other tools. Parameter descriptions exist but are often minimal (e.g., 'Fritext' without explaining search scope). No output schemas are documented. Error handling is not visible in the provided code. The server mixes Swedish and English naming, which may confuse LLM intent parsing. Naming is generally verb-based (list_*, get_*, search_*), which is good, but several tools have weak descriptions that do not guide selection.
Get a single taxeringsenhet typkod by its typkod.
Get taxeringsenhet typkoder by their description.
List all fastighetsskatt and avgift with pagination.
List all taxeringsenhet typkoder with pagination.
Hämtar ett specifikt dokument i önskat format (text/html/json) givet ett dok_id eller en URL.
Listar dokument via Riksdagens dokumentlista (avd=dokument) med stöd för filtrering (doktyp, rm, datum, organ, sort).
Hämtar en specifik kalenderhändelse/dokument i önskat format (text/html/json) givet ett dok_id eller en URL.
Insufficient tool descriptions. Most descriptions are 30 - 80 characters and lack actionable context for LLM selection. Example: 'Hämtar ett specifikt dokument i önskat format (text/html/json) givet ett dok_id eller en URL.' does not explain WHEN to call this vs. other tools, what dependencies exist, or what to do with the result.
Minimal parameter descriptions do not guide LLM understanding. Example: 'Fritext' (free-text search) lacks scope explanation. Does it search document titles, full text, metadata, or all? LLMs cannot infer from names alone.
No output schemas documented. Tools return unspecified structures (DokumentResponse, DokumentLista, DokumentDetaljResponse in code, but not described to LLM). LLMs cannot plan downstream tool calls or extract needed fields.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Listar kalenderhändelser via Riksdagens dokumentlista (avd=kalender) med stöd för filtrering (doktyp, rm, datum, organ, sort).
Listar poster från Riksdagens dokumentlista för avd=ledamot. Använd för att söka efter ledamöter och deras metadata.
Search for fastighetsskatt and avgift based on various parameters.
Mixed language naming (Swedish + English). Tool names like 'riksdagen_dokument_list' use Swedish prefixes, while descriptions are mostly Swedish but some parameter names use English ('fmt', 'sok'). This inconsistency may confuse LLM intent parsing.
Parameter 'dok_id_or_url' in fetch tools overloads a single parameter with two semantic types (ID or URL). Rubric guidance: provide separate parameters (dok_id, url) or document the format precisely in the description.
Date parameters lack format validation guidance. 'datum' and 'tom' accept YYYY-MM-DD but no enum or pattern constraint is visible. Descriptions do not warn LLMs about invalid formats.
No error handling visible. Code shows httpx calls with raise_for_status() but no guidance on what errors look like, how LLMs should recover, or what to retry.
No pagination guidance in list tool descriptions. 'riksdagen_ledamot_list' accepts 'p' (page) and 'pagesize' parameters but descriptions do not explain total count, next_cursor, or how to iterate. LLMs must guess pagination semantics.