Skip to main content
Glama

Finn dommer som anvender lov

find_decisions_applying_law
Read-only

«Hvilke Høyesteretts-dommer anvender §

Returnerer en ferdig RANGERT liste, klar til å presenteres direkte for brukeren.
Hver rad: `primary_id`, `decision_date`, `summary`, `sitering_count`, lesbar
`section` («§ 192 Voldtekt») og `edition`. Svar med lista — du trenger ikke
forklare verktøyets metode eller verifisere hvert treff.

Resultatet er allerede dato-filtrert til riktig lovutgave og rangert på relevans
+ autoritet. Et `note`-felt dukker opp KUN når noe må flagges (f.eks. et treff som
bør sjekkes mot fulltekst, eller utelatte treff i `_meta`) — løft da den ene
setningen kort. Ingen note = svaret står på egne ben.

Utgave: § n kan bety ulike ting i ulike utgaver (straffeloven § 257 =
menneskehandel i 2005-loven, tyveri i 1902-loven). Oppgi `on_date` (domsdatoen)
for å låse utgaven; uten den dekkes begge, og `_meta.edition` viser oppløsningen.
En opphevet utgave kan fortsatt anvendes i nyere dommer som OVERGANGSHJEMMEL (for
handlinger før opphevelsen) — slike treff beholdes med et `note`, ikke utelatt.

`overgangshjemmel=true`: når SPØRSMÅLET er «anvender noen FORTSATT den opphevede
utgaven?» (f.eks. strl. 1902 § 257 etter 2015) — løfter treff på opphevet utgave
øverst. Uten flagget rangeres de på relevans+autoritet og kan drukne under den
i-kraft-bunken (de har typisk få siteringer). `_meta.note` melder antallet, og null
treff er et ærlig «nei» — alle treff gjelder utgaven som var i kraft.

`instanser`: 'hoyesterett' (default — produktet er HR-praksis) | 'lagmannsrett' |
'tingrett' | 'alle'. `lov` = lovdata-id eller korttittel. EMK: lov='EMK',
section='art 6'.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
lovYes
limitNo
on_dateNo
sectionYes
instanserNohoyesterett
overgangshjemmelNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed3 schema fields changed
    • addedInput schema / properties / instanser
      Added value: +{
      +  "default": "hoyesterett",
      +  "title": "Instanser",
      +  "type": "string"
      +}
    • addedInput schema / properties / on_date
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "On Date"
      +}
    • addedInput schema / properties / overgangshjemmel
      Added value: +{
      +  "default": false,
      +  "title": "Overgangshjemmel",
      +  "type": "boolean"
      +}
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true (no contradiction). The description adds significant behavioral context: result is date-filtered, ranked on relevance+authority, 'note' appears only when flagging issues, edition ambiguity is handled, and 'overgangshjemmel' changes ranking. This goes well beyond annotations.

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 thorough but slightly lengthy (5 paragraphs). However, it is well-structured with bold headings, a sample query front-loaded, and each paragraph adds value. Could trim some redundancy (e.g., 'Resultatet er allerede...' could be merged) but remains effective.

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?

With no output schema, the description fully explains returns: primary_id, decision_date, summary, sitering_count, section, edition, and note field. It covers edge cases like overgangshjemmel, edition resolution, and how to present results. No gaps found for a legal research tool of this complexity.

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 bears full burden. It explains every parameter in detail: 'lov' as lawdata ID/title, 'section' as paragraph, 'on_date' to lock edition, 'overgangshjemmel' to lift old-edition results, 'instanser' to limit court instance. Only 'limit' is implicitly covered (default 50).

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 clearly states the tool finds Supreme Court decisions applying a specific law paragraph and returns a ranked list ready for presentation. It includes a sample query in Norwegian, specifying the verb 'Finn' (find) and resource 'dommer som anvender lov', and distinguishes from sibling tools by its focused law-paragraph scope.

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?

Excellent usage guidance: explains when to use 'overgangshjemmel', how 'on_date' locks edition, that result is pre-ranked and pre-filtered, how to interpret 'note' field, and that without 'on_date' both editions are covered. Provides clear context for when to use this tool vs. alternatives (e.g., search_decisions) via implied specificity.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources