PRIMAMCP

Name: PRIMAMCP
Author: PLANIT-TECH

by io.github.PLANIT-TECH

Overview Discussions Admin

Server Details

Verified, citable German & EU law for any LLM. Daily updates from official sources, hosted in DE.

Ownership verified

Status: Healthy
Uptime: 76.3% over 33 days
Last Tested: 2026-10-03 22:08
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: PLANIT-TECH/primamcp
GitHub Stars: 11
Server Listing: Lawbster

TDQS

A4.2/5.0

Scored 2026-09-30 14:50 across 11 tools

Disambiguation4/5

The core retrieval tools are explicitly differentiated: legal_lookup for a known citation, legal_lookup_batch for several citations, legal_search for topic questions, and legal_find_citing_decisions for citation inventories. The only real overlap is between legal_search (with cited_norm filter) and legal_find_citing_decisions, which the descriptions acknowledge and partially disentangle, and lookup vs lookup_batch, which boundaries are clearly stated.

Naming Consistency4/5

Nine tools share a clean 'legal_verb_noun' pattern (legal_lookup, legal_get_toc, legal_list_laws, legal_find_citing_decisions, etc.) with consistent snake_case and verb-first ordering. The two generic MCP tools list_resources and read_resource drop the prefix and use a different noun-verb order, a minor but noticeable deviation.

Tool Count5/5

Eleven tools is well within the ideal range. Each tool earns its place: retrieval (search, lookup, batch, citing-decisions), navigation (toc, context), enrichment (materials, stats), discovery (list_laws), and resource plumbing.

Completeness4/5

The surface covers the full legal-research lifecycle: discovery, topic search, exact resolution, batch resolution, context/navigation, citation-graph traversal, legislative intent, and stats. Minor gaps exist around retrieving a complete decision text in one call and any export/annotation capability, but agents can work around these via toc/context chaining.

Available Tools

11 tools

legal_find_citing_decisionsFind Citing Court DecisionsA

Read-onlyIdempotent

Inspect

List German federal court decisions (BGH, BVerwG, BFH, BAG, BSG, BVerfG, BPatG, GmSOGB), German state court decisions (Sächsisches OVG, Oberverwaltungsgericht NRW, Oberlandesgericht Düsseldorf, Oberlandesgericht Hamm, Oberlandesgericht Köln, Landesarbeitsgericht Düsseldorf, Landesarbeitsgericht Hamm, Landesarbeitsgericht Köln, Landessozialgericht NRW, Finanzgericht Düsseldorf, Finanzgericht Köln, Finanzgericht Münster, Verfassungsgerichtshof NRW) and EU court decisions (EuGH, EuG) citing a specific legal provision — the raw citation inventory, newest first. legal_search with the cited_norm filter searches within the same population and ranks the candidates against a specific question or fact pattern.

Matching is at paragraph level: '§ 280 Abs. 1 BGB' finds all decisions citing § 280 BGB. Returns decisions with Leitsatz (key legal principle summary) and ECLI identifier. Each decision also exposes a cited_norms array — a list of canonical citation strings (e.g. ['Art. 101 AEUV', '§ 280 BGB', 'Art. 6 DSGVO']) describing the other provisions the decision references. Pass an element back to legal_lookup to retrieve the norm's text and walk the citation graph (e.g. discover which BGB / DSGVO articles a BGH judgment hinges on, then resolve them in turn). German provisions, EU treaty articles (AEUV / EUV) and EU instruments with a registered short alias resolve directly — EuGH prose like 'der Verordnung (EU) 2016/679' is reverse-mapped to those aliases (DSGVO, KIVO, DSA, …) where one exists. A numbered EU instrument without a registered alias is shown in the compact 'EURL 98/59' form: it identifies the instrument but is not yet resolvable via legal_lookup.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of decisions to return (default 10).
`cited_norm`	Yes	The legal provision, e.g. '§ 823 BGB', 'Art. 6 DSGVO'. For an EU directive both the directive article ('Art. 9 Richtlinie 2011/83/EU') and the national transposition norm ('§ 355 BGB') are valid filters: the directive article matches EU case law (EuGH/EuG) and German decisions citing it directly (richtlinienkonforme Auslegung), while the transposition norm matches the larger body of German decisions applying the transposed rule. The transposition norm covers everyday German case law, the directive article EU-level interpretation. EU regulations (DSGVO, MDR) are cited directly.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint, idempotentHint), the description reveals paragraph-level matching behavior ('§ 280 Abs. 1 BGB' finds all decisions citing § 280 BGB) and the paragraph level is not visible in the schema. It also discloses the resolution rules for EU instruments, including that some will be shown in compact 'EURL 98/59' form and are not resolvable via legal_lookup. These behavioral traits materially affect agent expectations.

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?

The description is long but every sentence contributes functional detail, from the court list to the matching rule to the citation-graph workflow. It is front-loaded with the core purpose and the distinction from legal_search. Although dense, it is not padded; a 4 reflects that it could be tightened slightly without losing information.

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?

Given the tool's complexity — a broad court population, paragraph-level matching, and EU instrument resolution — the description covers all essential aspects: scope, behavior, output fields, and integration with legal_lookup. It also benefits from an output schema, so return structure is already defined. No critical operational detail is missing.

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?

The schema already covers the cited_norm parameter's examples and directive/transposition distinction (100% coverage), so the baseline is 3. The description adds important semantic detail: the paragraph-level matching rule clarifies that the filter is not exact string matching, and the EU instrument resolution paragraph explains how the parameter will be interpreted for EU instruments. This goes beyond the schema's description.

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 'List ... court decisions ... citing a specific legal provision — the raw citation inventory, newest first,' providing a specific verb and resource. It explicitly distinguishes itself from the sibling legal_search by stating that legal_search ranks candidates against a question or fact pattern, while this tool returns the raw, newest-first inventory. This makes the tool's unique role clear.

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

Usage Guidelines5/5

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

The description explicitly names legal_search as the alternative and explains the selection criterion: use this tool for an exhaustive citation inventory, use legal_search when ranking against a specific question or fact pattern. It also points to legal_lookup for resolving elements of the cited_norms array, giving a concrete workflow. This is explicit when/when-not guidance.

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

legal_get_contextGet Surrounding ProvisionsA

Read-onlyIdempotent

Inspect

Get a stored text section and its neighbours in document order, including consecutive provisions, parts of a long provision or sections of a court decision. Serves questions that span consecutive provisions or need the surrounding context of a norm's scope.

Requires a norm_id from legal_search, legal_lookup or legal_get_toc. Returns target, before and after sections, with up to 10 neighbours in each direction. Each section's id is a valid norm_id for a subsequent call. A window may cross provision boundaries; norm_key identifies which provision each section belongs to. legal_get_toc gives the law-wide overview.

ParametersJSON Schema

Name	Required	Description
`after`	No	Number of stored text sections after the target (max 10).
`before`	No	Number of stored text sections before the target (max 10).
`norm_id`	Yes	norm_id from legal_search, legal_lookup or legal_get_toc, or a section's id from legal_get_context.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the read-only and idempotent annotations, the description discloses return structure (target, before, after sections with up to 10 neighbors each), that windows may cross provision boundaries, and that section IDs can be reused as norm_ids. These are valuable behavioral details not derivable from annotations.

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 two tight paragraphs with the core purpose front-loaded, followed by usage and return details. Every sentence adds value, with no redundancy or 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?

The description, combined with the output schema and annotations, fully equips an agent to call the tool correctly: it covers input requirements, output structure, boundary-crossing behavior, and ID reuse. Nothing essential is missing.

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 descriptions cover all parameters (100% coverage). The description adds context about norm_id's provenance and reuse, enhancing the schema's meaning. However, after/before parameters are not further elaborated, so a 4 is appropriate given the high baseline.

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 clearly states the tool retrieves a stored text section and its neighbors in document order, explicitly covering consecutive provisions and court decision sections. It distinguishes itself from siblings by emphasizing context retrieval, which is unique among the listed tools.

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

Usage Guidelines5/5

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

It explicitly states when to use: for questions spanning consecutive provisions or needing surrounding context. It also specifies the required input source (norm_id from legal_search, legal_lookup, or legal_get_toc) and contrasts with legal_get_toc for law-wide overviews, effectively guiding tool selection.

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

legal_get_materialsGet Legislative Materials (Begründung)A

Read-onlyIdempotent

Inspect

Return the official legislative reasoning (Gesetzesbegründung / explanatory memorandum from a Bundestags-Drucksache) for a specific German federal provision — the source for genetic/historical interpretation: what the legislator intended with this norm.

It answers questions that turn on a norm's purpose (ratio legis / 'why does this rule exist'), the meaning of an unclear or undefined term, whether a regulatory gap is planwidrig (grounds an analogy) or a deliberate silence (grounds an Umkehrschluss), or what a specific amendment was meant to achieve — the everyday uses of materials in an Auslegung or a Schriftsatz. Weight: the Begründung is strong evidence of legislative intent but not binding, and the statutory wording stays the outer limit of any reading.

Pass a provision like '§ 823 BGB' or 'Art. 87a GG'. Returns the linked Begründungs-Abschnitte newest first, each with its 'BT-Drs.' Fundstelle, the reasoning text, and the other norms the same change amended ('target_norm_keys'). Complements legal_find_citing_decisions (how courts apply a norm) with the drafting intent behind it. Covers amendments since 1949 to German federal law (gesetze-im-internet corpus) only; an unknown or non-German provision returns no materials. Excerpts are prepared from the Bundestag-extracted text, not the original PDF.

ParametersJSON Schema

Name	Required	Description	Default
`norm`	Yes	The legal provision, e.g. '§ 823 BGB', 'Art. 87a GG'.
`limit`	No	Maximum number of Begründung segments to return (default 10).

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already indicate readOnly, idempotent, and non-destructive behavior, so the bar is about added context. The description adds return ordering ('newest first'), output fields ('BT-Drs.', reasoning text, 'target_norm_keys'), the no-materials behavior for unknown/non-German provisions, the non-binding weight of the Begründung, and the fact that excerpts come from Bundestag-extracted text rather than the original PDFs.

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 longer than average, but every sentence adds decision-relevant information: purpose, interpretive weight, usage scenarios, input format, output shape, sibling distinction, coverage limits, and source caveat. The primary action is front-loaded in the first sentence, and the rest is structured logically.

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?

For a legal research tool with this complexity, the description covers what it returns, how it orders results, what input to pass, what scope limitations apply, how to interpret the evidence weight, and how it differs from the closest sibling. Nothing essential for an agent to select and call it correctly is missing.

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%: both 'norm' and 'limit' are already fully described in the input schema. The description repeats the provision format ('§ 823 BGB', 'Art. 87a GG') and adds contextual guidance about scope, but it does not add meaningfully new parameter-level semantics beyond what the schema already provides.

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: 'Return the official legislative reasoning (Gesetzesbegründung ...) for a specific German federal provision.' It also explicitly separates this tool from legal_find_citing_decisions by contrasting legislative intent with court application, so an agent can distinguish it from its siblings without inspecting schemas.

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

Usage Guidelines5/5

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

It explains clearly when to use the tool: for questions about ratio legis, undefined terms, planwidrig gaps, deliberate silences, and amendment intent. It also names the alternative sibling legal_find_citing_decisions and states the boundary: this covers drafting intent, the other covers how courts apply a norm. It additionally notes the 1949-present and German-federal-law-only scope.

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

legal_get_statsShow Corpus StatisticsA

Read-onlyIdempotent

Inspect

Get database and search index statistics including counts of laws, norms, and indexed vectors. Use for health checks or to understand the scope of the legal corpus.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds detail about the nature of the statistics (database and search index, specific counts), which is useful but minimal. No contradiction with annotations.

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 two sentences with no wasted words. It front-loads the core function (getting statistics) and then provides usage context. Every sentence earns its place.

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?

The tool has no parameters, the annotations fully disclose safety and idempotency, and an output schema exists to define the return format. The description covers the tool's purpose and use cases completely for an agent to decide when to call it.

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?

The tool has zero parameters and the schema is an empty object (100% coverage). The description does not need to explain parameters since none exist. Baseline of 4 is appropriate for a no-parameter tool.

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 clearly states the tool retrieves database and search index statistics, listing specific counts (laws, norms, indexed vectors). It uses a specific verb (get) and resource (stats), and is distinct from all sibling tools, which focus on searching, looking up, or retrieving materials rather than corpus statistics.

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 explicitly states when to use the tool: for health checks or understanding the scope of the legal corpus. It does not mention alternative tools, but no sibling tool serves this purpose, so the guidance is clear and sufficient.

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

legal_get_tocBrowse Law Table of ContentsA

Read-onlyIdempotent

Inspect

Get the table of contents of a specific law or court decision. Returns norm keys (e.g. '§ 1', 'Art. 3'), titles, and chapter headings in document order.

Gives the overview of a law's structure; a returned norm_id feeds legal_get_context for the full text. Paginated for large laws.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max entries per page (default 100).
`offset`	No	Start position for pagination.
`language`	No	Document language: 'de' (default, German-language documents from German and EU sources) or 'en' (currently EDPB/EDSA data-protection guidance only). DE and EN are separate corpora — a document published in both languages has one entry per language under the same abbreviation. 'en' selects the English corpus regardless of the answer language; 'edsa' is published mostly in English.
`source_type`	No	'gii', 'eurlex', 'eurlex_caselaw', 'rechtsprechung', 'bverfge', 'bverwg', 'sachsen_rechtsprechung', 'nrw_rechtsprechung', 'bayern_gesetze', 'nrw_gesetze', 'verwaltungsvorschriften', 'edsa', 'dsk' or 'gesetzesmaterialien'. Empty = auto-detect; where an abbreviation names a law in two sources, the answer lists both. Note: 'edsa' is published mostly in English: language='en' covers the full set, the DE default only the translated documents.
`law_abbreviation`	Yes	Law abbreviation, e.g. 'bgb', 'dsgvo', 'stgb'.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already mark the tool as read-only, idempotent, and non-destructive, so the description does not need to repeat that. It adds useful behavioral context beyond annotations: results are in document order, pagination exists for large laws, and the output feeds a downstream tool.

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 appropriately sized: one front-loaded sentence states the core action and return values, and a second compact sentence provides the key workflow hint and pagination note. No wasted words.

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?

Given the output schema, rich parameter schemas, and annotations, the description covers what an agent needs to select and invoke the tool correctly. It explains the tool's role in the larger workflow (navigate TOC → get_context) and notes the pagination behavior.

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?

Parameter coverage in the schema is 100%, so the schema already documents each parameter, including defaults, ranges, and enum semantics. The description adds no new parameter-level detail; the mention of pagination aligns with limit/offset but does not go beyond the schema.

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 clearly states the tool fetches the table of contents for a specific law or court decision and enumerates the returned items (norm keys, titles, chapter headings). It uses a specific verb plus resource and distinguishes itself from legal_get_context by framing this as the structural overview.

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 explains when to use it—when an overview of a law's structure is needed—and explicitly connects the returned norm_id to legal_get_context for full text. It does not name alternatives or exclusions, but the intended usage path is clear enough to guide an agent.

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

legal_list_lawsList Available LawsA

Read-onlyIdempotent

Inspect

List available laws, regulations, and court decisions in the database. Returns abbreviation, title, source type, jurisdiction, document kind, and version date for each entry.

Unfiltered listings can contain thousands of entries; pass a search term or source_type to keep responses focused. Useful for discovering valid law abbreviations to use as filters in legal_search; legal_get_toc shows a listed law's structure.

Not an existence check for a specific law: EUR-Lex entries store the official long title, so a short name or number can miss a law that is in the corpus. legal_lookup with a citation or legal_search with a topic provides alternative retrieval paths; a missing match does not prove absence from the corpus.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max results per page (default 50).
`offset`	No	Start position for pagination.
`search`	No	Case-insensitive search on abbreviation, title and official short designation ('Elektronischer-Rechtsverkehr-Verordnung'), e.g. 'bgb', 'datenschutz'. Also accepts a CELEX number ('32022L2555') or an EU instrument reference ('2022/2555', 'Richtlinie (EU) 2022/2555') and resolves it to the stored law.
`language`	No	Document language: 'de' (default, German-language documents from German and EU sources) or 'en' (currently EDPB/EDSA data-protection guidance only). DE and EN are separate corpora — a document published in both languages has one entry per language under the same abbreviation. 'en' selects the English corpus regardless of the answer language; 'edsa' is published mostly in English.
`source_type`	No	Filter: 'gii', 'eurlex', 'eurlex_caselaw', 'rechtsprechung', 'bverfge', 'bverwg', 'sachsen_rechtsprechung', 'nrw_rechtsprechung', 'bayern_gesetze', 'nrw_gesetze', 'verwaltungsvorschriften', 'edsa', 'dsk' or 'gesetzesmaterialien'. Note: 'edsa' is published mostly in English: language='en' covers the full set, the DE default only the translated documents.
`jurisdiction`	No	Filter by jurisdiction: 'de' (all German law — matches federal AND state law; federal only is source_type='gii'), 'eu', 'de_by' (Bavaria only), 'de_nw' (North Rhine-Westphalia only), 'de_sn' (Saxony only). Empty = no jurisdiction filter.
`document_kind`	No	Filter by document class: the norm subtypes 'statute', 'regulation' and 'directive' form ONE class (any of them lists all three); 'decision' (court case-law), 'guidance' (supervisory-authority soft law, EDSA/DSK) and 'explanatory_memorandum' (legislative materials) are separate classes.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior1/5

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

The description adds useful behavioral context (scale, long-title mismatch, missing matches do not prove absence), but it directly contradicts the openWorldHint:false annotation, which implies a closed world where absence means non-existence. This contradiction mandates a score of 1 and flags an annotation contradiction.

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 paragraphs, each earning its place: purpose, usage guidance, and caveat with alternatives. No filler, and the core purpose is front-loaded in the first sentence.

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?

Given the rich schema (100% coverage) and output schema, the description covers all essential usage context: what it returns, when to use it, what it is not for, and how to manage large listings. The openWorldHint contradiction is a behavioral transparency issue, not a completeness gap.

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 the schema fully documents all seven parameters. The description adds only a general note to pass search or source_type to focus results, which is practical but not additional parameter-level semantics. Baseline 3 applies.

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?

States a specific verb and resource: lists laws, regulations, and court decisions in the database, and enumerates returned fields. Explicitly distinguishes itself from siblings by positioning itself as the way to discover law abbreviations for legal_search, while legal_get_toc shows structure, and clarifies it is not an existence check.

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

Usage Guidelines5/5

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

Provides explicit when-to-use guidance: discovering valid law abbreviations for legal_search. Names alternatives (legal_lookup, legal_search) and states when not to use it (existence check), plus a practical tip to filter for focused responses. This leaves little to inference.

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

legal_lookupLook Up Provision by CitationA

Read-onlyIdempotent

Inspect

Retrieve a specific legal provision by citation (e.g. '§ 823 BGB', 'Art. 6 DSGVO', '§ 280 Abs. 1 BGB'), or a court decision by Aktenzeichen or ECLI (e.g. 'VII ZR 184/14', 'BGH VII ZR 184/14', 'C-184/14', 'ECLI:DE:BGH:2017:050117BVIIZR184.14.0'). Citation order is flexible — '§ 9 DSGVO', 'DSGVO Art. 9', 'Artikel 9 DSGVO' all resolve correctly. is_exact_match reports whether the citation was matched exactly; non-exact results can be a semantic fallback, the first section of an annex, or an uncertain decision match. The result hint explains which case applies; found=true alone does not prove citation identity. Provision text is reassembled where available; content_truncated and the result hint identify incomplete text and its continuation. A decision lookup returns its lead section (Leitsatz); further sections are reachable via legal_get_toc or legal_get_context on the returned norm_id.

ParametersJSON Schema

Name	Required	Description	Default
`citation`	Yes	Full citation string, e.g. '§ 823 BGB' or 'VII ZR 184/14'
`language`	No	Document language: 'de' (default, German-language documents from German and EU sources) or 'en' (currently EDPB/EDSA data-protection guidance only). DE and EN are separate corpora — a document published in both languages has one entry per language under the same abbreviation. 'en' selects the English corpus regardless of the answer language; 'edsa' is published mostly in English.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

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 and idempotent, and the description adds substantial behavioral nuance: flexible citation order, fallback matching semantics, found=true not proving identity, content reassembly/truncation behavior, and decision lead-section handling. This goes far beyond the structured fields and prevents false expectations.

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 front-loaded with the purpose and uses every subsequent sentence to clarify a distinct and important behavior—match semantics, result hints, truncation, or follow-up tools. No filler, repetition, or irrelevant detail appears despite the heavy domain complexity.

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?

For a complex legal lookup tool, the description covers input formats, output semantics (is_exact_match, result hint, content_truncated, norm_id), fallback behavior, and onward navigation to sibling tools. The presence of an output schema further reduces the burden, yet the description still explains the critical non-obvious return-field meanings.

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?

The input schema already fully describes both parameters, so the baseline is 3. The description adds extra value by explaining citation-order flexibility and giving realistic formats for laws, decisions, and ECLI identifiers, while the language parameter remains documented only in the schema. This is a solid enhancement without being exhaustive.

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 ('Retrieve') and a clear resource ('a specific legal provision by citation, or a court decision by Aktenzeichen or ECLI'), immediately distinguishing this from broad search tools like legal_search. The included citation examples and the naming of legal_get_toc/legal_get_context for follow-up work reinforce what this tool is and is not.

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 clearly signals 'use this when you have a concrete citation or case number' and even points to legal_get_toc/legal_get_context for continued exploration of a decision. It does not explicitly state when not to use it versus legal_search or legal_lookup_batch, but the emphasis on 'specific' and 'by citation' makes the primary use case unambiguous.

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

legal_lookup_batchLook Up Multiple ProvisionsA

Read-onlyIdempotent

Inspect

Retrieve multiple cited provisions or decisions in a single call without semantic fallback. Accepts 1-20 citations — norm citations and court-decision references, same forms as legal_lookup (e.g. ['§ 823 BGB', 'Art. 6 DSGVO', 'VII ZR 184/14']). Citations not found appear as found=false. Norm citations require an exact match. Decision references follow the same resolution as legal_lookup and can yield ambiguous, relaxed-reference or title-only matches; is_exact_match and the hint report that uncertainty. Each entry has its own match status and any ambiguity or truncation hint. Decision matches return the lead section, not the complete judgment. Fuzzy resolution of a hard-to-find provision belongs to legal_lookup, not to this tool.

ParametersJSON Schema

Name	Required	Description	Default
`language`	No	Document language: 'de' (default, German-language documents from German and EU sources) or 'en' (currently EDPB/EDSA data-protection guidance only). DE and EN are separate corpora — a document published in both languages has one entry per language under the same abbreviation. 'en' selects the English corpus regardless of the answer language; 'edsa' is published mostly in English.
`citations`	Yes	List of citation strings, e.g. ['§ 823 BGB', 'Art. 6 DSGVO']. Max 20.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, consistent with the description's 'Retrieve' framing. The description adds valuable behavior beyond annotations: no semantic fallback, not-found entries report found=false, exact-match requirement for norms, ambiguous/relaxed/title-only matches for decisions reported via is_exact_match and hints, and that decision matches return only the lead section. No contradiction with annotations.

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?

The description is front-loaded with the core purpose and each subsequent sentence carries distinct information: batch size, citation forms, not-found behavior, matching semantics, ambiguity reporting, and lead-section return. It is dense but slightly verbose in places (e.g., restating is_exact_match and hint reporting), though no sentence is pure filler.

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

Completeness4/5

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

With an output schema present, return values are already covered structurally. The description additionally handles batch limits, matching semantics, ambiguity/truncation hints, and lead-section behavior. The language parameter is fully documented in the schema (100% coverage). Minor gaps like explicit error handling for invalid citation formats are not essential given the thorough schema.

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 coverage is 100%, so the schema already documents both parameters well. The description adds meaningful context for the citations parameter (example forms matching legal_lookup, the found=false behavior, exact-match vs relaxed-match semantics), which slightly elevates it, but most parameter detail is already in the schema. Baseline 3 is appropriate.

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+resource statement ('Retrieve multiple cited provisions or decisions in a single call') and immediately distinguishes the tool from its sibling by adding 'without semantic fallback' and later routing fuzzy resolution explicitly to legal_lookup. An agent can tell this batch tool apart from legal_lookup and legal_search without opening the schema.

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

Usage Guidelines5/5

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

The description states when to use it (multiple citations in one call, 1-20) and explicitly when not to: 'Fuzzy resolution of a hard-to-find provision belongs to legal_lookup, not to this tool.' It also clarifies that norm citations require exact match vs decision references that allow relaxed/ambiguous matching, giving the agent a clear decision rule for routing.

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

legal_searchSearch Legal DocumentsA

Read-onlyIdempotent

Inspect

Search legal documents across jurisdictions (DE federal, EU, Bavaria, North Rhine-Westphalia, Saxony) using hybrid semantic + keyword search. Returns ranked results with content snippets, not full text.

Suitable for topic questions and case facts when the relevant provision or decision is not yet known. A known citation is resolved by legal_lookup; several known citations by legal_lookup_batch. Natural-language questions using the documents' terminology usually rank better than keyword lists or doctrinal labels, e.g. 'Wann verjährt ein Schadensersatzanspruch?' or 'Wie sind mehrdeutige Vertragsklauseln auszulegen?'. Ranking indicates textual relevance, not legal applicability or exhaustive coverage. document_kind separates norms from case-law: the three norm subtypes ('statute'/'regulation'/'directive') form one filter class — any of them admits all three, so an EU regulation or directive is never hidden by a reflexive 'statute'. 'decision' restricts to court decisions and drops every norm before ranking, so it can hide the statute that answers a rule question. Without a document_kind filter, norms, case law and guidance can rank together, subject to other filters. This supports mixed questions (norm + its case-law application) and unclear German-vs-EU scope (e.g. data protection: BDSG vs DSGVO). Legislative materials are excluded by default and require explicit scope. A statute law_abbreviation combined with a decision scope ('decision', a decision source_type, court or decision_type) yields an empty set, because decisions carry file-number identifiers, not statute abbreviations; cited_norm filters decisions by the provision they cite. legal://filter_values documents the per-value definitions and the disambiguation list. law_abbreviation, jurisdiction and source_type restrict the law, jurisdiction and source respectively; when omitted, these filters add no restriction. Other filters and the corpus-language default still apply. legal://rechtsrahmen lists which law governs which domain (EU vs national, substantive vs procedural).

Common mix-ups (which law governs):

Procedural law by jurisdiction: ZPO (zivilrecht), STPO (strafrecht), VWGO (verwaltungsrecht), ARBGG (arbeitsrecht), SGG (sozialrecht), BVERFGG (verfassungsrecht), FAMFG (familienrecht)
AO, ESTG, KSTG, USTG, FGO: AO=procedure, EStG/KStG/UStG=substantive
VVG, BGB: Insurance rescission → BGB §§ 812ff, not VVG
VERSAUSGLG, FAMFG: VersAusglG=substantive, FamFG=procedure
APOG, AMG: ApoG=operation, AMG=drug approval
WEHRPFLG, SG: WPflG=conscription, SG=soldiers
AGG, BETRVG: AGG=anti-discrimination, BetrVG=works council

ParametersJSON Schema

Name	Required	Description
`court`	No	Filter by court: BGH, BVerwG, BFH, BAG, BSG, BVerfG, BPatG, GmSOGB, Sächsisches OVG, Oberverwaltungsgericht NRW, Oberlandesgericht Düsseldorf, Oberlandesgericht Hamm, Oberlandesgericht Köln, Landesarbeitsgericht Düsseldorf, Landesarbeitsgericht Hamm, Landesarbeitsgericht Köln, Landessozialgericht NRW, Finanzgericht Düsseldorf, Finanzgericht Köln, Finanzgericht Münster, Verfassungsgerichtshof NRW, EuGH, EuG.
`query`	Yes	Natural-language question or case facts, e.g. 'Wann verjährt ein Schadensersatzanspruch?'. Terms used in the relevant legal documents help retrieval.
`top_k`	No	Number of results to return (default 5).
`chapter`	No	Narrows to one chapter/section within a law; reduces recall. Only meaningful together with law_abbreviation.
`date_to`	No	Include results until this date (YYYY-MM-DD).
`language`	No	Document language: 'de' (default, German-language documents from German and EU sources) or 'en' (currently EDPB/EDSA data-protection guidance only). DE and EN are separate corpora — a document published in both languages has one entry per language under the same abbreviation. 'en' selects the English corpus regardless of the answer language; 'edsa' is published mostly in English.
`date_from`	No	Include results from this date onwards (YYYY-MM-DD).
`cited_norm`	No	Restrict results to court decisions that verifiably cite this provision (citation-graph filter, e.g. '§ 573 BGB' or 'Art. 6 DSGVO'). With a case-specific query — e.g. query='Eigenbedarfskündigung Härtefall hohes Alter', cited_norm='§ 573 BGB' — citing candidates are ranked by relevance to the query. A citation does not establish applicability to the facts. legal_find_citing_decisions yields the unranked inventory, newest first. Matching is paragraph-level (Abs./Satz/Nr. are ignored). Only court decisions carry citations, so this filter implicitly restricts to case law — no document_kind needed. For an EU directive both the directive article ('Art. 9 Richtlinie 2011/83/EU') and the national transposition norm ('§ 355 BGB') are valid filters: the directive article matches EU case law (EuGH/EuG) and German decisions citing it directly (richtlinienkonforme Auslegung), while the transposition norm matches the larger body of German decisions applying the transposed rule. The transposition norm covers everyday German case law, the directive article EU-level interpretation. EU regulations (DSGVO, MDR) are cited directly.
`source_type`	No	Filter by source: 'gii' (German federal laws like BGB, StGB), 'eurlex' (EU legislation, including regulations like DSGVO/DSA, directives and treaties), 'eurlex_caselaw' (EU court decisions, EuGH/EuG), 'rechtsprechung' (federal court decisions, 2010 onwards), 'bverfge' (BVerfG leading decisions from the official reporter BVerfGE, up to 2009 — the reported slice, not every BVerfG decision of that era), 'bverwg' (BVerwG judgments (Urteile) up to 2009), 'sachsen_rechtsprechung' (Saxon OVG decisions), 'nrw_rechtsprechung' (NRW higher-court decisions: OVG/OLG/LAG/LSG/FG/VerfGH), 'bayern_gesetze' (Bavaria), 'nrw_gesetze' (North Rhine-Westphalia), 'verwaltungsvorschriften' (federal administrative regulations, e.g. TA Luft, BMGVwV), 'edsa' (EDPB/EDSA data-protection guidance — soft law, not enacted norms; mostly English, see the language parameter), 'dsk' (Datenschutzkonferenz guidance: Orientierungshilfen, Kurzpapiere, Beschlüsse — the German supervisory authorities' reading of GDPR/BDSG), 'gesetzesmaterialien' (legislative materials — Gesetzesbegründung from Bundestag Drucksachen, the legislator's intent behind a federal norm; the corpus includes draft bills that never became law. Materials are opt-in: they appear with this value or document_kind='explanatory_memorandum', not in an unfiltered search). Empty = no source filter.
`jurisdiction`	No	Filter by jurisdiction: 'de' (all German law — matches federal AND state law, incl. Staatsverträge like the Medienstaatsvertrag), 'eu' (EU), 'de_by' (Bavaria only), 'de_nw' (North Rhine-Westphalia only), 'de_sn' (Saxony only — Saxon state law is not in the corpus, so this matches Saxon court decisions). 'de' includes state law; source_type='gii' restricts to federal statutes. Empty = no jurisdiction filter.
`decision_type`	No	Filter by decision type: 'Urteil' or 'Beschluss'.
`document_kind`	No	Filter by document class: the three norm subtypes 'statute', 'regulation' and 'directive' form ONE filter class — any of them admits all three, so they need not be told apart, and an EU regulation or directive is never hidden by a reflexive 'statute'. Three values discriminate: 'decision' restricts to court case-law (how a norm is applied), 'guidance' restricts to supervisory-authority soft law (EDPB/EDSA and Datenschutzkonferenz — authoritative readings of the GDPR/BDSG, not enacted norms and not binding), and 'explanatory_memorandum' restricts to legislative materials (Gesetzesbegründung / BT-Drucksachen — the legislator's intent behind a norm; ratio legis, purpose of an amendment). Materials are opt-in: reachable via this value, source_type='gesetzesmaterialien', or legal_get_materials for one provision, not in an unfiltered search. Empty = no document-class filter: norms, case law and guidance can rank together, subject to other filters. legal://filter_values documents the per-value definitions and disambiguation.
`law_abbreviation`	No	Restrict to the named document, e.g. 'bgb', 'dsgvo'. A statute abbreviation does not select decisions citing that statute; cited_norm selects those decisions. Omitted or null = no law filter.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds substantial behavioral context beyond annotations: ranking indicates textual relevance not legal applicability, document_kind filter-class semantics (the three norm subtypes admit all three), the empty-set behavior when combining law_abbreviation with decision scope, the exclusion of legislative materials by default, and the separate DE/EN corpora. It also discloses that 'decision' can hide the statute that answers a rule question — a genuine behavioral caveat.

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?

The description is long but every section earns its place: the opening sentence states the core function, the second paragraph gives usage guidance, the third explains filter interactions, and the final block lists common legal mix-ups. It is front-loaded with the most important information (what it does, when to use it) before the detailed filter semantics. The length is justified by the tool's complexity (13 parameters, 10 siblings, nuanced filter interactions), though a few sentences could be tightened.

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?

Given the tool's complexity — 13 parameters, 10 sibling tools, an output schema, and subtle filter interactions — the description is remarkably complete. It covers return format (ranked results with snippets, not full text), ranking semantics (textual relevance, not legal applicability), filter interactions (document_kind class behavior, law_abbreviation + decision empty set, cited_norm implicit case-law restriction), corpus defaults (legislative materials excluded by default, DE/EN separate corpora), and points to legal://filter_values and legal://rechtsrahmen for further reference. The output schema exists, so return values need not be re-explained. Nothing an agent needs to call this correctly is missing.

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%, so the baseline is 3. The description adds significant meaning beyond the schema: it explains the document_kind filter-class behavior (statute/regulation/directive admit all three), the interaction between law_abbreviation and decision scope (empty set), the cited_norm citation-graph semantics with paragraph-level matching, and the language parameter's separate-corpus behavior. It does not add per-parameter syntax details for every parameter, but the schema already provides those, and the description compensates where the schema is terse (e.g., source_type values are expanded with corpus meanings).

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: 'Search legal documents across jurisdictions... using hybrid semantic + keyword search' and immediately distinguishes itself from siblings by stating it returns ranked results with snippets, not full text. It explicitly names legal_lookup and legal_lookup_batch as the tools for known citations, making the differentiation concrete.

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

Usage Guidelines5/5

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

The description provides explicit when-to-use guidance: 'Suitable for topic questions and case facts when the relevant provision or decision is not yet known' and explicitly states when NOT to use it ('A known citation is resolved by legal_lookup; several known citations by legal_lookup_batch'). It also gives query-formatting advice (natural-language questions rank better than keyword lists) and documents common mix-ups about which law governs, which is directly actionable for an agent.

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

list_resourcesList ResourcesA

Read-only

Inspect

List all available resources and resource templates.

Returns JSON with resource metadata. Static resources have a 'uri' field, while templates have a 'uri_template' field with placeholders like {name}.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds that results split into static resources ('uri') versus templates ('uri_template'), which is genuinely useful behavioral context. It does not cover pagination or whether the list is complete/unbounded, so with annotations carrying the safety burden a 3 is appropriate.

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?

Three short sentences with the core purpose front-loaded and no filler. The second/third sentences describe the return shape, which slightly overlaps the existing output schema, but the uri vs uri_template distinction earns its place as a discriminator for callers.

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

Completeness4/5

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

An output schema already exists, so the description is not obligated to explain return values, yet it does add a useful layer about the two result shapes. Combined with the readOnly annotation and zero parameters, an agent has what it needs; only the relationship to read_resource is unstated.

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?

Zero parameters, so there is no parameter semantics to convey and the baseline of 4 applies. The description correctly focuses on output structure instead of inventing parameter detail.

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?

States a specific verb and resource ("List all available resources and resource templates") and further clarifies the two categories it returns. It is clear on its own, but never names or contrasts with the obvious sibling read_resource, so a small amount of differentiation is left to inference.

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

Usage Guidelines3/5

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

No explicit when-to-use or when-not-to-use guidance, and no mention of read_resource as the follow-up action. Usage is only implied by the discovery nature of the tool. For a zero-arg catalog tool this is adequate but thin.

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

read_resourceRead ResourceA

Read-only

Inspect

Read a resource by its URI.

For static resources, provide the exact URI. For templated resources, provide the URI with template parameters filled in.

Returns the resource content as a string. Binary content is base64-encoded.

ParametersJSON Schema

Name	Required	Description	Default
`uri`	Yes	The URI of the resource to read

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds genuine behavioral context beyond that: the return is a string and binary payloads are base64-encoded, which materially affects how an agent must handle the result. It omits error/not-found behavior, but the encoding disclosure is a real addition.

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?

Three short sentences, front-loaded with the core action and then the two caveats an agent needs. Zero wasted words, though the 'Returns...' sentence partially overlaps the existing output schema.

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

Completeness4/5

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

With an output schema present and annotations covering the read-only profile, the description need not detail return structure. It supplies the URI-construction nuance and encoding caveat, leaving only minor gaps such as invalid-URI or missing-resource behavior.

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% with a single string parameter, so baseline would be 3. The description goes beyond the schema by specifying that templated resources require the URI with template parameters already filled in, which is meaningful semantic guidance the schema does not carry.

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 gives a specific verb and resource ('Read a resource by its URI'), which cleanly separates it from list_resources and the legal_* tools. It does not explicitly name or contrast with any sibling, so it lands at a solid but not exemplary 4.

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

Usage Guidelines3/5

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

It explains how to construct the URI for static vs templated resources, which is practical invocation guidance, but never states when to pick this tool over alternatives (e.g., list_resources first, or the legal_* lookups) or any preconditions. Usage is implied rather than stated.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

7 tool updatesSep 21, 2026

Changedlegal_find_citing_decisions1 field changed

changedInput schema / properties / cited_norm / description

Previous value: -"The legal provision, e.g. '§ 823 BGB', 'Art. 6 DSGVO'. For an EU directive both the directive article ('Art. 9 Richtlinie 2011/83/EU') and the national transposition norm ('§ 355 BGB') are valid filters: the directive article matches EU case law (EuGH/EuG) and German decisions citing it directly (richtlinienkonforme Auslegung), while the transposition norm matches the larger body of German decisions applying the transposed rule. The transposition norm covers everyday German case law, the directive article EU-level interpretation; a plain legal_search on the topic reveals the transposition norm when it is unknown. EU regulations (DSGVO, MDR) are cited directly."New value: +"The legal provision, e.g. '§ 823 BGB', 'Art. 6 DSGVO'. For an EU directive both the directive article ('Art. 9 Richtlinie 2011/83/EU') and the national transposition norm ('§ 355 BGB') are valid filters: the directive article matches EU case law (EuGH/EuG) and German decisions citing it directly (richtlinienkonforme Auslegung), while the transposition norm matches the larger body of German decisions applying the transposed rule. The transposition norm covers everyday German case law, the directive article EU-level interpretation. EU regulations (DSGVO, MDR) are cited directly."

Changedlegal_get_context3 fields changed

changedInput schema / properties / after / description

Previous value: -"Number of norms after the target (max 10)."New value: +"Number of stored text sections after the target (max 10)."

changedInput schema / properties / before / description

Previous value: -"Number of norms before the target (max 10)."New value: +"Number of stored text sections before the target (max 10)."

changedInput schema / properties / norm_id / description

Previous value: -"norm_id from a prior legal_search or legal_lookup result."New value: +"norm_id from legal_search, legal_lookup or legal_get_toc, or a section's id from legal_get_context."

Changedlegal_get_toc4 fields changed

changedInput schema / properties / language / anyOf

Previous value: -[
-  {
-    "description": "Content language of legal documents.\n\nUses StrEnum so values compare equal to plain strings for\nseamless PostgreSQL/Qdrant compatibility.",
-    "enum": [
-      "de",
-      "en"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "description": "Document language, independent of the language of the answer.",
+    "enum": [
+      "de",
+      "en"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / language / description

Previous value: -"Corpus language: 'de' (default — the full German + EU corpus) or 'en' (English-language corpus: currently EDPB/EDSA data-protection guidance only; much smaller than 'de'). DE and EN are separate corpora — a document published in both languages has one entry per language under the same abbreviation. 'en' selects the English corpus regardless of the answer language; 'edsa' is published mostly in English."New value: +"Document language: 'de' (default, German-language documents from German and EU sources) or 'en' (currently EDPB/EDSA data-protection guidance only). DE and EN are separate corpora — a document published in both languages has one entry per language under the same abbreviation. 'en' selects the English corpus regardless of the answer language; 'edsa' is published mostly in English."

changedInput schema / properties / source_type / anyOf

Previous value: -[
-  {
-    "description": "Known legal document source types.\n\nUses StrEnum so values compare equal to plain strings\n(e.g. ``SourceType.GII == \"gii\"``), which keeps Qdrant\npayloads and PostgreSQL columns compatible without conversion.",
-    "enum": [
-      "gii",
-      "eurlex",
-      "eurlex_caselaw",
-      "rechtsprechung",
-      "sachsen_rechtsprechung",
-      "sachsen_gesetze",
-      "bayern_gesetze",
-      "nrw_gesetze",
-      "nrw_rechtsprechung",
-      "gesetzesmaterialien",
-      "edsa",
-      "bverfge",
-      "bverwg",
-      "verwaltungsvorschriften",
-      "dsk"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "bayern_gesetze",
+      "bverfge",
+      "bverwg",
+      "dsk",
+      "edsa",
+      "eurlex",
+      "eurlex_caselaw",
+      "gesetzesmaterialien",
+      "gii",
+      "nrw_gesetze",
+      "nrw_rechtsprechung",
+      "rechtsprechung",
+      "sachsen_rechtsprechung",
+      "verwaltungsvorschriften"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / source_type / description

Previous value: -"'gii', 'eurlex', 'eurlex_caselaw', 'rechtsprechung', 'bverfge', 'bverwg', 'sachsen_rechtsprechung', 'nrw_rechtsprechung', 'bayern_gesetze', 'nrw_gesetze', 'verwaltungsvorschriften', 'edsa', 'dsk' or 'gesetzesmaterialien'. Leave empty to auto-detect; where an abbreviation names a law in two sources, the answer lists them so you can retry. Note: 'edsa' is published mostly in English: language='en' covers the full set, the DE default only the translated documents."New value: +"'gii', 'eurlex', 'eurlex_caselaw', 'rechtsprechung', 'bverfge', 'bverwg', 'sachsen_rechtsprechung', 'nrw_rechtsprechung', 'bayern_gesetze', 'nrw_gesetze', 'verwaltungsvorschriften', 'edsa', 'dsk' or 'gesetzesmaterialien'. Empty = auto-detect; where an abbreviation names a law in two sources, the answer lists both. Note: 'edsa' is published mostly in English: language='en' covers the full set, the DE default only the translated documents."

Changedlegal_list_laws6 fields changed

changedInput schema / properties / document_kind / anyOf

Previous value: -[
-  {
-    "description": "Legal document type classification.\n\nUses StrEnum so values compare equal to plain strings for\nseamless PostgreSQL/Qdrant compatibility.",
-    "enum": [
-      "statute",
-      "regulation",
-      "directive",
-      "decision",
-      "explanatory_memorandum",
-      "guidance"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "description": "Document class: legislation, court decisions, legislative materials or guidance.",
+    "enum": [
+      "statute",
+      "regulation",
+      "directive",
+      "decision",
+      "explanatory_memorandum",
+      "guidance"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / jurisdiction / anyOf

Previous value: -[
-  {
-    "description": "Legal jurisdiction identifiers.\n\nUses StrEnum so values compare equal to plain strings for\nseamless PostgreSQL/Qdrant compatibility.",
-    "enum": [
-      "de",
-      "eu",
-      "de_by",
-      "de_sn",
-      "de_nw"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "description": "Jurisdiction of the legal document.",
+    "enum": [
+      "de",
+      "eu",
+      "de_by",
+      "de_sn",
+      "de_nw"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / jurisdiction / description

Previous value: -"Filter by jurisdiction: 'de' (all German law — matches federal AND state law; for federal only use source_type='gii'), 'eu', 'de_by' (Bavaria only), 'de_nw' (North Rhine-Westphalia only), 'de_sn' (Saxony only). Leave empty for all jurisdictions."New value: +"Filter by jurisdiction: 'de' (all German law — matches federal AND state law; federal only is source_type='gii'), 'eu', 'de_by' (Bavaria only), 'de_nw' (North Rhine-Westphalia only), 'de_sn' (Saxony only). Empty = no jurisdiction filter."

changedInput schema / properties / language / anyOf

Previous value: -[
-  {
-    "description": "Content language of legal documents.\n\nUses StrEnum so values compare equal to plain strings for\nseamless PostgreSQL/Qdrant compatibility.",
-    "enum": [
-      "de",
-      "en"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "description": "Document language, independent of the language of the answer.",
+    "enum": [
+      "de",
+      "en"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / language / description

Previous value: -"Corpus language: 'de' (default — the full German + EU corpus) or 'en' (English-language corpus: currently EDPB/EDSA data-protection guidance only; much smaller than 'de'). DE and EN are separate corpora — a document published in both languages has one entry per language under the same abbreviation. 'en' selects the English corpus regardless of the answer language; 'edsa' is published mostly in English."New value: +"Document language: 'de' (default, German-language documents from German and EU sources) or 'en' (currently EDPB/EDSA data-protection guidance only). DE and EN are separate corpora — a document published in both languages has one entry per language under the same abbreviation. 'en' selects the English corpus regardless of the answer language; 'edsa' is published mostly in English."

changedInput schema / properties / source_type / anyOf

Previous value: -[
-  {
-    "description": "Known legal document source types.\n\nUses StrEnum so values compare equal to plain strings\n(e.g. ``SourceType.GII == \"gii\"``), which keeps Qdrant\npayloads and PostgreSQL columns compatible without conversion.",
-    "enum": [
-      "gii",
-      "eurlex",
-      "eurlex_caselaw",
-      "rechtsprechung",
-      "sachsen_rechtsprechung",
-      "sachsen_gesetze",
-      "bayern_gesetze",
-      "nrw_gesetze",
-      "nrw_rechtsprechung",
-      "gesetzesmaterialien",
-      "edsa",
-      "bverfge",
-      "bverwg",
-      "verwaltungsvorschriften",
-      "dsk"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "bayern_gesetze",
+      "bverfge",
+      "bverwg",
+      "dsk",
+      "edsa",
+      "eurlex",
+      "eurlex_caselaw",
+      "gesetzesmaterialien",
+      "gii",
+      "nrw_gesetze",
+      "nrw_rechtsprechung",
+      "rechtsprechung",
+      "sachsen_rechtsprechung",
+      "verwaltungsvorschriften"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

Changedlegal_lookup2 fields changed

changedInput schema / properties / language / anyOf

Previous value: -[
-  {
-    "description": "Content language of legal documents.\n\nUses StrEnum so values compare equal to plain strings for\nseamless PostgreSQL/Qdrant compatibility.",
-    "enum": [
-      "de",
-      "en"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "description": "Document language, independent of the language of the answer.",
+    "enum": [
+      "de",
+      "en"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / language / description

Previous value: -"Corpus language: 'de' (default — the full German + EU corpus) or 'en' (English-language corpus: currently EDPB/EDSA data-protection guidance only; much smaller than 'de'). DE and EN are separate corpora — a document published in both languages has one entry per language under the same abbreviation. 'en' selects the English corpus regardless of the answer language; 'edsa' is published mostly in English."New value: +"Document language: 'de' (default, German-language documents from German and EU sources) or 'en' (currently EDPB/EDSA data-protection guidance only). DE and EN are separate corpora — a document published in both languages has one entry per language under the same abbreviation. 'en' selects the English corpus regardless of the answer language; 'edsa' is published mostly in English."

Changedlegal_lookup_batch2 fields changed

changedInput schema / properties / language / anyOf

Previous value: -[
-  {
-    "description": "Content language of legal documents.\n\nUses StrEnum so values compare equal to plain strings for\nseamless PostgreSQL/Qdrant compatibility.",
-    "enum": [
-      "de",
-      "en"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "description": "Document language, independent of the language of the answer.",
+    "enum": [
+      "de",
+      "en"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / language / description

Previous value: -"Corpus language: 'de' (default — the full German + EU corpus) or 'en' (English-language corpus: currently EDPB/EDSA data-protection guidance only; much smaller than 'de'). DE and EN are separate corpora — a document published in both languages has one entry per language under the same abbreviation. 'en' selects the English corpus regardless of the answer language; 'edsa' is published mostly in English."New value: +"Document language: 'de' (default, German-language documents from German and EU sources) or 'en' (currently EDPB/EDSA data-protection guidance only). DE and EN are separate corpora — a document published in both languages has one entry per language under the same abbreviation. 'en' selects the English corpus regardless of the answer language; 'edsa' is published mostly in English."

Changedlegal_search14 fields changed

changedInput schema / properties / chapter / description

Previous value: -"Filter by chapter/section within a law. Rarely needed — can reduce recall. Only useful with law_abbreviation."New value: +"Narrows to one chapter/section within a law; reduces recall. Only meaningful together with law_abbreviation."

changedInput schema / properties / cited_norm / description

Previous value: -"Restrict results to court decisions that verifiably cite this provision (citation-graph filter, e.g. '§ 573 BGB' or 'Art. 6 DSGVO'). Combine with a case-specific query — e.g. query='Eigenbedarfskündigung Härtefall hohes Alter', cited_norm='§ 573 BGB' — to get decisions that both apply the provision AND match the facts of the case. It yields the case law for a specific provision and question; legal_find_citing_decisions yields the unranked inventory, newest first. Matching is paragraph-level (Abs./Satz/Nr. are ignored). Only court decisions carry citations, so this filter implicitly restricts to case law — no document_kind needed. For an EU directive both the directive article ('Art. 9 Richtlinie 2011/83/EU') and the national transposition norm ('§ 355 BGB') are valid filters: the directive article matches EU case law (EuGH/EuG) and German decisions citing it directly (richtlinienkonforme Auslegung), while the transposition norm matches the larger body of German decisions applying the transposed rule. The transposition norm covers everyday German case law, the directive article EU-level interpretation; a plain legal_search on the topic reveals the transposition norm when it is unknown. EU regulations (DSGVO, MDR) are cited directly."New value: +"Restrict results to court decisions that verifiably cite this provision (citation-graph filter, e.g. '§ 573 BGB' or 'Art. 6 DSGVO'). With a case-specific query — e.g. query='Eigenbedarfskündigung Härtefall hohes Alter', cited_norm='§ 573 BGB' — citing candidates are ranked by relevance to the query. A citation does not establish applicability to the facts. legal_find_citing_decisions yields the unranked inventory, newest first. Matching is paragraph-level (Abs./Satz/Nr. are ignored). Only court decisions carry citations, so this filter implicitly restricts to case law — no document_kind needed. For an EU directive both the directive article ('Art. 9 Richtlinie 2011/83/EU') and the national transposition norm ('§ 355 BGB') are valid filters: the directive article matches EU case law (EuGH/EuG) and German decisions citing it directly (richtlinienkonforme Auslegung), while the transposition norm matches the larger body of German decisions applying the transposed rule. The transposition norm covers everyday German case law, the directive article EU-level interpretation. EU regulations (DSGVO, MDR) are cited directly."

changedInput schema / properties / court / anyOf

Previous value: -[
-  {
-    "description": "Courts available as search filter.\n\nValues match the ``extra.gericht`` Qdrant payload field used by\nboth Rechtsprechung-im-Internet (German federal courts) and\nEUR-Lex case law (EU courts).",
-    "enum": [
-      "BGH",
-      "BVerfG",
-      "BVerwG",
-      "BFH",
-      "BAG",
-      "BSG",
-      "BPatG",
-      "GmSOGB",
-      "Sächsisches OVG",
-      "Oberverwaltungsgericht NRW",
-      "Oberlandesgericht Düsseldorf",
-      "Oberlandesgericht Hamm",
-      "Oberlandesgericht Köln",
-      "Landesarbeitsgericht Düsseldorf",
-      "Landesarbeitsgericht Hamm",
-      "Landesarbeitsgericht Köln",
-      "Landessozialgericht NRW",
-      "Finanzgericht Düsseldorf",
-      "Finanzgericht Köln",
-      "Finanzgericht Münster",
-      "Verfassungsgerichtshof NRW",
-      "EuGH",
-      "EuG"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "description": "German federal and state courts and EU courts available as search filters.",
+    "enum": [
+      "BGH",
+      "BVerfG",
+      "BVerwG",
+      "BFH",
+      "BAG",
+      "BSG",
+      "BPatG",
+      "GmSOGB",
+      "Sächsisches OVG",
+      "Oberverwaltungsgericht NRW",
+      "Oberlandesgericht Düsseldorf",
+      "Oberlandesgericht Hamm",
+      "Oberlandesgericht Köln",
+      "Landesarbeitsgericht Düsseldorf",
+      "Landesarbeitsgericht Hamm",
+      "Landesarbeitsgericht Köln",
+      "Landessozialgericht NRW",
+      "Finanzgericht Düsseldorf",
+      "Finanzgericht Köln",
+      "Finanzgericht Münster",
+      "Verfassungsgerichtshof NRW",
+      "EuGH",
+      "EuG"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / decision_type / anyOf

Previous value: -[
-  {
-    "description": "Decision types available as search filter.\n\nValues match the ``doktyp`` field in Rechtsprechung-im-Internet XML\nand the Qdrant payload ``decision_type`` field.\n\nNote: ``Gerichtsbescheid`` exists in the XML but is intentionally\nexcluded from the filter enum — it is rare and not useful as a\nuser-facing filter.  The parser handles it internally.",
-    "enum": [
-      "Urteil",
-      "Beschluss"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "description": "Type of court decision: judgment (Urteil) or order (Beschluss).",
+    "enum": [
+      "Urteil",
+      "Beschluss"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / document_kind / anyOf

Previous value: -[
-  {
-    "description": "Legal document type classification.\n\nUses StrEnum so values compare equal to plain strings for\nseamless PostgreSQL/Qdrant compatibility.",
-    "enum": [
-      "statute",
-      "regulation",
-      "directive",
-      "decision",
-      "explanatory_memorandum",
-      "guidance"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "description": "Document class: legislation, court decisions, legislative materials or guidance.",
+    "enum": [
+      "statute",
+      "regulation",
+      "directive",
+      "decision",
+      "explanatory_memorandum",
+      "guidance"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / document_kind / description

Previous value: -"Filter by document class: the three norm subtypes 'statute', 'regulation' and 'directive' form ONE filter class — any of them admits all three, so you cannot (and need not) tell them apart, and an EU regulation or directive is never hidden by a reflexive 'statute'. Three values discriminate: 'decision' restricts to court case-law (how a norm is applied), 'guidance' restricts to supervisory-authority soft law (EDPB/EDSA and Datenschutzkonferenz — authoritative readings of the GDPR/BDSG, not enacted norms and not binding), and 'explanatory_memorandum' restricts to legislative materials (Gesetzesbegründung / BT-Drucksachen — the legislator's intent behind a norm; ratio legis, purpose of an amendment). Materials are opt-in: reachable via this value, source_type='gesetzesmaterialien', or legal_get_materials for one provision, not in an unfiltered search. Leave empty for mixed questions. legal://filter_values documents the per-value definitions and disambiguation."New value: +"Filter by document class: the three norm subtypes 'statute', 'regulation' and 'directive' form ONE filter class — any of them admits all three, so they need not be told apart, and an EU regulation or directive is never hidden by a reflexive 'statute'. Three values discriminate: 'decision' restricts to court case-law (how a norm is applied), 'guidance' restricts to supervisory-authority soft law (EDPB/EDSA and Datenschutzkonferenz — authoritative readings of the GDPR/BDSG, not enacted norms and not binding), and 'explanatory_memorandum' restricts to legislative materials (Gesetzesbegründung / BT-Drucksachen — the legislator's intent behind a norm; ratio legis, purpose of an amendment). Materials are opt-in: reachable via this value, source_type='gesetzesmaterialien', or legal_get_materials for one provision, not in an unfiltered search. Empty = no document-class filter: norms, case law and guidance can rank together, subject to other filters. legal://filter_values documents the per-value definitions and disambiguation."

changedInput schema / properties / jurisdiction / anyOf

Previous value: -[
-  {
-    "description": "Legal jurisdiction identifiers.\n\nUses StrEnum so values compare equal to plain strings for\nseamless PostgreSQL/Qdrant compatibility.",
-    "enum": [
-      "de",
-      "eu",
-      "de_by",
-      "de_sn",
-      "de_nw"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "description": "Jurisdiction of the legal document.",
+    "enum": [
+      "de",
+      "eu",
+      "de_by",
+      "de_sn",
+      "de_nw"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / jurisdiction / description

Previous value: -"Filter by jurisdiction: 'de' (all German law — matches federal AND state law, incl. Staatsverträge like the Medienstaatsvertrag), 'eu' (EU), 'de_by' (Bavaria only), 'de_nw' (North Rhine-Westphalia only), 'de_sn' (Saxony only — Saxon state law is not in the corpus, so this matches Saxon court decisions). 'de' includes state law; source_type='gii' restricts to federal statutes. Leave empty for cross-jurisdiction search."New value: +"Filter by jurisdiction: 'de' (all German law — matches federal AND state law, incl. Staatsverträge like the Medienstaatsvertrag), 'eu' (EU), 'de_by' (Bavaria only), 'de_nw' (North Rhine-Westphalia only), 'de_sn' (Saxony only — Saxon state law is not in the corpus, so this matches Saxon court decisions). 'de' includes state law; source_type='gii' restricts to federal statutes. Empty = no jurisdiction filter."

changedInput schema / properties / language / anyOf

Previous value: -[
-  {
-    "description": "Content language of legal documents.\n\nUses StrEnum so values compare equal to plain strings for\nseamless PostgreSQL/Qdrant compatibility.",
-    "enum": [
-      "de",
-      "en"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "description": "Document language, independent of the language of the answer.",
+    "enum": [
+      "de",
+      "en"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / language / description

Previous value: -"Corpus language: 'de' (default — the full German + EU corpus) or 'en' (English-language corpus: currently EDPB/EDSA data-protection guidance only; much smaller than 'de'). DE and EN are separate corpora — a document published in both languages has one entry per language under the same abbreviation. 'en' selects the English corpus regardless of the answer language; 'edsa' is published mostly in English."New value: +"Document language: 'de' (default, German-language documents from German and EU sources) or 'en' (currently EDPB/EDSA data-protection guidance only). DE and EN are separate corpora — a document published in both languages has one entry per language under the same abbreviation. 'en' selects the English corpus regardless of the answer language; 'edsa' is published mostly in English."

changedInput schema / properties / law_abbreviation / description

Previous value: -"Filter by law abbreviation, e.g. 'bgb', 'dsgvo'. Leave empty for thematic questions."New value: +"Restrict to the named document, e.g. 'bgb', 'dsgvo'. A statute abbreviation does not select decisions citing that statute; cited_norm selects those decisions. Omitted or null = no law filter."

changedInput schema / properties / query / description

Previous value: -"Search query as a natural sentence using statutory language (not keywords or doctrinal terms)."New value: +"Natural-language question or case facts, e.g. 'Wann verjährt ein Schadensersatzanspruch?'. Terms used in the relevant legal documents help retrieval."

changedInput schema / properties / source_type / anyOf

Previous value: -[
-  {
-    "description": "Known legal document source types.\n\nUses StrEnum so values compare equal to plain strings\n(e.g. ``SourceType.GII == \"gii\"``), which keeps Qdrant\npayloads and PostgreSQL columns compatible without conversion.",
-    "enum": [
-      "gii",
-      "eurlex",
-      "eurlex_caselaw",
-      "rechtsprechung",
-      "sachsen_rechtsprechung",
-      "sachsen_gesetze",
-      "bayern_gesetze",
-      "nrw_gesetze",
-      "nrw_rechtsprechung",
-      "gesetzesmaterialien",
-      "edsa",
-      "bverfge",
-      "bverwg",
-      "verwaltungsvorschriften",
-      "dsk"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "bayern_gesetze",
+      "bverfge",
+      "bverwg",
+      "dsk",
+      "edsa",
+      "eurlex",
+      "eurlex_caselaw",
+      "gesetzesmaterialien",
+      "gii",
+      "nrw_gesetze",
+      "nrw_rechtsprechung",
+      "rechtsprechung",
+      "sachsen_rechtsprechung",
+      "verwaltungsvorschriften"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / source_type / description

Previous value: -"Filter by source: 'gii' (German federal laws like BGB, StGB), 'eurlex' (EU regulations like DSGVO, DSA), 'eurlex_caselaw' (EU court decisions, EuGH/EuG), 'rechtsprechung' (federal court decisions, 2010 onwards), 'bverfge' (BVerfG leading decisions from the official reporter BVerfGE, up to 2009 — the reported slice, not every BVerfG decision of that era), 'bverwg' (BVerwG judgments (Urteile) up to 2009), 'sachsen_rechtsprechung' (Saxon OVG decisions), 'nrw_rechtsprechung' (NRW higher-court decisions: OVG/OLG/LAG/LSG/FG/VerfGH), 'bayern_gesetze' (Bavaria), 'nrw_gesetze' (North Rhine-Westphalia), 'verwaltungsvorschriften' (federal administrative regulations, e.g. TA Luft, BMGVwV), 'edsa' (EDPB/EDSA data-protection guidance — soft law, not enacted norms; mostly English, see the language parameter), 'dsk' (Datenschutzkonferenz guidance: Orientierungshilfen, Kurzpapiere, Beschlüsse — the German supervisory authorities' reading of GDPR/BDSG), 'gesetzesmaterialien' (legislative materials — Gesetzesbegründung from Bundestag Drucksachen, the legislator's intent behind a federal norm; the corpus includes draft bills that never became law. Materials are opt-in: they appear with this value or document_kind='explanatory_memorandum', not in an unfiltered search). Leave empty for cross-source search."New value: +"Filter by source: 'gii' (German federal laws like BGB, StGB), 'eurlex' (EU legislation, including regulations like DSGVO/DSA, directives and treaties), 'eurlex_caselaw' (EU court decisions, EuGH/EuG), 'rechtsprechung' (federal court decisions, 2010 onwards), 'bverfge' (BVerfG leading decisions from the official reporter BVerfGE, up to 2009 — the reported slice, not every BVerfG decision of that era), 'bverwg' (BVerwG judgments (Urteile) up to 2009), 'sachsen_rechtsprechung' (Saxon OVG decisions), 'nrw_rechtsprechung' (NRW higher-court decisions: OVG/OLG/LAG/LSG/FG/VerfGH), 'bayern_gesetze' (Bavaria), 'nrw_gesetze' (North Rhine-Westphalia), 'verwaltungsvorschriften' (federal administrative regulations, e.g. TA Luft, BMGVwV), 'edsa' (EDPB/EDSA data-protection guidance — soft law, not enacted norms; mostly English, see the language parameter), 'dsk' (Datenschutzkonferenz guidance: Orientierungshilfen, Kurzpapiere, Beschlüsse — the German supervisory authorities' reading of GDPR/BDSG), 'gesetzesmaterialien' (legislative materials — Gesetzesbegründung from Bundestag Drucksachen, the legislator's intent behind a federal norm; the corpus includes draft bills that never became law. Materials are opt-in: they appear with this value or document_kind='explanatory_memorandum', not in an unfiltered search). Empty = no source filter."

6 tool updatesSep 8, 2026

Changedlegal_find_citing_decisions1 field changed

changedInput schema / properties / cited_norm / description

Previous value: -"The legal provision, e.g. '§ 823 BGB', 'Art. 6 DSGVO'. For an EU directive both the directive article ('Art. 9 Richtlinie 2011/83/EU') and the national transposition norm ('§ 355 BGB') are valid filters: the directive article matches EU case law (EuGH/EuG) and German decisions citing it directly (richtlinienkonforme Auslegung), while the transposition norm matches the larger body of German decisions applying the transposed rule. Prefer the transposition norm for everyday German case law, the directive article for EU-level interpretation; run a plain legal_search first if you do not know the transposition norm. EU regulations (DSGVO, MDR) are cited directly."New value: +"The legal provision, e.g. '§ 823 BGB', 'Art. 6 DSGVO'. For an EU directive both the directive article ('Art. 9 Richtlinie 2011/83/EU') and the national transposition norm ('§ 355 BGB') are valid filters: the directive article matches EU case law (EuGH/EuG) and German decisions citing it directly (richtlinienkonforme Auslegung), while the transposition norm matches the larger body of German decisions applying the transposed rule. The transposition norm covers everyday German case law, the directive article EU-level interpretation; a plain legal_search on the topic reveals the transposition norm when it is unknown. EU regulations (DSGVO, MDR) are cited directly."

Changedlegal_get_toc2 fields changed

changedInput schema / properties / language / description

Previous value: -"Corpus language: 'de' (default — the full German + EU corpus) or 'en' (English-language corpus: currently EDPB/EDSA data-protection guidance only; much smaller than 'de'). DE and EN are separate corpora — a document published in both languages has one entry per language under the same abbreviation. Set 'en' only when the user explicitly works in English or asks for the English version."New value: +"Corpus language: 'de' (default — the full German + EU corpus) or 'en' (English-language corpus: currently EDPB/EDSA data-protection guidance only; much smaller than 'de'). DE and EN are separate corpora — a document published in both languages has one entry per language under the same abbreviation. 'en' selects the English corpus regardless of the answer language; 'edsa' is published mostly in English."

changedInput schema / properties / source_type / description

Previous value: -"'gii', 'eurlex', 'eurlex_caselaw', 'rechtsprechung', 'bverfge', 'bverwg', 'sachsen_rechtsprechung', 'nrw_rechtsprechung', 'bayern_gesetze', 'nrw_gesetze', 'verwaltungsvorschriften', 'edsa', 'dsk' or 'gesetzesmaterialien'. Leave empty to auto-detect; where an abbreviation names a law in two sources, the answer lists them so you can retry. Note: 'edsa' is published mostly in English — pair it with language='en', or the DE default leaves you only the few translated documents."New value: +"'gii', 'eurlex', 'eurlex_caselaw', 'rechtsprechung', 'bverfge', 'bverwg', 'sachsen_rechtsprechung', 'nrw_rechtsprechung', 'bayern_gesetze', 'nrw_gesetze', 'verwaltungsvorschriften', 'edsa', 'dsk' or 'gesetzesmaterialien'. Leave empty to auto-detect; where an abbreviation names a law in two sources, the answer lists them so you can retry. Note: 'edsa' is published mostly in English: language='en' covers the full set, the DE default only the translated documents."

Changedlegal_list_laws2 fields changed

changedInput schema / properties / language / description

Previous value: -"Corpus language: 'de' (default — the full German + EU corpus) or 'en' (English-language corpus: currently EDPB/EDSA data-protection guidance only; much smaller than 'de'). DE and EN are separate corpora — a document published in both languages has one entry per language under the same abbreviation. Set 'en' only when the user explicitly works in English or asks for the English version."New value: +"Corpus language: 'de' (default — the full German + EU corpus) or 'en' (English-language corpus: currently EDPB/EDSA data-protection guidance only; much smaller than 'de'). DE and EN are separate corpora — a document published in both languages has one entry per language under the same abbreviation. 'en' selects the English corpus regardless of the answer language; 'edsa' is published mostly in English."

changedInput schema / properties / source_type / description

Previous value: -"Filter: 'gii', 'eurlex', 'eurlex_caselaw', 'rechtsprechung', 'bverfge', 'bverwg', 'sachsen_rechtsprechung', 'nrw_rechtsprechung', 'bayern_gesetze', 'nrw_gesetze', 'verwaltungsvorschriften', 'edsa', 'dsk' or 'gesetzesmaterialien'. Note: 'edsa' is published mostly in English — pair it with language='en', or the DE default leaves you only the few translated documents."New value: +"Filter: 'gii', 'eurlex', 'eurlex_caselaw', 'rechtsprechung', 'bverfge', 'bverwg', 'sachsen_rechtsprechung', 'nrw_rechtsprechung', 'bayern_gesetze', 'nrw_gesetze', 'verwaltungsvorschriften', 'edsa', 'dsk' or 'gesetzesmaterialien'. Note: 'edsa' is published mostly in English: language='en' covers the full set, the DE default only the translated documents."

Changedlegal_lookup1 field changed

changedInput schema / properties / language / description

Previous value: -"Corpus language: 'de' (default — the full German + EU corpus) or 'en' (English-language corpus: currently EDPB/EDSA data-protection guidance only; much smaller than 'de'). DE and EN are separate corpora — a document published in both languages has one entry per language under the same abbreviation. Set 'en' only when the user explicitly works in English or asks for the English version."New value: +"Corpus language: 'de' (default — the full German + EU corpus) or 'en' (English-language corpus: currently EDPB/EDSA data-protection guidance only; much smaller than 'de'). DE and EN are separate corpora — a document published in both languages has one entry per language under the same abbreviation. 'en' selects the English corpus regardless of the answer language; 'edsa' is published mostly in English."

Changedlegal_lookup_batch1 field changed

changedInput schema / properties / language / description

Previous value: -"Corpus language: 'de' (default — the full German + EU corpus) or 'en' (English-language corpus: currently EDPB/EDSA data-protection guidance only; much smaller than 'de'). DE and EN are separate corpora — a document published in both languages has one entry per language under the same abbreviation. Set 'en' only when the user explicitly works in English or asks for the English version."New value: +"Corpus language: 'de' (default — the full German + EU corpus) or 'en' (English-language corpus: currently EDPB/EDSA data-protection guidance only; much smaller than 'de'). DE and EN are separate corpora — a document published in both languages has one entry per language under the same abbreviation. 'en' selects the English corpus regardless of the answer language; 'edsa' is published mostly in English."

Changedlegal_search5 fields changed

changedInput schema / properties / cited_norm / description

Previous value: -"Restrict results to court decisions that verifiably cite this provision (citation-graph filter, e.g. '§ 573 BGB' or 'Art. 6 DSGVO'). Combine with a case-specific query — e.g. query='Eigenbedarfskündigung Härtefall hohes Alter', cited_norm='§ 573 BGB' — to get decisions that both apply the provision AND match the facts of the case. This is the preferred way to find case law for a specific provision and a specific question. Matching is paragraph-level (Abs./Satz/Nr. are ignored). Only court decisions carry citations, so this filter implicitly restricts to case law — no document_kind needed. For the raw citation inventory of a provision (newest first), use legal_find_citing_decisions instead. For an EU directive both the directive article ('Art. 9 Richtlinie 2011/83/EU') and the national transposition norm ('§ 355 BGB') are valid filters: the directive article matches EU case law (EuGH/EuG) and German decisions citing it directly (richtlinienkonforme Auslegung), while the transposition norm matches the larger body of German decisions applying the transposed rule. Prefer the transposition norm for everyday German case law, the directive article for EU-level interpretation; run a plain legal_search first if you do not know the transposition norm. EU regulations (DSGVO, MDR) are cited directly."New value: +"Restrict results to court decisions that verifiably cite this provision (citation-graph filter, e.g. '§ 573 BGB' or 'Art. 6 DSGVO'). Combine with a case-specific query — e.g. query='Eigenbedarfskündigung Härtefall hohes Alter', cited_norm='§ 573 BGB' — to get decisions that both apply the provision AND match the facts of the case. It yields the case law for a specific provision and question; legal_find_citing_decisions yields the unranked inventory, newest first. Matching is paragraph-level (Abs./Satz/Nr. are ignored). Only court decisions carry citations, so this filter implicitly restricts to case law — no document_kind needed. For an EU directive both the directive article ('Art. 9 Richtlinie 2011/83/EU') and the national transposition norm ('§ 355 BGB') are valid filters: the directive article matches EU case law (EuGH/EuG) and German decisions citing it directly (richtlinienkonforme Auslegung), while the transposition norm matches the larger body of German decisions applying the transposed rule. The transposition norm covers everyday German case law, the directive article EU-level interpretation; a plain legal_search on the topic reveals the transposition norm when it is unknown. EU regulations (DSGVO, MDR) are cited directly."

changedInput schema / properties / document_kind / description

Previous value: -"Filter by document class: the three norm subtypes 'statute', 'regulation' and 'directive' form ONE filter class — any of them admits all three, so you cannot (and need not) tell them apart, and an EU regulation or directive is never hidden by a reflexive 'statute'. Three values discriminate: 'decision' restricts to court case-law (prefer it for how-a-norm-is-applied questions), 'guidance' restricts to supervisory-authority soft law (EDPB/EDSA and Datenschutzkonferenz — authoritative readings of the GDPR/BDSG, not enacted norms and not binding), and 'explanatory_memorandum' restricts to legislative materials (Gesetzesbegründung / BT-Drucksachen — the legislator's intent behind a norm; prefer it for ratio-legis or purpose-of-an-amendment questions). Materials are opt-in: an unfiltered search never returns them — set this value (or source_type='gesetzesmaterialien') to search them, or use legal_get_materials for a specific provision. Leave empty for mixed questions. See legal://filter_values for the per-value definitions and disambiguation."New value: +"Filter by document class: the three norm subtypes 'statute', 'regulation' and 'directive' form ONE filter class — any of them admits all three, so you cannot (and need not) tell them apart, and an EU regulation or directive is never hidden by a reflexive 'statute'. Three values discriminate: 'decision' restricts to court case-law (how a norm is applied), 'guidance' restricts to supervisory-authority soft law (EDPB/EDSA and Datenschutzkonferenz — authoritative readings of the GDPR/BDSG, not enacted norms and not binding), and 'explanatory_memorandum' restricts to legislative materials (Gesetzesbegründung / BT-Drucksachen — the legislator's intent behind a norm; ratio legis, purpose of an amendment). Materials are opt-in: reachable via this value, source_type='gesetzesmaterialien', or legal_get_materials for one provision, not in an unfiltered search. Leave empty for mixed questions. legal://filter_values documents the per-value definitions and disambiguation."

changedInput schema / properties / jurisdiction / description

Previous value: -"Filter by jurisdiction: 'de' (all German law — matches federal AND state law, incl. Staatsverträge like the Medienstaatsvertrag), 'eu' (EU), 'de_by' (Bavaria only), 'de_nw' (North Rhine-Westphalia only), 'de_sn' (Saxony only). For federal statutes ONLY, use source_type='gii' instead. Leave empty for cross-jurisdiction search."New value: +"Filter by jurisdiction: 'de' (all German law — matches federal AND state law, incl. Staatsverträge like the Medienstaatsvertrag), 'eu' (EU), 'de_by' (Bavaria only), 'de_nw' (North Rhine-Westphalia only), 'de_sn' (Saxony only — Saxon state law is not in the corpus, so this matches Saxon court decisions). 'de' includes state law; source_type='gii' restricts to federal statutes. Leave empty for cross-jurisdiction search."

changedInput schema / properties / language / description

Previous value: -"Corpus language: 'de' (default — the full German + EU corpus) or 'en' (English-language corpus: currently EDPB/EDSA data-protection guidance only; much smaller than 'de'). DE and EN are separate corpora — a document published in both languages has one entry per language under the same abbreviation. Set 'en' only when the user explicitly works in English or asks for the English version."New value: +"Corpus language: 'de' (default — the full German + EU corpus) or 'en' (English-language corpus: currently EDPB/EDSA data-protection guidance only; much smaller than 'de'). DE and EN are separate corpora — a document published in both languages has one entry per language under the same abbreviation. 'en' selects the English corpus regardless of the answer language; 'edsa' is published mostly in English."

changedInput schema / properties / source_type / description

Previous value: -"Filter by source: 'gii' (German federal laws like BGB, StGB), 'eurlex' (EU regulations like DSGVO, DSA), 'eurlex_caselaw' (EU court decisions, EuGH/EuG), 'rechtsprechung' (federal court decisions, 2010 onwards), 'bverfge' (BVerfG leading decisions from the official reporter BVerfGE, up to 2009 — the reported slice, not every BVerfG decision of that era), 'bverwg' (BVerwG judgments (Urteile) up to 2009), 'sachsen_rechtsprechung' (Saxon OVG decisions), 'nrw_rechtsprechung' (NRW higher-court decisions: OVG/OLG/LAG/LSG/FG/VerfGH), 'bayern_gesetze' (Bavaria), 'nrw_gesetze' (North Rhine-Westphalia), 'verwaltungsvorschriften' (federal administrative regulations, e.g. TA Luft, BMGVwV), 'edsa' (EDPB/EDSA data-protection guidance — soft law, not enacted norms; mostly English, see the language parameter), 'dsk' (Datenschutzkonferenz guidance: Orientierungshilfen, Kurzpapiere, Beschlüsse — the German supervisory authorities' reading of GDPR/BDSG), 'gesetzesmaterialien' (legislative materials — Gesetzesbegründung from Bundestag Drucksachen, the legislator's intent behind a federal norm; the corpus includes draft bills that never became law. Materials appear ONLY when explicitly requested via this value or document_kind='explanatory_memorandum' — an unfiltered search never returns them). Leave empty for cross-source search."New value: +"Filter by source: 'gii' (German federal laws like BGB, StGB), 'eurlex' (EU regulations like DSGVO, DSA), 'eurlex_caselaw' (EU court decisions, EuGH/EuG), 'rechtsprechung' (federal court decisions, 2010 onwards), 'bverfge' (BVerfG leading decisions from the official reporter BVerfGE, up to 2009 — the reported slice, not every BVerfG decision of that era), 'bverwg' (BVerwG judgments (Urteile) up to 2009), 'sachsen_rechtsprechung' (Saxon OVG decisions), 'nrw_rechtsprechung' (NRW higher-court decisions: OVG/OLG/LAG/LSG/FG/VerfGH), 'bayern_gesetze' (Bavaria), 'nrw_gesetze' (North Rhine-Westphalia), 'verwaltungsvorschriften' (federal administrative regulations, e.g. TA Luft, BMGVwV), 'edsa' (EDPB/EDSA data-protection guidance — soft law, not enacted norms; mostly English, see the language parameter), 'dsk' (Datenschutzkonferenz guidance: Orientierungshilfen, Kurzpapiere, Beschlüsse — the German supervisory authorities' reading of GDPR/BDSG), 'gesetzesmaterialien' (legislative materials — Gesetzesbegründung from Bundestag Drucksachen, the legislator's intent behind a federal norm; the corpus includes draft bills that never became law. Materials are opt-in: they appear with this value or document_kind='explanatory_memorandum', not in an unfiltered search). Leave empty for cross-source search."

11 tool updatesSep 8, 2026
- First observedlegal_find_citing_decisions
- First observedlegal_get_context
- First observedlegal_get_materials
- First observedlegal_get_stats
- First observedlegal_get_toc
- First observedlegal_list_laws
- First observedlegal_lookup
- First observedlegal_lookup_batch
- First observedlegal_search
- First observedlist_resources
- First observedread_resource

Related MCP Connectors

LawbsterOAuth
io.github.PLANIT-TECH
Verified, citable German & EU law for any LLM. Daily updates from official sources, hosted in DE.
Legal & Compliance Documentation Access
211
Obsidian Regulatory MCPOAuth
io.github.richbile
Verified, tier-0 regulatory data for AI across 850+ official sources and 50+ jurisdictions.
Legal & Compliance Government Data Open Data
2
Handelsregister A
io.github.jkbngb
German Handelsregister + Austrian Firmenbuch for AI agents: master data, financials & ratios.
Government Data Finance Open Data
121
TalarionOAuth
com.talarion
A knowledge base of verified, dated facts your LLM would otherwise get wrong.
Search Knowledge & Memory
2

Related MCP Servers

legal-text-mcp-de
Legal & Compliance Government Data
klein-business
A
license
Not graded
quality
D
maintenance
Cite-grade German legal-text infrastructure for LLM agents, providing access to federal, Länder, and EU laws with cryptographic provenance.
Updated 3 months ago (2026-07-16 20:42 UTC)
44 PyPI
2
Apache 2.0
German Law MCP Server
Legal & Compliance Government Data Research & Data
Ansvar-Systems
A
license
Not graded
quality
F
maintenance
Enables querying over 6,800 German federal statutes, case law, and legislative preparatory works with verbatim source text. Integrates EU law cross-references and provides citation validation and legal stance building.
Updated 3 months ago (2026-07-07 03:54 UTC)
76 npm
22
Apache 2.0
Legal MCP
Legal & Compliance Search RAG Systems
ayunis-core
A
license
Not graded
quality
C
maintenance
Enables AI assistants to search and analyze German legal texts using vector embeddings and semantic search.
Updated 2 months ago (2026-08-05 20:10 UTC)
90
MIT
kvasir-legalofficial
Legal & Compliance Government Data
kvasir-legal
F
license
Not graded
quality
C
maintenance
Verifiable German, Austrian, Swiss and EU law: resolve citations to the wording in force, verify the citations a model produced against the official source, and walk the citation graph.
Updated a month ago (2026-08-19 18:08 UTC)
-

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.

Server Details

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

kvasir-legalofficial

Glama MCP Gateway

Resources