Skip to main content
Glama
nulegal-startup

recht-mcp

by nulegal-startup
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Get statute text

getNorm
Read-onlyIdempotent

Retrieve a German legal provision's text by law abbreviation and section number, optionally as of a specific date, returned as clean Markdown for citation.

Instructions

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 resolve, and CASE IS READ: 'LwG' is the federal Landwirtschaftsgesetz while 'LWG' is a Land statute (Bayern's Landeswahlgesetz, NRW's Landeswassergesetz), so write the abbreviation the way your citation writes it. A spelling that matches no law exactly still resolves case-insensitively, and a miss lists the other laws the abbreviation names under other_laws, each with a law_key you can call again with.

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 observedv1.0.1

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already mark this as read-only, idempotent, and non-destructive, and the description adds substantial behavioral detail beyond that: case-sensitive abbreviation handling, ambiguous-law fallback with other_laws, version archive boundaries, the distinction between first_observed and legal Inkrafttreten, and trust/citation semantics. This is rich, valuable context.

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 long but every section earns its place: core purpose first, then parameter semantics, point-in-time behavior, response fields, and trust guidance. Clear section headers and front-loaded key facts make it easy for an agent to skim and apply.

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 takes on full responsibility for explaining return values and did so thoroughly: version_coverage, outside_coverage, first_observed, valid_to, date_precision, amendment_note, fundstelle, authoritative_source, markdown, url, and other_laws are all mentioned with practical guidance. An agent has what it needs to invoke and interpret the tool correctly.

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 100% and each parameter has meaningful schema descriptions and examples. The description adds further semantic nuance for 'law' and 'ref', especially the citation-style abbreviation, case sensitivity, alias resolution, and dropping sub-units. Format is only lightly covered, but the schema enum and default already handle it.

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 opens with a specific verb and resource: it returns 'the text of one provision' as clean Markdown. It clearly distinguishes this from sibling list/version/search tools by emphasizing a single provision in compact form.

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 usage context: how to cite law abbreviations, what ref means, how case-sensitivity and ambiguity resolve, and when to use as_of. It does not explicitly name sibling tools or state when not to use this tool, but the context is strong enough for an agent to route correctly.

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