Rettsarkiv
Server Details
Norske Høyesterettsavgjørelser og lovtekst som lov-bevisst data, søkbart på vanlig norsk.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 8 of 8 tools scored.
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.
Available Tools
8 toolsfind_decisions_applying_lawFinn dommer som anvender lovARead-onlyInspect
«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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare read-only; description adds that results are pre-filtered, ranked, and include a note field only when needed. Explains behavior for repealed editions and overgangshjemmel, enhancing transparency.
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?
Packed with necessary information, well-structured with examples and special cases. No wasted sentences; each part adds value.
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?
Despite no output schema, description fully explains return fields and behavior. Covers edge cases and parameter interactions, making it complete for the tool's 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?
With 0% schema description coverage, the description explains most parameters (lov, section, on_date, instanser, overgangshjemmel) in detail. The 'limit' parameter is not mentioned, creating a minor 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?
Description clearly states the tool returns a ranked list of decisions applying a specific law section, using a question format. It distinguishes from sibling tools by focusing on law application rather than general search or document retrieval.
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?
Provides detailed when-to-use guidance including handling editions, instances, and the overgangshjemmel flag. Lacks explicit 'do not use when' statements, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_similar_decisionsFinn lignende dommerARead-onlyInspect
«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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds rich behavioral details: ranked list logic, relation types (precedent, later citing, co-citation), tie-break rule, and empty result handling with _meta.note. No contradiction.
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?
Description is appropriately sized for the complexity, front-loaded with a question, and uses bullet points for clarity. Every sentence adds value; no 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 no output schema, the description thoroughly explains return behavior (relation field, ranking, empty result note). Parameters are fully documented. Context about sibling tools and usage scenarios is complete.
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 has 0% description coverage, but the description fully compensates by explaining id format (HR-2024-1016-A or Rt-1979-524) and instanser values (hoyesterett default, lagmannsrett, tingrett, alle). Limit is mentioned with default from 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?
The description clearly states the tool finds precedent neighbors via citation graph, using the specific verb 'find' and resource 'similar decisions'. It distinguishes from siblings by explaining that this tool captures citation-based connections, unlike search_decisions (topic) and find_decisions_applying_law (single section).
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 states when to use: when user asks for similar/related decisions, mapping a doctrine, or needing a principled line. Also states when not to use, naming alternatives: search_decisions and find_decisions_applying_law do not capture the citation-based connection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_decisionHent avgjørelseARead-onlyInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses return structure (structured text, tags, provenance, section headings) beyond the readOnlyHint annotation, adding value for expected behavior.
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, front-loaded paragraph of three sentences, each adding value—purpose, return fields, and parameter usage—without any fluff.
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 adequately explains return values and effects of parameters, covering all user needs for a simple retrieval tool.
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?
With 0% schema coverage, the description fully explains both optional parameters (paragraphs for numbered chunks, statutes for law text) and gives examples for the required id parameter, compensating completely.
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 verb 'Hent' (get) and resource 'avgjørelse' (decision) with specific stable ID examples, distinguishing it from sibling tools like search_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 clear context for using the optional parameters (paragraphs for citation, statutes for law text), but does not explicitly state when to prefer this tool over siblings, though it's implied for known IDs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_lawHent lovARead-onlyInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds detail about returning metadata and table of contents beyond the readOnlyHint annotation. 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?
The description is two sentences, front-loaded with the main purpose. Every sentence earns its place with no 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?
For a simple tool with one parameter and no output schema, the description is complete: it explains what is returned and directs to the sibling for full text.
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 single parameter 'lov' can be a lovdata-id or short title, adding meaning beyond the schema which only has 'Lov'. With 0% schema coverage, this is essential.
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 verb 'Slå opp' (look up) and the resource 'lov med metadata + innholdsfortegnelse'. It distinguishes itself from sibling tools like get_law_section.
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?
It specifies when to use this tool vs alternatives ('Bruk get_law_section for selve teksten') and clarifies the input format (lovdata-id or short title).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_law_sectionHent lovparagrafARead-onlyInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, consistent with read purpose. Description adds behavioral details: returns text for a specific edition, historical editions may return null, and with_decisions=true combines section text 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?
The description is concise, a single dense sentence with key information front-loaded. However, it uses abbreviations and special characters that may reduce readability.
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?
For a read-only tool with 5 parameters and no output schema, the description covers core functionality, version nuance, and optional decisions. Missing explanation of instanser 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?
Schema coverage is 0%, so description must explain parameters. It explains lov and section with examples, on_date for versioning, and with_decisions briefly. However, instanser is not explicitly explained (only schema title), and its default value is not mentioned in description.
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 concrete examples (e.g., 'straffeloven', section='257'). It distinguishes from siblings like get_law (whole law) and find_decisions_applying_law (decisions) by focusing on a specific section.
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: version-aware usage with on_date for ambiguous titles, and examples for EMK. It does not explicitly state when not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_changesList opp endringerARead-onlyInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so no contradiction. The description adds behavioral context: it returns a next marker for pagination and contrasts with the streaming export endpoint. However, it does not detail other behaviors like rate limits or error handling.
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 concise and front-loaded with the main purpose. However, it is in Norwegian, which may reduce clarity for an English-speaking agent, though the title and name are also in Norwegian.
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?
No output schema, so description must explain return values. It mentions a 'next' marker for incremental sync but does not describe the actual list fields (e.g., decision IDs, metadata). Additionally, pagination via 'limit' is implied but not elaborated. The description is complete enough for basic use but lacks detail on output structure.
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 must compensate. It explains the 'since' parameter (ISO timestamp marker) but does not mention 'limit' or its default value. Thus, partial compensation but incomplete for both 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 the tool lists new/updated decisions since a timestamp, with a next marker for incremental sync. It distinguishes from the /export endpoint for full corpus download, and the sibling tools include search_decisions and get_decision, so the purpose is specific and differentiated.
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 says when to use this tool (incremental sync) and when not to (full corpus download, directing to the /export endpoint instead). This provides clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_lawFinn riktig lovARead-onlyInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses detailed behavior: resolution logic, response fields (editions list, resolution, warning), collision handling, and error states (unresolved_for_date). Annotations already declare readOnlyHint=true, which aligns with the read-only nature described.
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 somewhat lengthy but each sentence earns its place. It is front-loaded with the core purpose, then explains nuance, response details, and ordering. No redundant sentences, though could be tightened slightly.
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 no output schema and 0% schema description coverage, the description provides a full picture: input parameters, output structure (editions, resolution, warning), error handling, and usage context with sibling tools. It leaves no critical information missing.
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?
With 0% schema description coverage, the description fully compensates by explaining the 'name' parameter (short title) and 'on_date' parameter (YYYY-MM-DD, typical hearing date) with concrete examples and usage implications. Adds meaning far beyond the bare 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?
The description clearly states the tool resolves a law's canonical ID from short title/name, with explicit edition awareness. It distinguishes itself by recommending usage before find_decisions_applying_law, a sibling tool listed in context.
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?
Provides explicit when-to-use (when law may be ambiguous) and when-not-to (implied by suggesting alternative). Specifies the on_date parameter usage and consequences of omission. Directly references sibling tool find_decisions_applying_law as a follow-up.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_decisionsSøk i avgjørelserARead-onlyInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description explains that results are ranked and ready to present, lists output fields, and discloses filtering behavior (court_level aliases). It adds significant value and does not contradict 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 a single efficient paragraph with front-loaded purpose and minimal wasted text. Every sentence adds value, making it highly 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 and no output schema, the description lacks details on date formats, pagination for the limit parameter, and the decision_type parameter. Output fields are listed, but overall completeness is adequate with notable gaps.
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?
With 0% schema description coverage, the description explains q, lov, section, and court_level but omits from_date, to_date, on_date, limit, and decision_type. This incomplete coverage leaves meaning gaps for several 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 it performs free text search in Norwegian court decisions and lists output fields. However, it initially says 'Høyesteretts-avgjørelser' (Supreme Court) but then includes a court_level filter for lower courts, causing slight inconsistency. Overall purpose is clear.
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 references get_decision for full text retrieval and mentions find_decisions_applying_law for the same law+section key. It provides context on date parameters but does not explicitly state when not to use this tool or prioritize alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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.
Discussions
No comments yet. Be the first to start the discussion!