Norske Høyesterettsavgjørelser og lovtekst som lov-bevisst data, søkbart på vanlig norsk.
«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'.| Name | Required | Description | Default |
|---|---|---|---|
| lov | Yes | ||
| limit | No | ||
| on_date | No | ||
| section | Yes | ||
| instanser | No | hoyesterett | |
| overgangshjemmel | No |
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.
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.
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.
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.
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.
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.
«Hvilke dommer henger sammen med ?» — presedens-naboer via SITATGRAFEN.
Dette er det PÅLITELIGE relevans-signalet for presedens: ikke at to dommer deler
en paragraf (svakt — en § dekker vidt forskjellige saker), men at de henger sammen
i siteringskjeden inne i premissene. Hver rad har et `relation`-felt som sier HVORFOR:
• «presedens denne dommen bygger på» — en avgjørelse <id> selv siterer (oppstrøms)
• «senere dom som bygger på denne» — en senere avgjørelse som siterer <id> (nedstrøms)
• «deler N sentrale referanser» — co-sitering: bygger på de samme presedensene
Returnerer en ferdig RANGERT liste, klar til å presenteres direkte. Direkte naboer
(opp-/nedstrøms) rangeres foran rene co-siterings-søsken; `sitering_count` er kun
tie-break (et høyt siteringstall løfter ikke en urelatert dom). Bruk dette når
brukeren spør «finn lignende/relaterte dommer», vil kartlegge en doktrine, eller
trenger den prinsipielle linjen bak en avgjørelse — der `search_decisions` (tema)
og `find_decisions_applying_law` (én §) ikke fanger sammenhengen.
`id` = HR-2024-1016-A eller Rt-1979-524. `instanser`: 'hoyesterett' (default) |
'lagmannsrett' | 'tingrett' | 'alle'. Tomt resultat = dommen står utenfor
sitatgrafen (siterer ingen / er ikke sitert) — da melder `_meta.note` det ærlig.| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| limit | No | ||
| instanser | No | hoyesterett |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite annotations providing readOnlyHint=true, the description adds substantial behavioral context: it details the ranking logic (direct neighbors before co-citation siblings, sitering_count as tie-break), explains the relation field values, and describes the output as a ready-ranked list. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and a clear hierarchy, but it is somewhat verbose. However, every sentence adds value, and the key question is front-loaded. A minor reduction in explanation could improve conciseness without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema), the description is comprehensive. It explains the output format (ranked list with relation field), the ranking logic, and the _meta.note for empty results. No output schema is needed as the description covers return value semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates fully. It provides example formats for the id parameter (HR-2024-1016-A, Rt-1979-524), lists allowed values for instanser (hoyesterett, lagmannsrett, tingrett, alle), and clarifies the behavior when results are empty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific question ('Hvilke dommer henger sammen med <id>?') and clearly defines the tool as finding precedent neighbors via citation graph. It explicitly distinguishes itself from sibling tools like search_decisions (topic-based) and find_decisions_applying_law (section-based).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (e.g., user asks for similar/related decisions, mapping a doctrine) and when the alternatives are insufficient. It also explains the meaning of an empty result and directs the user to _meta.note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hent én avgjørelse med stabil id (HR-2024-123-A eller Rt-1979-524). Returnerer strukturert tekst, lov-taggede §-referanser og provenance (source_origin + content_hash). Hver §-tag har lesbar overskrift (section_heading). Sett paragraphs=true for nummererte avsnitt-chunks (pinpoint «avsnitt 45») med arvede §-tags — bruk det for sitérbar RAG-kontekst. Sett statutes=true for å få selve gjeldende lovtekst (section_text) på hver tag.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| statutes | No | ||
| paragraphs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description reinforces that it is a read operation. Beyond annotations, the description details the return structure (structured text, law-tags, provenance, section_heading, section_text), which is valuable behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph that front-loads the core purpose, then efficiently covers parameter behavior and output details. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description adequately covers the return fields (structured text, tags, provenance, etc.). However, it does not mention error handling, rate limits, or prerequisites, which slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), so the description fully compensates by explaining each parameter: 'id' format, 'paragraphs' for numbered chunks with inherited tags, and 'statutes' to include law text. This is thorough and actionable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a single decision with a specific stable ID format (e.g., HR-2024-123-A or Rt-1979-524). It immediately distinguishes itself from sibling tools like search_decisions which are for searching, not retrieving a specific decision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the user has a stable decision ID, but it does not explicitly contrast with sibling tools or provide when-not-to-use guidance. The ID format is specified, which helps, but alternatives are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Slå opp en lov med metadata + innholdsfortegnelse (paragraf-overskrifter).
lov kan være lovdata-id (2005-05-20-28) eller korttittel (straffeloven).
Bruk get_law_section for selve teksten i en enkelt paragraf.
| Name | Required | Description | Default |
|---|---|---|---|
| lov | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description doesn't need to re-state safety. It adds some context about the output (metadata + TOC) and input formats, but doesn't disclose other behaviors like auth requirements or rate limits. Given the annotation coverage, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and what is returned, second gives parameter guidance and alternative tool. Front-loaded, no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (single parameter, no output schema), the description covers all essential aspects: purpose, return content, parameter format, and alternative tool. It is complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only one parameter 'lov' with no description (0% coverage). The description compensates fully by explaining it can be a lovdata-id (e.g., 2005-05-20-28) or a short title (e.g., straffeloven), adding crucial semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'slå opp' (look up) and resource 'lov' (law), and specifies it returns metadata + table of contents (paragraph headings). This distinguishes it from sibling 'get_law_section' which returns the text of a single paragraph.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool (to get metadata and TOC) and when to use the alternative 'get_law_section' (for the actual text of a paragraph). Also provides details on the 'lov' parameter format (lovdata-id or korttittel).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hent tekst for en lovparagraf (NLOD-fri lovtekst), f.eks. lov='straffeloven',
section='257' → «§ 257 Menneskehandel …». UTGAVE-BEVISST: oppgi on_date
(domsdato) for flertydig korttittel — teksten er for den OPPLØSTE utgaven, aldri
en annen utgaves tekst limt på (en historisk utgave kan mangle tekst → text=null
+ note). lov = lovdata-id eller korttittel; EMK: lov='EMK', section='art 6'.
with_decisions=true gir paragrafen + de rangerte dommene som anvender den (dato-
filtrert) i ett kall.
| Name | Required | Description | Default |
|---|---|---|---|
| lov | Yes | ||
| on_date | No | ||
| section | Yes | ||
| instanser | No | hoyesterett | |
| with_decisions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, consistent with description. The description adds important behavioral details: edition-awareness (text for the resolved edition only), possibility of null text for historical editions, and combined decision retrieval with with_decisions. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Information is packed in one paragraph with clear front-loading of purpose. Every sentence adds value, though a more structured layout (e.g., bullet points) could improve readability. Still concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters (one undocumented), no output schema, and moderate complexity, the description covers main functionality but lacks full return value structure and explanation of the instanser parameter. Partial completeness limits agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description carries the burden. It explains lov, section, on_date, and with_decisions meaningfully, including examples and behavior. However, the instanser parameter is not described, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves text for a law section with a concrete example (lov='straffeloven', section='257'). It distinguishes from siblings like get_law (whole law) and find_decisions_applying_law (decision search) by focusing on a specific section and optionally including decisions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use on_date for edition disambiguation and how to specify law using ID or short title. It mentions with_decisions as a combined alternative to separate tool calls. However, it does not explicitly state when not to use this tool or compare with all siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Nye/oppdaterte avgjørelser siden en markør (ISO-tidsstempel). Returnerer en
next-markør for inkrementell synk. Til full nedlasting av hele korpuset
(avsnitt-chunks + embeddings + §-tags): bruk /export-endepunktet (NDJSON) i
REST-API-et — det er en strøm, ikke et interaktivt verktøy.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| since | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description's addition of returning a 'next' marker for incremental sync adds valuable behavioral context beyond annotations. It could further discuss rate limits or error behavior but is sufficient with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core purpose and return value, followed by an alternative usage note. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description covers the core functionality, return marker, and a key alternative. It lacks details on pagination semantics (e.g., limit behavior, error cases) but is reasonably complete for its complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the 'since' parameter as an ISO timestamp marker, adding meaning beyond the schema. However, it does not address the 'limit' parameter at all, leaving its behavior undocumented. With 0% schema coverage, the description partially compensates but is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists new/updated decisions since an ISO timestamp, with a specific verb and resource. It distinguishes from the export endpoint for full download, making its purpose unambiguous even among sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool (incremental sync) and when not to (full download should use the /export endpoint). This provides clear usage guidance and an alternative, which is excellent for agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Slå opp en lovs kanoniske lovdata-id fra korttittel/navn, UTGAVE-BEVISST.
VIKTIG: samme korttittel kan peke på ULIKE lover (utgaver) etter ikraft-dato, og
samme §-nummer betyr da ULIKE ting. Eksempel: straffeloven § 257 = menneskehandel
i 2005-loven (i kraft 2015-10-01), men tyveri i 1902-loven.
Oppgi `on_date` (YYYY-MM-DD) — typisk DOMSDATOEN — for å få utgaven som faktisk var
i kraft da. Uten `on_date` velges nyeste utgave og svaret merkes
`resolution='defaulted_newest'` + `ambiguous=true` når korttittelen er flertydig.
Returnerer ALLTID hele `editions`-lista med `valid_from`/`valid_to`/`text_loaded`
per utgave, et `resolution`-felt som forklarer HVORDAN den valgte, og et `warning`
når §-nummer kolliderer mellom utgaver. Ukjent utgave for datoen → `resolved=null`,
`resolution='unresolved_for_date'` — aldri et stille feil-treff. Bruk dette FØR
find_decisions_applying_law når loven kan være flertydig.| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| on_date | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Details return values including editions list, resolution field, warning, and behavior for unresolved cases. Consistent with readOnlyHint annotation as a safe lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded, but slightly verbose. Every sentence adds value, though could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a complex tool with edition-awareness. Covers all return fields, edge cases (ambiguous, defaulted, unresolved), and no output schema needed as description suffices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description thoroughly explains both parameters: name as short title, on_date as date for edition resolution, with examples and fallback behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves a law's canonical ID from a short title, being edition-aware. It distinguishes from sibling tools like find_decisions_applying_law by specifying when to use this beforehand.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use this before find_decisions_applying_law when the law is ambiguous. Provides guidance on providing on_date (typically court date) and explains behavior without it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fritekstsøk i norske Høyesteretts-avgjørelser — rangerte treff, klare til å
presenteres direkte. Hver rad: primary_id, decision_date, summary,
sitering_count. Oppgi lov+section for å begrense til dommer som anvender en
bestemt paragraf (samme utgave-bevisste nøkkel som find_decisions_applying_law).
court_level (instans-filter) tar hoyesterett | lagmannsrett | tingrett
(aliasene «HR»/«Høyesterett» godtas også); utelat for alle instanser.
Hent fulltekst for en konkret dom via get_decision. Svar med lista.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | ||
| lov | No | ||
| limit | No | ||
| on_date | No | ||
| section | No | ||
| to_date | No | ||
| from_date | No | ||
| court_level | No | ||
| decision_type | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lists output fields and states that results are ranked, which adds some behavioral insight. However, it does not disclose pagination behavior or rate limits. Since annotations already indicate readOnlyHint=true, the additional disclosure is moderate but not extensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph but efficiently packs purpose, parameter details, and sibling reference. It is well-structured with front-loaded purpose, though slightly dense. Could benefit from bullet points but remains concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, no output schema, and complexity, the description covers primary purpose, output format, parameter usage, and related tools. It lacks explicit pagination details but is otherwise complete for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to many parameters (lov, section, court_level with aliases, date range) beyond the schema titles. However, decision_type is not explained. With 0% schema description coverage, the description compensates well for most parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool performs free-text search on Norwegian Supreme Court decisions, returning ranked results with specific fields. It distinguishes itself from sibling tools like find_decisions_applying_law and get_decision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (for free-text search) and explains how to filter by parameters like lov, section, court_level with aliases. It also directs users to get_decision for full text, clarifying alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
find_similar_decisionsfind_decisions_applying_law3 fields changedInput schema / properties / instanserAdded value: +{
+ "default": "hoyesterett",
+ "title": "Instanser",
+ "type": "string"
+}Input schema / properties / on_dateAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "On Date"
+}Input schema / properties / overgangshjemmelAdded value: +{
+ "default": false,
+ "title": "Overgangshjemmel",
+ "type": "boolean"
+}get_law_section2 fields changedInput schema / properties / instanserAdded value: +{
+ "default": "hoyesterett",
+ "title": "Instanser",
+ "type": "string"
+}Input schema / properties / on_dateAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "On Date"
+}search_decisions1 field changedInput schema / properties / on_dateAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "On Date"
+}find_decisions_applying_lawget_decisionget_lawget_law_sectionlist_changesresolve_lawsearch_decisionsClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Temporal search and comparison for official Luxembourg and reviewed EU law, with provenance.
Verified, citable German & EU law for any LLM. Daily updates from official sources, hosted in DE.
Verified, citable German & EU law for any LLM. Daily updates from official sources, hosted in DE.
Search 18M+ legal documents worldwide — case law, legislation, and doctrine across 110+ countries.
Add one secure layer between your agents and this server.
Each tool targets a distinct task: law-section search, citation-based similarity, full decision retrieval, law metadata, law section text, change tracking, law name resolution, and free-text search. Descriptions clarify boundaries, e.g., between find_decisions_applying_law and search_decisions with law+section.
All tool names follow a consistent verb_noun pattern in English (find_, get_, list_, resolve_, search_). Verbs are uniform and nouns clearly indicate the resource or action. No mixing of conventions.
With 8 tools, the server is well-scoped for legal research. Each tool serves a core function without redundancy, covering search, retrieval, navigation, and updates. Neither too sparse nor overwhelming.
The tool surface covers the full lifecycle of legal research: searching (free-text, by law section), finding related decisions via citation graph, retrieving decision and law content, resolving legal references, and tracking updates. No obvious gaps for the domain.