PRIMAMCP
Server Details
Search German and EU law from official sources with your AI assistant. PRIMAMCP provides citable legal texts via MCP, with daily updates and hosting in Germany.
- Status
- Healthy
- Uptime
- 95.9% over 39 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
Scored across 11 tools
Most legal tools carve out distinct workflows: known-citation lookup, batch lookup, topic search, citing-decisions discovery, context retrieval, TOC, and legislative materials. The main overlap is between legal_lookup and legal_lookup_batch and between legal_find_citing_decisions and legal_search with a cited_norm filter, but the descriptions explicitly cross-reference and differentiate when each should be used. list_resources and read_resource are generic but not confusable with the legal tools.
The legal tools consistently use a legal_<verb>_<object> pattern such as legal_lookup, legal_search, legal_get_toc, and legal_list_laws. Legal_find_citing_decisions is a slightly longer phrase rather than a simple verb_noun, and list_resources/read_resource follow a different generic MCP convention. Overall the naming is predictable and readable.
Eleven tools is well within the appropriate range for a legal research server, and each legal tool contributes a distinct retrieval or analysis function. There is no obvious filler or redundant duplication, while the generic resource tools add standard MCP coverage without bloating the set.
The toolset covers the full legal research workflow: discovering laws, resolving known citations individually or in batches, searching by topic, finding decisions citing a provision, navigating context and TOCs, and retrieving legislative intent. It also supports citation-graph exploration through returned norm_ids and cited_norms, so there are no critical dead ends.
Available Tools
11 toolslegal_find_citing_decisionsFind Citing Court DecisionsARead-onlyIdempotentInspect
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.
| 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
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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 ProvisionsARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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)ARead-onlyIdempotentInspect
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.
| 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
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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 StatisticsARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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 ContentsARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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 LawsARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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 CitationARead-onlyIdempotentInspect
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.
| 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
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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 ProvisionsARead-onlyIdempotentInspect
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.
| 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
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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 DocumentsARead-onlyIdempotentInspect
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
| Name | Required | Description | Default |
|---|---|---|---|
| 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
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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_resourcesARead-onlyInspect
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}.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates the tool is non-destructive. The description adds valuable context beyond this by explaining the output structure (JSON with resource metadata) and the key distinction between static 'uri' fields and templates with 'uri_template' placeholders. This extra detail about the return format and resource types exceeds what the annotation provides, though the read-only behavior itself is not elaborated further.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, consisting of two short sentences. It front-loads the primary action and object ('List all available resources and resource templates') and then provides necessary detail on return format and resource types without any redundant or vague phrasing. Every sentence adds meaningful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, clear output schema present), the description is sufficiently complete. It explains what the tool returns (JSON metadata) and the critical distinction between static and template resources, which is essential for understanding the tool's behavior. The presence of an output schema means the description does not need to enumerate all return fields, and it covers the key context an agent would need to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (vacuously). There are no parameter semantics to explain, so the description does not need to add any meaning. The description fully aligns with the input schema, and there is no ambiguity or missing parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the target ('all available resources and resource templates'). It distinguishes between static resources and templates, making the purpose unambiguous even without opening the schema. This is a precise, specific statement of what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool over siblings like read_resource or legal_list_laws. It implies that this is for discovery (listing all resources), but it does not provide direct guidance on selection criteria. The information about static vs. template resources is helpful but does not constitute explicit usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_resourceARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| uri | Yes | The URI of the resource to read |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation is consistent with the described read-only behavior. The description adds useful details about return content and base64 encoding, going beyond the annotation without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, with no unnecessary words or repetition. It delivers all essential information in two sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation, the description is complete: it covers input format, output type, and encoding. No further details are needed for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'uri' is described in the schema, but the tool description adds important nuance about static vs. templated URIs, which is not present in the schema. This additional guidance improves parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Read' and the object 'resource by its URI.' It distinguishes from sibling tools such as list_resources (listing) and legal_* tools (specific legal actions) by focusing on reading a single resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on static vs. templated URIs and explains output encoding. Does not explicitly contrast with alternatives, but the purpose is straightforward and the instructions are sufficient for correct invocation.
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 updates
- Changed
legal_find_citing_decisions1 field changed- changed
Input schema / properties / cited_norm / descriptionPrevious 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."
- Changed
legal_get_context3 fields changed- changed
Input schema / properties / after / descriptionPrevious value: -"Number of norms after the target (max 10)."New value: +"Number of stored text sections after the target (max 10)." - changed
Input schema / properties / before / descriptionPrevious value: -"Number of norms before the target (max 10)."New value: +"Number of stored text sections before the target (max 10)." - changed
Input schema / properties / norm_id / descriptionPrevious 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."
- Changed
legal_get_toc4 fields changed- changed
Input schema / properties / language / anyOfPrevious 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" + } +] - changed
Input schema / properties / language / descriptionPrevious 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." - changed
Input schema / properties / source_type / anyOfPrevious 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" + } +] - changed
Input schema / properties / source_type / descriptionPrevious 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."
- Changed
legal_list_laws6 fields changed- changed
Input schema / properties / document_kind / anyOfPrevious 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" + } +] - changed
Input schema / properties / jurisdiction / anyOfPrevious 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" + } +] - changed
Input schema / properties / jurisdiction / descriptionPrevious 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." - changed
Input schema / properties / language / anyOfPrevious 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" + } +] - changed
Input schema / properties / language / descriptionPrevious 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." - changed
Input schema / properties / source_type / anyOfPrevious 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" + } +]
- Changed
legal_lookup2 fields changed- changed
Input schema / properties / language / anyOfPrevious 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" + } +] - changed
Input schema / properties / language / descriptionPrevious 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."
- Changed
legal_lookup_batch2 fields changed- changed
Input schema / properties / language / anyOfPrevious 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" + } +] - changed
Input schema / properties / language / descriptionPrevious 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."
- Changed
legal_search14 fields changed- changed
Input schema / properties / chapter / descriptionPrevious 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." - changed
Input schema / properties / cited_norm / descriptionPrevious 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." - changed
Input schema / properties / court / anyOfPrevious 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" + } +] - changed
Input schema / properties / decision_type / anyOfPrevious 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" + } +] - changed
Input schema / properties / document_kind / anyOfPrevious 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" + } +] - changed
Input schema / properties / document_kind / descriptionPrevious 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." - changed
Input schema / properties / jurisdiction / anyOfPrevious 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" + } +] - changed
Input schema / properties / jurisdiction / descriptionPrevious 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." - changed
Input schema / properties / language / anyOfPrevious 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" + } +] - changed
Input schema / properties / language / descriptionPrevious 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." - changed
Input schema / properties / law_abbreviation / descriptionPrevious 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." - changed
Input schema / properties / query / descriptionPrevious 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." - changed
Input schema / properties / source_type / anyOfPrevious 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" + } +] - changed
Input schema / properties / source_type / descriptionPrevious 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 updates
- Changed
legal_find_citing_decisions1 field changed- changed
Input schema / properties / cited_norm / descriptionPrevious 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."
- Changed
legal_get_toc2 fields changed- changed
Input schema / properties / language / descriptionPrevious 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." - changed
Input schema / properties / source_type / descriptionPrevious 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."
- Changed
legal_list_laws2 fields changed- changed
Input schema / properties / language / descriptionPrevious 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." - changed
Input schema / properties / source_type / descriptionPrevious 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."
- Changed
legal_lookup1 field changed- changed
Input schema / properties / language / descriptionPrevious 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."
- Changed
legal_lookup_batch1 field changed- changed
Input schema / properties / language / descriptionPrevious 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."
- Changed
legal_search5 fields changed- changed
Input schema / properties / cited_norm / descriptionPrevious 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." - changed
Input schema / properties / document_kind / descriptionPrevious 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." - changed
Input schema / properties / jurisdiction / descriptionPrevious 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." - changed
Input schema / properties / language / descriptionPrevious 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." - changed
Input schema / properties / source_type / descriptionPrevious 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."
1 tool update
- Changed
legal_get_toc1 field changed- changed
Input schema / properties / source_type / descriptionPrevious 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. 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 — pair it with language='en', or the DE default leaves you only the few translated documents."
3 tool updates
- Changed
legal_get_toc1 field changed- changed
Input schema / properties / source_type / descriptionPrevious value: -"'gii', 'eurlex', 'eurlex_caselaw', 'rechtsprechung', 'sachsen_rechtsprechung', 'nrw_rechtsprechung', 'bayern_gesetze', 'nrw_gesetze', or 'verwaltungsvorschriften'. Leave empty to auto-detect."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. Note: 'edsa' is published mostly in English — pair it with language='en', or the DE default leaves you only the few translated documents."
- Changed
legal_list_laws3 fields changed- changed
Input schema / properties / document_kind / descriptionPrevious value: -"Filter by document class: the norm subtypes 'statute', 'regulation' and 'directive' form ONE class (any of them lists all three); 'decision' is separate and restricts to court case-law."New value: +"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." - changed
Input schema / properties / jurisdiction / descriptionPrevious 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_sn' (Saxony only). Leave empty for all jurisdictions."New 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." - changed
Input schema / properties / source_type / descriptionPrevious value: -"Filter: 'gii', 'eurlex', 'eurlex_caselaw', 'rechtsprechung', 'sachsen_rechtsprechung', 'nrw_rechtsprechung', 'bayern_gesetze', 'nrw_gesetze', or 'verwaltungsvorschriften'."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 — pair it with language='en', or the DE default leaves you only the few translated documents."
- Changed
legal_search3 fields changed- changed
Input schema / properties / document_kind / descriptionPrevious 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'. Two values discriminate: 'decision' restricts to court case-law (prefer it for how-a-norm-is-applied questions), 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 (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." - changed
Input schema / properties / jurisdiction / descriptionPrevious 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_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). For federal statutes ONLY, use source_type='gii' instead. Leave empty for cross-jurisdiction search." - changed
Input schema / properties / source_type / descriptionPrevious 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), '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), '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 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."
1 tool update
- Changed
legal_list_laws1 field changed- changed
Input schema / properties / search / descriptionPrevious value: -"Case-insensitive search on abbreviation and title, 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."New value: +"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."
2 tool updates
- Changed
legal_find_citing_decisions1 field changed- changed
Input schema / properties / cited_norm / descriptionPrevious value: -"The legal provision, e.g. '§ 823 BGB', 'Art. 6 DSGVO'."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. 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."
- Changed
legal_search1 field changed- changed
Input schema / properties / cited_norm / descriptionPrevious 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."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. 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."
3 tool updates
- Changed
legal_get_toc2 fields changed- changed
Input schema / properties / source_type / anyOfPrevious 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", - "gesetzesmaterialien", - "edsa", - "bverfge", - "bverwg", - "verwaltungsvorschriften", - "dsk" - ], - "type": "string" - }, - { - "type": "null" - } -]New 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" + } +] - changed
Input schema / properties / source_type / descriptionPrevious value: -"'gii', 'eurlex', 'eurlex_caselaw', 'rechtsprechung', 'sachsen_rechtsprechung', 'bayern_gesetze', 'nrw_gesetze', or 'verwaltungsvorschriften'. Leave empty to auto-detect."New value: +"'gii', 'eurlex', 'eurlex_caselaw', 'rechtsprechung', 'sachsen_rechtsprechung', 'nrw_rechtsprechung', 'bayern_gesetze', 'nrw_gesetze', or 'verwaltungsvorschriften'. Leave empty to auto-detect."
- Changed
legal_list_laws2 fields changed- changed
Input schema / properties / source_type / anyOfPrevious 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", - "gesetzesmaterialien", - "edsa", - "bverfge", - "bverwg", - "verwaltungsvorschriften", - "dsk" - ], - "type": "string" - }, - { - "type": "null" - } -]New 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" + } +] - changed
Input schema / properties / source_type / descriptionPrevious value: -"Filter: 'gii', 'eurlex', 'eurlex_caselaw', 'rechtsprechung', 'sachsen_rechtsprechung', 'bayern_gesetze', 'nrw_gesetze', or 'verwaltungsvorschriften'."New value: +"Filter: 'gii', 'eurlex', 'eurlex_caselaw', 'rechtsprechung', 'sachsen_rechtsprechung', 'nrw_rechtsprechung', 'bayern_gesetze', 'nrw_gesetze', or 'verwaltungsvorschriften'."
- Changed
legal_search4 fields changed- changed
Input schema / properties / court / anyOfPrevious 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", - "EuGH", - "EuG" - ], - "type": "string" - }, - { - "type": "null" - } -]New 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" + } +] - changed
Input schema / properties / court / descriptionPrevious value: -"Filter by court: BGH, BVerwG, BFH, BAG, BSG, BVerfG, BPatG, GmSOGB, Sächsisches OVG, EuGH, EuG."New value: +"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." - changed
Input schema / properties / source_type / anyOfPrevious 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", - "gesetzesmaterialien", - "edsa", - "bverfge", - "bverwg", - "verwaltungsvorschriften", - "dsk" - ], - "type": "string" - }, - { - "type": "null" - } -]New 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" + } +] - changed
Input schema / properties / source_type / descriptionPrevious 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), 'sachsen_rechtsprechung' (Saxon OVG decisions), 'bayern_gesetze' (Bavaria), 'nrw_gesetze' (North Rhine-Westphalia), 'verwaltungsvorschriften' (federal administrative regulations, e.g. TA Luft, BMGVwV), '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), '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), '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."
3 tool updates
- Changed
legal_get_toc1 field changed- changed
Input schema / properties / source_type / anyOfPrevious 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", - "gesetzesmaterialien", - "edsa", - "bverfge", - "bverwg", - "verwaltungsvorschriften" - ], - "type": "string" - }, - { - "type": "null" - } -]New 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", + "gesetzesmaterialien", + "edsa", + "bverfge", + "bverwg", + "verwaltungsvorschriften", + "dsk" + ], + "type": "string" + }, + { + "type": "null" + } +]
- Changed
legal_list_laws1 field changed- changed
Input schema / properties / source_type / anyOfPrevious 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", - "gesetzesmaterialien", - "edsa", - "bverfge", - "bverwg", - "verwaltungsvorschriften" - ], - "type": "string" - }, - { - "type": "null" - } -]New 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", + "gesetzesmaterialien", + "edsa", + "bverfge", + "bverwg", + "verwaltungsvorschriften", + "dsk" + ], + "type": "string" + }, + { + "type": "null" + } +]
- Changed
legal_search1 field changed- changed
Input schema / properties / source_type / anyOfPrevious 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", - "gesetzesmaterialien", - "edsa", - "bverfge", - "bverwg", - "verwaltungsvorschriften" - ], - "type": "string" - }, - { - "type": "null" - } -]New 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", + "gesetzesmaterialien", + "edsa", + "bverfge", + "bverwg", + "verwaltungsvorschriften", + "dsk" + ], + "type": "string" + }, + { + "type": "null" + } +]
3 tool updates
- Changed
legal_get_toc2 fields changed- changed
Input schema / properties / source_type / anyOfPrevious 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", - "gesetzesmaterialien", - "edsa", - "bverfge", - "bverwg" - ], - "type": "string" - }, - { - "type": "null" - } -]New 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", + "gesetzesmaterialien", + "edsa", + "bverfge", + "bverwg", + "verwaltungsvorschriften" + ], + "type": "string" + }, + { + "type": "null" + } +] - changed
Input schema / properties / source_type / descriptionPrevious value: -"'gii', 'eurlex', 'eurlex_caselaw', 'rechtsprechung', 'sachsen_rechtsprechung', 'bayern_gesetze', or 'nrw_gesetze'. Leave empty to auto-detect."New value: +"'gii', 'eurlex', 'eurlex_caselaw', 'rechtsprechung', 'sachsen_rechtsprechung', 'bayern_gesetze', 'nrw_gesetze', or 'verwaltungsvorschriften'. Leave empty to auto-detect."
- Changed
legal_list_laws2 fields changed- changed
Input schema / properties / source_type / anyOfPrevious 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", - "gesetzesmaterialien", - "edsa", - "bverfge", - "bverwg" - ], - "type": "string" - }, - { - "type": "null" - } -]New 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", + "gesetzesmaterialien", + "edsa", + "bverfge", + "bverwg", + "verwaltungsvorschriften" + ], + "type": "string" + }, + { + "type": "null" + } +] - changed
Input schema / properties / source_type / descriptionPrevious value: -"Filter: 'gii', 'eurlex', 'eurlex_caselaw', 'rechtsprechung', 'sachsen_rechtsprechung', 'bayern_gesetze', or 'nrw_gesetze'."New value: +"Filter: 'gii', 'eurlex', 'eurlex_caselaw', 'rechtsprechung', 'sachsen_rechtsprechung', 'bayern_gesetze', 'nrw_gesetze', or 'verwaltungsvorschriften'."
- Changed
legal_search2 fields changed- changed
Input schema / properties / source_type / anyOfPrevious 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", - "gesetzesmaterialien", - "edsa", - "bverfge", - "bverwg" - ], - "type": "string" - }, - { - "type": "null" - } -]New 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", + "gesetzesmaterialien", + "edsa", + "bverfge", + "bverwg", + "verwaltungsvorschriften" + ], + "type": "string" + }, + { + "type": "null" + } +] - changed
Input schema / properties / source_type / descriptionPrevious 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), 'sachsen_rechtsprechung' (Saxon OVG decisions), 'bayern_gesetze' (Bavaria), 'nrw_gesetze' (North Rhine-Westphalia), '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), 'sachsen_rechtsprechung' (Saxon OVG decisions), 'bayern_gesetze' (Bavaria), 'nrw_gesetze' (North Rhine-Westphalia), 'verwaltungsvorschriften' (federal administrative regulations, e.g. TA Luft, BMGVwV), '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."
3 tool updates
- Changed
legal_get_toc1 field changed- changed
Input schema / properties / source_type / anyOfPrevious 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", - "gesetzesmaterialien", - "edsa", - "bverfge" - ], - "type": "string" - }, - { - "type": "null" - } -]New 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", + "gesetzesmaterialien", + "edsa", + "bverfge", + "bverwg" + ], + "type": "string" + }, + { + "type": "null" + } +]
- Changed
legal_list_laws1 field changed- changed
Input schema / properties / source_type / anyOfPrevious 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", - "gesetzesmaterialien", - "edsa", - "bverfge" - ], - "type": "string" - }, - { - "type": "null" - } -]New 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", + "gesetzesmaterialien", + "edsa", + "bverfge", + "bverwg" + ], + "type": "string" + }, + { + "type": "null" + } +]
- Changed
legal_search1 field changed- changed
Input schema / properties / source_type / anyOfPrevious 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", - "gesetzesmaterialien", - "edsa", - "bverfge" - ], - "type": "string" - }, - { - "type": "null" - } -]New 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", + "gesetzesmaterialien", + "edsa", + "bverfge", + "bverwg" + ], + "type": "string" + }, + { + "type": "null" + } +]
3 tool updates
- Changed
legal_get_toc1 field changed- changed
Input schema / properties / source_type / anyOfPrevious 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", - "gesetzesmaterialien", - "edsa" - ], - "type": "string" - }, - { - "type": "null" - } -]New 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", + "gesetzesmaterialien", + "edsa", + "bverfge" + ], + "type": "string" + }, + { + "type": "null" + } +]
- Changed
legal_list_laws1 field changed- changed
Input schema / properties / source_type / anyOfPrevious 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", - "gesetzesmaterialien", - "edsa" - ], - "type": "string" - }, - { - "type": "null" - } -]New 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", + "gesetzesmaterialien", + "edsa", + "bverfge" + ], + "type": "string" + }, + { + "type": "null" + } +]
- Changed
legal_search1 field changed- changed
Input schema / properties / source_type / anyOfPrevious 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", - "gesetzesmaterialien", - "edsa" - ], - "type": "string" - }, - { - "type": "null" - } -]New 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", + "gesetzesmaterialien", + "edsa", + "bverfge" + ], + "type": "string" + }, + { + "type": "null" + } +]
5 tool updates
- Changed
legal_get_toc2 fields changed- added
Input schema / properties / languageAdded value: +{ + "anyOf": [ + { + "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" + } + ], + "default": null, + "description": "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." +} - changed
Input schema / properties / source_type / anyOfPrevious 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", - "gesetzesmaterialien" - ], - "type": "string" - }, - { - "type": "null" - } -]New 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", + "gesetzesmaterialien", + "edsa" + ], + "type": "string" + }, + { + "type": "null" + } +]
- Changed
legal_list_laws3 fields changed- changed
Input schema / properties / document_kind / anyOfPrevious 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" - ], - "type": "string" - }, - { - "type": "null" - } -]New 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" + } +] - added
Input schema / properties / languageAdded value: +{ + "anyOf": [ + { + "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" + } + ], + "default": null, + "description": "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." +} - changed
Input schema / properties / source_type / anyOfPrevious 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", - "gesetzesmaterialien" - ], - "type": "string" - }, - { - "type": "null" - } -]New 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", + "gesetzesmaterialien", + "edsa" + ], + "type": "string" + }, + { + "type": "null" + } +]
- Changed
legal_lookup1 field changed- added
Input schema / properties / languageAdded value: +{ + "anyOf": [ + { + "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" + } + ], + "default": null, + "description": "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." +}
- Changed
legal_lookup_batch1 field changed- added
Input schema / properties / languageAdded value: +{ + "anyOf": [ + { + "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" + } + ], + "default": null, + "description": "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." +}
- Changed
legal_search3 fields changed- changed
Input schema / properties / document_kind / anyOfPrevious 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" - ], - "type": "string" - }, - { - "type": "null" - } -]New 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" + } +] - added
Input schema / properties / languageAdded value: +{ + "anyOf": [ + { + "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" + } + ], + "default": null, + "description": "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." +} - changed
Input schema / properties / source_type / anyOfPrevious 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", - "gesetzesmaterialien" - ], - "type": "string" - }, - { - "type": "null" - } -]New 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", + "gesetzesmaterialien", + "edsa" + ], + "type": "string" + }, + { + "type": "null" + } +]
1 tool update
- Changed
legal_search1 field changed- added
Input schema / properties / cited_normAdded value: +{ + "anyOf": [ + { + "maxLength": 200, + "minLength": 1, + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "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." +}
1 tool update
- Changed
legal_list_laws1 field changed- changed
Input schema / properties / search / descriptionPrevious value: -"Case-insensitive search on abbreviation and title, e.g. 'bgb', 'datenschutz'."New value: +"Case-insensitive search on abbreviation and title, 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."
1 tool update
- Changed
legal_lookup1 field changed- changed
Input schema / properties / citation / descriptionPrevious value: -"Full citation string, e.g. '§ 823 BGB'"New value: +"Full citation string, e.g. '§ 823 BGB' or 'VII ZR 184/14'"
1 tool update
- Changed
legal_search2 fields changed- changed
Input schema / properties / document_kind / descriptionPrevious 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'. Two values discriminate: 'decision' restricts to court case-law (prefer it for how-a-norm-is-applied questions), 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). 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'. Two values discriminate: 'decision' restricts to court case-law (prefer it for how-a-norm-is-applied questions), 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." - changed
Input schema / properties / source_type / descriptionPrevious 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), 'sachsen_rechtsprechung' (Saxon OVG decisions), 'bayern_gesetze' (Bavaria), 'nrw_gesetze' (North Rhine-Westphalia), 'gesetzesmaterialien' (legislative materials — Gesetzesbegründung from Bundestag Drucksachen, the legislator's intent behind a federal norm). 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), 'sachsen_rechtsprechung' (Saxon OVG decisions), 'bayern_gesetze' (Bavaria), 'nrw_gesetze' (North Rhine-Westphalia), '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."
Related MCP Connectors
Verified, citable German & EU law for any LLM. Daily updates from official sources, hosted in DE.
Eurlex MCP client: Access EU law & Official Journal. https://www.lexsocket.ai/
Connect AI to millions of laws and court cases with the Lawstronaut MCP.
EUR-Lex MCP — official EU law, article-level.
Related MCP Servers
- FlicenseNot gradedqualityCmaintenanceProvides access to German court decisions and laws via MCP tools, enabling legal document search and retrieval.-
- AlicenseNot gradedqualityCmaintenanceEnables querying 6,870 German federal statutes, case law, and legislative preparatory works directly from AI assistants and MCP-compatible clients.65 npm4Apache 2.0
- AlicenseAqualityCmaintenanceProvides unified access to German federal and state legislation, court decisions, and European Union legal databases for comprehensive legal research. It enables users to search and retrieve full-text laws, parliamentary documents, and judicial rulings directly through the Model Context Protocol.2070 npmGPL 3.0
- AlicenseNot gradedqualityFmaintenanceEnables 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.65 npm22Apache 2.0
Glama MCP Gateway
Add one secure layer between your agents and this server.