This server gives AI agents grounded access to German law: retrieving statutes, searching case law, calculating procedural deadlines, and building subsumption/pleading material.
get_norm(law, section) — Fetches verbatim statutory text (BGB, ZPO, KSchG, StGB, RVG, AufenthG, etc.) from official federal/state sources.
search_precedents(query, limit, court, source) — Searches authentic case law from federal courts (BGH, BAG, BVerfG, BVerwG, BFH) and Bavarian courts; defaults to 5 results, all sources.
get_decision(doc_id) — Returns the full text of a decision including Randnummern.
compute_deadline(ereignis_datum, dauer_wert, dauer_einheit, state) — Computes deadlines under §§ 187–193 BGB/ZPO with weekend and public-holiday shifting for all 16 states (defaults: weeks, BY).
get_subsumption_blueprint(law, section) — Provides structured Tatbestandsmerkmale, factual requirements, burden of proof, and legal consequences.
prepare_pleading_dossier(norms, query) — Assembles a citation-grounded research block for drafting pleadings.
Note: the documented anonymize_text tool is not exposed in the schema, and all tools return a single stringified result.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@german-legal-engine berechne die Widerspruchsfrist ab Zustellung am 03.10.2026 in Bayern"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Souveräne juristische Recherche-, Subsumtions- und Fristen-Engine für autonome KI-Agenten
Souveräne Open-Source-Distribution von Agentiqa
Bestehende Legal-Tech-Suchwerkzeuge und MCP-Wrapper für deutsches Recht (wie z. B. german-legal-mcp) agieren primär als unstrukturierte Text-Scraper: Sie liefern unstrukturierte 40-seitige Urteilsprotokolle zurück, ohne ein Verständnis für juristische Subsumtion, Beweislastverteilung oder prozessuale Fristenberechnung mitzubringen.
Die German Legal Engine (GLE) wurde von praktizierenden Rechtsanwälten und KI-Systemarchitekten von Grund auf konzipiert, um KI-Agenten im deutschen Rechtsraum eine verlässliche Entscheidungs- und Recherchebasis (Ground Truth) bereitzustellen:
Deterministischer Normenabruf (Gesetzeswahrheit): Wortlautgetreuer Abruf von Bundesgesetzen (BGB, ZPO, KSchG, StGB, RVG, HGB, etc.) direkt über gesetze-im-internet.de ohne Halluzinationen.
Strukturierte Subsumtions-Modelle (Tatbestands-Graphen): Zerlegung von Gesetzesnormen in konkrete Tatbestandsmerkmale, Tatsachenanforderungen und gesetzliche Beweislastverteilung (Kläger versus Beklagter).
Mathematische Fristen-Engine (§§ 187–193 BGB & ZPO): Exakte Berechnung zivil- und arbeitsgerichtlicher Fristen (Ereignistag, Fristbeginn, Fristende) inklusive automatischer Verschiebung bei Wochenenden und Feiertagen aller 16 Bundesländer (Feiertagsgesetze).
Authentische Rechtsprechung (RII-Integration): Volltextsuche und zitiersichere Nachweise höchstrichterlicher Entscheidungen (BGH, BAG, BVerfG, BVerwG) mit gezielter Randnummern-Extraktion ([Rn. X]).
Einhaltung anwaltlicher Schriftsatzstandards (Zero-Dashes & Urteilsstil): Automatische Bereinigung störender Gedankenstriche (—, –) in prozessual saubere Zitiersyntax.
Related MCP server: legal-text-mcp-de
german-legal-engine/
├── README.md # Vollständige Dokumentation in deutscher Sprache
├── AGENT_INSTRUCTIONS.md # Technisches Briefing & Entwicklungsleitfaden für KI-Agenten
├── pyproject.toml # Modernes Packaging via Hatchling / pip / uv
├── LICENSE # MIT-Lizenz
├── src/
│ └── german_legal_engine/
│ ├── __init__.py # Öffentliche API-Exporte
│ ├── client.py # Einheitliches Python-SDK (LegalEngine)
│ ├── server.py # FastMCP-Server (stdio und sse) für Claude Desktop, Cursor etc.
│ ├── norms.py # Autarker Normen-Parser für gesetze-im-internet.de
│ ├── case_law.py # Rechtsprechungs-Client für BGH, BAG, BVerfG (100% Python)
│ ├── bayern.py # Nativer Scraper für bayerische Gerichte (gesetze-bayern.de)
│ ├── subsumption.py # Subsumtions-Blueprints (Merkmale & Beweislast)
│ ├── deadlines.py # Exakte Fristenmathematik gem. §§ 187-193 BGB
│ ├── sanitizer.py # Zero-Dashes Bereinigung & BGH-Zitierweise
│ └── cli.py # Komfortables Terminal-Tool (gle)
├── tests/
│ ├── test_deadlines.py # BGB-Fristen- und Feiertagstests
│ ├── test_subsumption.py # Subsumtions- und Bereinigungstests
│ ├── test_case_law.py # Rechtsprechungs- und Bayern-Tests
│ └── test_norms.py # Gesetzesabruf- und Slug-Tests
└── examples/
├── 01_statutory_lookup.py # Gesetzesabruf in der Praxis
├── 02_case_law_research.py # Recherche von Leitentscheidungen
└── 03_procedural_deadline.py # Fristenberechnung mit Feiertagsprüfung# Repository klonen und im Editable-Modus installieren
git clone https://github.com/rzgrw/german-legal-engine.git
cd german-legal-engine
pip install -e .gle)Das mitgelieferte CLI-Werkzeug gle ermöglicht die sofortige Abfrage direkt im Terminal:
# 1. Gesetzestext wortlautgetreu abrufen (z. B. § 823 BGB, § 81 AufenthG)
gle norm BGB 823
# 2. Rechtsprechung durchsuchen (Bundesgerichte + bayerische Gerichte)
gle search "Mietkaution Rückzahlung" --limit 3 --source ALL
# 3. Volltext einer Entscheidung abrufen
gle decision Y-300-Z-BECKRS-B-2021-N-30750
# 4. Prozessuale Notfrist berechnen (§§ 187-193 BGB)
# Kündigungszugang am 03.10.2026 + 1 Woche Frist in Bayern (BY):
# Fällt regulär auf Samstag, den 10.10. -> automatische Verschiebung auf Montag, den 12.10.2026!
gle deadline 2026-10-03 1 wochen --state BY
# 5. Tatbestandsmerkmale und Beweislast analysieren
gle subsume BGB 280from datetime import date
from german_legal_engine import LegalEngine
# 1. Gesetzliche Norm abrufen
norm = LegalEngine.get_norm("BGB", "551")
print(norm["title"])
print(norm["content_clean"])
# 2. Frist berechnen (inklusive Feiertagsverschiebung)
frist = LegalEngine.compute_deadline(
ereignis_datum=date(2026, 10, 3),
dauer_wert=1,
dauer_einheit="wochen",
state="BY"
)
print(frist["citation"])
# Ausgabe: "Fristablauf am 12.10.2026 um 24:00 Uhr gem. §§ 187 Abs. 1, 188 Abs. 2, 193 BGB"
# 3. Präzedenzfälle recherchieren
urteil = LegalEngine.search_precedents("Kündigungsschutz Wartezeit", limit=2)
for u in urteil:
print(f"- {u['citation']}: {u['title']}")Die Engine stellt einen standardkonformen MCP-Server bereit, der sich nahtlos in Claude Desktop, Claude Code, Cursor, OpenCode und Hermes Agent einklinkt.
claude_desktop_config.json):{
"mcpServers": {
"german-legal-engine": {
"command": "python3",
"args": ["-m", "german_legal_engine.server"]
}
}
}get_norm(law, section): Liefert den amtlichen Volltext der gesuchten Rechtsnorm (Bund und Länder).
search_precedents(query, limit, court, source): Durchsucht amtliche Entscheidungen von Bundesgerichten (BGH, BAG, BVerfG) und bayerischen Gerichten (gesetze-bayern.de).
get_decision(doc_id): Ruft die amtliche Volltext-Entscheidung mit Randnummern ab.
compute_deadline(ereignis_datum, dauer_wert, dauer_einheit, state): Mathematisch exakte Fristenberechnung gem. §§ 187-193 BGB mit Feiertagskontrolle aller 16 Bundesländer.
get_subsumption_blueprint(law, section): Liefert strukturierte Tatbestandsmerkmale mit zugehöriger Darlegungs- und Beweislast (Arbeitshilfe, kein amtlicher Text).
anonymize_text(text): Schwärzt sensible personenbezogene Daten (IBAN, E-Mail, Telefon, Anschriften) gem. Art. 5 DSGVO.
prepare_pleading_dossier(norms, query): Erzeugt einen fertigen, zitatgesicherten Rechercheblock für Klageschriften und Schriftsätze.
Die German Legal Engine wurde unter strikter Beachtung des deutschen Urheber- und Datenschutzrechts konzipiert. Ausführliche Leitlinien finden sich in COMPLIANCE.md:
Amtliche Werke gem. § 5 Abs. 1 UrhG: Die Engine ruft ausschließlich Gesetze, Verordnungen und gerichtliche Entscheidungen aus amtlichen Bundes- und Landesquellen ab. Diese genießen als amtliche Werke keinen urheberrechtlichen Schutz.
Ausschluss privater Normen (§ 5 Abs. 3 UrhG): Das Framework verzichtet bewusst auf die Einbindung privater DIN/ISO-Normen oder urheberrechtlich geschützter Fachliteratur.
Schutz von Datenbankrechten (§§ 87a, 87b UrhG) & § 44b UrhG: Kein massenhaftes systematisches Scraping oder unautorisiertes Spiegeln fremder Datenbanken. Die Abfragen erfolgen rein punktuell on-demand mit vollständiger Quellenintegrität und Zeitstempel (Source Provenance).
Datenschutz durch lokale Ausführung (DSGVO): Die Engine läuft als lokale Open-Source-Runtime on-premise auf dem Rechner des Nutzers. Es existiert kein zentraler Server, der Mandantendaten, IP-Adressen oder vertrauliche Suchanfragen speichert oder verarbeitet.
Integrierte PII-Redaktion: Schnelle Schwärzung von Mandanten- und Kontodaten über anonymize_text vor der Weitergabe an LLM-Schnittstellen.
Das Testset prüft die exakte Einhaltung der gesetzlichen Fristenlogik und Bereinigungsregeln:
# Tests ausführen
python3 -m unittest discover testsDieses Projekt steht unter der freien MIT-Lizenz.
Copyright (c) 2026 Agentiqa Core Team.
Calculate German procedural deadlines under §§ 187-193 BGB and ZPO with weekend and statutory holiday shifting across all 16 German states.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | BY | |
| dauer_wert | Yes | ||
| dauer_einheit | No | wochen | |
| ereignis_datum | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses that weekend and statutory holiday shifting is applied across all 16 states, which is real behavioral context beyond a bare 'calculate' claim, but it says nothing about day-counting conventions, how the state parameter affects the result, or whether the calculation is deterministic/read-only.
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?
A single dense sentence with the legal basis and operational scope front-loaded and no filler. Every clause (legal sections, holiday shifting, state coverage) 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?
An output schema exists, so return values need not be explained, and the description covers the legal framework and shifting behavior well. However, with zero annotation coverage and 0% parameter schema descriptions, it leaves the input contract under-specified for a tool whose correctness hinges on units and state codes.
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 0%, so the description must compensate for four undocumented parameters, and it largely does not. It hints at the state parameter ('all 16 German states') but never explains state codes, the dauer_einheit unit values (default 'wochen'), or the expected format of ereignis_datum, leaving critical inputs like duration unit unclarified.
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 (calculate), resource (German procedural deadlines), legal basis (§§ 187-193 BGB and ZPO), and scope (weekend/statutory holiday shifting, all 16 states). This is far more specific than the sibling tools, though it does not explicitly name an alternative to route against.
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?
No when-to-use or when-not-to-use guidance is given, nor any mention of prerequisites or alternatives. The agent can infer this is for deadline computation, but nothing states the conditions that select this tool over, say, get_norm or prepare_pleading_dossier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the authentic full text and Randnummern of a court decision by document ID.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully signals that the returned text is the 'authentic' authoritative version and that Randnummern numbering is included, but says nothing about permissions, rate limits, completeness of the text, or not-found behavior.
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?
A single front-loaded sentence that identifies the action, the payload, and the key. No filler, nothing wasted.
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?
An output schema exists, so return structure need not be described, and this is inherently a read-only lookup. Still, the absence of any annotation coverage leaves error behavior and the scope of the retrieved text (full vs excerpt) unspecified.
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?
One required parameter with 0% schema description coverage, so the description must compensate. 'by document ID' does identify the parameter's meaning (a document identifier), but adds no format, source, or example guidance beyond that.
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 (Retrieve) and resource (full text and Randnummern of a court decision) with the lookup key (document ID). It implicitly distinguishes itself from discovery tools like search_precedents, but never names a sibling explicitly.
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?
Usage is only implied: the 'by document ID' phrasing signals a post-search lookup, so an agent can infer it follows search_precedents, but there is no explicit when-to-use statement, no exclusions, and no mention of what happens when the ID is unknown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve official, verbatim German federal or state statutory law (BGB, ZPO, KSchG, StGB, RVG, AufenthG, etc.) directly from official government repositories.
| Name | Required | Description | Default |
|---|---|---|---|
| law | Yes | ||
| section | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It adds genuine behavioral context by asserting the source is authoritative and 'verbatim' from official repositories, which matters for trustworthiness. However, it omits failure behavior (e.g., unknown law/section), coverage limits for the statutory corpus, and any access requirements.
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?
A single tightly written sentence with the verb and resource front-loaded. Every clause earns its place: source fidelity, jurisdiction scope, and concrete examples.
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?
An output schema exists, so return values need no explanation, and the annotation gap is partially offset by the description's source-fidelity claim. Still, with 0% parameter coverage and no usage or error guidance, the definition is only minimally sufficient for a lookup tool whose inputs are easy to get wrong.
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 0% for both parameters, so the description must compensate. The enumerated law abbreviations (BGB, ZPO, KSchG, StGB, RVG, AufenthG) usefully imply the expected format for 'law', but the 'section' parameter's expected syntax (e.g., '§ 823' vs. '823') is left entirely undefined in both schema and 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?
States a specific verb ('Retrieve') and a precisely scoped resource ('official, verbatim German federal or state statutory law') drawn from a named source class ('official government repositories'). The resource domain makes it inherently distinguishable from siblings like search_precedents, get_decision, and compute_deadline, so an agent can route to it 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 says only what the tool does, not when to prefer it over alternatives. There is no guidance on when to use get_norm vs. search_precedents or get_decision for legal research, and no stated prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve directed legal subsumption blueprints: Tatbestandsmerkmale, factual details, burden of proof (Beweislast), and statutory legal consequences.
| Name | Required | Description | Default |
|---|---|---|---|
| law | Yes | ||
| section | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Retrieve' implies a read-only lookup and the enumeration characterizes the returned content, but there is no disclosure of permission requirements, lookup failure behavior when a law/section pair has no blueprint, or coverage limits.
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?
A single front-loaded sentence with no filler. The enumerated list of blueprint components is dense but each item earns its place by telling the agent what the blueprint contains.
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 output schema exists, so return-value explanation is not required, and the description's content list is a reasonable supplement. However, the undocumented parameter formats and absent usage guidance leave the definition only minimally sufficient for a legal-domain lookup tool.
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 0% and the description never mentions the 'law' and 'section' parameters. The agent gets no format hints (e.g., 'BGB' vs 'German Civil Code', '§ 823' vs '823'), which is a real gap for a two-required-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?
States a specific verb (Retrieve) and a specific resource (legal subsumption blueprints), then enumerates the components returned (Tatbestandsmerkmale, Beweislast, legal consequences). An agent can grasp what the tool yields without opening a schema, though it does not explicitly distinguish itself from siblings like get_norm or search_precedents.
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?
No when-to-use guidance, no prerequisites, and no mention of alternatives among the sibling tools (get_norm, search_precedents, get_decision). The agent must infer usage purely from the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prepare an executive, citation-grounded legal context dossier for drafting court pleadings or legal briefs without hallucinations or dashes.
| Name | Required | Description | Default |
|---|---|---|---|
| norms | Yes | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses output-quality behavior ('citation-grounded', 'without hallucinations or dashes'), implying a grounding/non-fabricating operation. However it says nothing about access requirements, whether it mutates any state, or performance characteristics.
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?
A single front-loaded sentence with a clear verb-object framing and no padding. The trailing 'or dashes' clause is slightly idiosyncratic but the sentence remains efficient.
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?
An output schema exists, so return-value explanation is not strictly needed, but with no annotations and 0% parameter coverage the description should at least explain the 'norms' structure. For a two-required-param tool it leaves key invocation details unaddressed.
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 0% with two required parameters, one of which ('norms') is a nested array-of-arrays of strings whose intended format is opaque. The description offers no clarification of either 'norms' or 'query', leaving the agent to guess how to construct the crucial 'norms' input.
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 (Prepare) and resource (a citation-grounded legal context dossier) with the intended downstream use case (drafting pleadings/briefs). It does not explicitly differentiate itself from siblings like get_subsumption_blueprint or search_precedents, but the resource and purpose are clear enough to distinguish it.
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 phrase 'for drafting court pleadings or legal briefs' implies the context of use, but there is no explicit when-to-use/when-not guidance and no mention of the sibling tools (search_precedents, get_norm) it should be combined with or preferred over.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search authentic German court case law: federal courts (BGH, BAG, BVerfG, BVerwG, BFH) via Rechtsprechung im Internet and Bavarian courts (AG/LG/OLG München) via gesetze-bayern.de.
| Name | Required | Description | Default |
|---|---|---|---|
| court | No | ||
| limit | No | ||
| query | Yes | ||
| source | No | ALL |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It usefully names the external data sources and jurisdictional coverage (federal and Bavarian courts), but omits access requirements, rate limits, result ordering, and exhaustiveness details.
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?
A single front-loaded sentence with no filler; every clause names relevant courts or sources. It is appropriately sized, though it could trade some enumeration for parameter guidance.
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 four-parameter search tool with no annotations and no schema descriptions, the definition is incomplete. It says what is searched but not how to control the search or when to prefer it; the output schema covers returns, but invocation context 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 0% and none of the four parameters (query, court, limit, source) are described in the description. The mention of court names and database names loosely relates to the court/source parameters but gives no format, defaults, or filtering behavior.
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 ('Search') and resource ('authentic German court case law'), and enumerates covered courts and databases. It does not explicitly distinguish itself from sibling tools like get_decision or get_norm, so it stops short of 5.
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?
No when-to-use, when-not-to-use, or alternative tool guidance is provided. The description establishes the legal domain but leaves the agent to infer that this is for precedent lookup rather than decision retrieval or norm lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0compute_deadlineget_decisionget_normget_subsumption_blueprintprepare_pleading_dossiersearch_precedentsScored across 6 tools
search_precedents (case law search) and get_decision (full text by ID) are related but clearly distinct actions, and get_norm cleanly separates statutes from case law. get_subsumption_blueprint and prepare_pleading_dossier both support drafting and could be momentarily confused, but their descriptions differentiate blueprint retrieval from dossier preparation.
All six tools follow a consistent verb_noun snake_case pattern: search_precedents, get_decision, compute_deadline, get_subsumption_blueprint, prepare_pleading_dossier, get_norm. No mixing of conventions.
Six tools is well-scoped for a focused legal engine covering case law, statutes, deadlines, and drafting. Each tool earns its place, though the surface is somewhat lean for the breadth of the legal domain.
The set covers the core legal research and drafting lifecycle: finding precedents, retrieving decisions and norms, computing deadlines, and preparing pleadings. Minor gaps exist (e.g., no explicit citation formatting or update/versioning, appeal lifecycle), but the primary workflows are covered.
Verified, citable German & EU law for any LLM. Daily updates from official sources, hosted in DE.
Verified, citable German & EU law for any LLM. Daily updates from official sources, hosted in DE.
German federal and Land statutes plus court decisions for agents. Keyless, read-only, CC BY 4.0.
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.