Skip to main content
Glama

nu:legal Deutsches Recht

Statute text, as Markdown

getNorm
Read-onlyIdempotent

The text of one provision, by default as clean Markdown — about a tenth the size of the reader page for the same provision, with no navigation, no scripts and no boilerplate.

law is the abbreviation as a citation writes it ('BGB', 'DSGVO', 'BDSG 2018', 'RVG'); ref is the bare number, with any letter suffix and no § or Art. ('622', '823', '3a', '83'). Aliases and case variants resolve.

POINT IN TIME: as_of=YYYY-MM-DD returns the version stored for that date. Read version_coverage on every answer — the version archive begins 2019-06-10, and a date before that answers outside_coverage with the law's amendment register attached. That is a limit of our archive and says nothing about whether the provision existed.

Every answer carries first_observed, valid_to, date_precision and amendment_note. first_observed is the day we first saw the text, NOT the legal Inkrafttreten — do not compute a deadline from it without reading date_precision (day / week / launch; 'launch' means the date is a floor).

TRUST: fundstelle is the gazette citation of the authentic text — the citation a court accepts. authoritative_source names what our copy is (a consolidated, non-official reading version) and where the binding text lives. Quote the provision from markdown; the reader page at url carries per-Absatz anchors (#abs-N) if you want to deep-link a single Absatz.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
lawYesLaw abbreviation, or a `law_key` (`slug` in search results) when an abbreviation is ambiguous.
refYesProvision number without § or Art. A sub-unit ('Abs. 1', 'lit. f') is dropped: the whole provision is returned.
as_ofNoReturn the version stored for this date.
formatNo'markdown' (default, compact, quotable) or 'json' for the structured payload.markdown

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses response fields (first_observed, valid_to, date_precision, amendment_note), warns that first_observed is not the legal Inkrafttreten, and explains outside_coverage behavior for pre-archive dates. It also clarifies the trust semantics of fundstelle and authoritative_source.

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?

The description is structured into core purpose, parameter rules, point-in-time caveats, and trust metadata; every sentence carries actionable information. The front-loaded purpose statement is followed by logical sections, and no sentence is filler.

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 covers the key return fields, the outside_coverage error case, and how to quote or deep-link. It gives an agent enough to call the tool and interpret results correctly, including caveats about date precision and authoritative sources.

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?

Despite 100% schema coverage, the description adds material meaning: ref must be the bare number with no §/Art and may carry letter suffixes, sub-units are dropped, aliases/case variants resolve, and as_of triggers version lookup with archive limits. This goes well beyond the schema examples.

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 opening line names the exact deliverable: 'the text of one provision, by default as clean Markdown.' This is a specific verb+resource, and the 'one provision' scope distinguishes it from siblings like listNormVersions, getChanges, and search, which serve different retrieval tasks.

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?

The description gives clear operational context: how to format law and ref, when to use as_of, and the coverage caveat for dates before 2019-06-10. It does not explicitly name sibling tools as alternatives or say when not to use this tool, so it stops short of full selection guidance.

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