MCP server for Norwegian law lookup via Lovdata Public API. Provides access to over 92,000 Norwegian legal paragraphs with full-text search, semantic search, and batch retrieval capabilities.
This is a specialized legal research server with 10 tools. Strengths: all tools have descriptions and input schemas with type information; tool names are action-oriented (sok, hent_flere, sjekk_storrelse); parameters are well-described with constraints and examples. Weaknesses: output schemas are not explicitly documented (the source shows only input schemas); error handling guidance is absent; no pagination/result limits documented for search tools; parameter descriptions contain example values (violates rubric guidance) in multiple tools; no tool annotations (readOnlyHint, etc.) despite claiming toolAnnotations=true in the feature list; Norwegian descriptions may reduce LLM clarity in English-context agents. The server implements a complex domain (Norwegian law lookup) but lacks production-grade error handling and output documentation.
List alle departementer (for filterverdier)
Slå opp forskrift. Uten paragraf → innholdsfortegnelse med hjemmelslov
Batch-henting av flere paragrafer (~80% raskere enn separate kall)
Vis aliaser (IKKE komplett liste - alle 770+ lover kan slås opp)
Slå opp norsk lov eller spesifikk paragraf fra Lovdata. Støtter kortnavn (avhendingslova, buofl, pbl, aml) eller full ID. Paragraf: bruk kun tall ('3-9'), ikke '§ 3-9'. Eksempel: lov('aml', '14-9') for arbeidsmiljøloven § 14-9
Finn forskrifter med hjemmel i en lov
List alle rettsområder (for filterverdier)
Output schemas not documented. The source code shows input schemas with JSON Schema format, but return types and output field structures are not explicitly declared. LLMs cannot plan downstream tool calls or understand what fields to extract without documented output schemas.
Parameter descriptions contain example values. E.g., 'lov' parameter includes example '3-9', 'Kapittel 16'; 'sok' includes 'vesentlig mislighold'. Use enums or regex patterns instead.
No error handling guidance. Tool descriptions do not explain what errors might occur, which are retryable, or what the LLM should do if a call fails. E.g., 'lov_id not found', should the agent try 'sok()' first, or is this unrecoverable?
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 57 | 2025-06-18+ | v1 |
AI-søk for naturlig språk. Bruker vektorsøk for å finne relatert innhold selv om ordene er annerledes.
Estimer tokens før henting
FTS-søk med filtre. Prøver AND-logikk først. Hvis 0 treff, faller automatisk tilbake til OR.
No pagination or result limit guidance for search tools. 'sok' and 'semantisk_sok' have a 'limit' parameter, but the description does not state min/max values or default behavior. What happens if limit is not specified? Is there a hard cap?
Tool descriptions written in Norwegian. While appropriate for a Norwegian law tool, descriptions in non-English may reduce clarity for English-speaking LLMs and violate conventions in multilingual agent systems. Consider bilingual descriptions or English-first with Norwegian fallback.
toolAnnotations claimed as true, but no tool-level readOnlyHint, destructiveHint, or idempotentHint annotations visible in the schema. All tools are read-only (appropriate), but readOnlyHint should be explicitly set in tool registration for clarity.
Discovery tools (departementer, rettsomrader, liste) lack context. Descriptions do not explain when to call them or how they support filtering in 'sok' and 'semantisk_sok'. A user reading 'List all departementer (for filterverdier)' does not know why to call it.
Parameter 'max_tokens' appears in multiple tools but its semantics are ambiguous. Does it control the size of the returned text, or is it a pre-flight estimate (like 'sjekk_storrelse')? This dependency is not documented per the 'param-relationships' guidance.