Skip to main content
Glama
Sign In

nu:legal Deutsches Recht

by eu.nulegal
OverviewDiscussionsAdmin

Get statute text

getNorm
Read-onlyIdempotent

The text of one provision (§ or Article) as Markdown. law is the abbreviation ('BGB', 'StGB', 'DSGVO'; Hessen: 'HBO'), ref the number ('573', '3a'). For the text on a past date add as_of (YYYY-MM-DD; versions are held from 2019-06-10; for EU acts, the EMRK and some Landesrecht from the day their held text applies). The answer says how many versions are held (versions_held) and how many decisions cite the provision (cited_by). A version date is not always its Inkrafttreten: date_basis says what it is. For most federal law it is the day the text was first seen here; for an EU act it is the day its text applies (applies_from). With compare_to (YYYY-MM-DD) the answer adds diff, the word diff to the version stored for that date. DATES: each version carries date_basis, in_force_from (a date the source states) and observed_from (first seen here), each with its *_basis; the one we do not hold is null. Example: {"law": "BGB", "ref": "573"}

Input 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
compare_toNoCompare with the version stored for this date: the answer adds `diff`, the word diff between the two versions (the older one is `from`), each side with its `date_basis`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / compare_to
      Added value: +{
+  "description": "Compare with the version stored for this date: the answer adds `diff`, the word diff between the two versions (the older one is `from`), each side with its `date_basis`.",
+  "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+  "type": "string"
+}
  2. Changed1 schema field changed
    • addedInput schema / properties / as_of / examples
      Added value: +[
+  "2021-01-01"
+]
  3. First observed

TDQS

A4.1/5.0
Behavior5/5

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

With annotations already declaring read-only, idempotent, non-destructive behavior, the description goes well beyond them: it explains that the answer includes `versions_held` and `cited_by`, that `date_basis` may differ from Inkrafttreten, and that `diff` is a word diff with the older side as `from`. This is unusually rich behavioral context for a read tool.

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

Conciseness4/5

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

Front-loaded with the core purpose and argument shapes, and the optional-parameter semantics follow in a logical order. It is dense but mostly earns its length, though the standalone 'DATES:' sentence partially repeats the `date_basis` explanation given earlier.

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?

There is no output schema, so the description must carry return-value semantics — and it does, naming `versions_held`, `cited_by`, `diff`, and the date basis fields plus null handling. For a 5-parameter, enum-bearing lookup tool this is complete enough to call correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so baseline is 3. The description's parameter prose (law = abbreviation, ref = number, compare_to adds `diff`) largely restates what the schema already documents; it adds only marginal format detail (e.g. 'Hessen: HBO') beyond structured fields.

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?

Opens with a specific verb+resource+format: 'The text of one provision (§ or Article) as Markdown', and clarifies the shape of both required arguments. It does not name any sibling (e.g. listNormVersions or getChanges) to differentiate itself, so an agent must infer the boundary from the sibling list.

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?

Gives clear conditional guidance for the optional parameters: use `as_of` for text on a past date, `compare_to` to get a word diff, and notes coverage limits (versions held from 2019-06-10). It stops short of explicitly excluding/redirecting to alternatives like listNormVersions when only version metadata is needed.

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

All nu:legal Deutsches Recht toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources