Skip to main content
Glama
Sign In
mcp-lovdata

mcp-lovdata

by synjan
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Bla i korpuset

list_documents

List Norwegian laws and regulations filtered by type, ministry, or change date, sorted by last modified. Use 'since' to see new rules since a date, or omit filters to view department publication counts.

Instructions

List dokumenter filtrert på type, departement eller endringsdato, sortert med sist endrede først. Bruk since for «hva er nytt i regelverket siden ...». Uten filtre svarer verktøyet med hvilke departementer som finnes, og hvor mye hvert av dem har publisert.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_documents"
  }
}

Input Schema

NameRequiredDescriptionDefault
typeNo
limitNo
sinceNoIkrafttredelse eller endring fra og med, f.eks. "2026-01".
offsetNo
ministryNoDelstreng av departementsnavn, f.eks. "Helse".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden. It discloses the sort order and the significant no-filter aggregation behavior, both of which are non-obvious. It does not specify the response format or pagination details, but these are partially covered by the schema's limit/offset fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, each adding unique value: the core action, the specific use of 'since', and the no-filter fallback. No filler or repetition, and the main action is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers filtering and a special no-filter case, but with 5 parameters, no output schema, and no annotations, it could have stated what fields are returned and how this relates to `get_document` or `search`. The lack of response-shape information and explicit routing to sibling tools leaves some gaps for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 40%, but the description compensates by explaining 'since' as a date filter and interpreting 'departement' as a ministry filter. It also adds the interaction that omitting all filters produces ministry counts. Limit and offset are left to schema defaults, which is acceptable since they are conventional.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists documents with filters on type, ministry, or change date, and sorts by most recently changed. This distinguishes it from the general 'search' sibling by focusing on structured browsing rather than full-text search, though it does not explicitly name that alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit guidance for the 'since' parameter ('what's new in the regulations since ...') and explains the no-filter behavior (returns ministry counts). It lacks direct 'when not to use' or explicit comparison to sibling tools like 'search', but the provided usage context is actionable.

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

Deploy Server

Other Tools