MCP server for German & EU law. Verified, citable legal context for any LLM. Daily updates from official sources, hosted in Germany
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.6/5 across 11 of 11 tools scored. Lowest: 3.8/5.
Each legal tool targets a distinct operation: finding citing decisions, retrieving context, legislative history, stats, TOC, law lists, and exact lookups. The batch lookup is clearly a convenience wrapper for the single lookup, and the generic resource tools are unmistakably separate from the legal research functions.
All legal tools follow a consistent 'legal_' prefix plus verb_noun pattern (e.g., legal_find_citing_decisions, legal_get_context, legal_list_laws). The two generic MCP tools also follow verb_noun (list_resources, read_resource), maintaining overall consistency.
With 11 tools, the server is well-scoped for a comprehensive legal research domain. Each tool provides a distinct capability, and none feels redundant or excessive. The count is within the ideal 3-15 range.
The tool set covers the core legal research lifecycle: discovery (list_laws, search), lookup (lookup, lookup_batch), citation analysis (find_citing_decisions), structural navigation (get_toc, get_context), and legislative intent (get_materials). Minor gaps exist, such as the lack of coverage for certain state court decisions and non-German legislative materials, but these are explicitly documented and workarounds are provided.
legal_find_citing_decisionsFind Citing Court DecisionsAList 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. For decisions relevant to a specific question or fact pattern, use legal_search with the cited_norm filter instead: it ranks the full citing population against your case question.
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. 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. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read only and idempotent, but the description adds substantive behavior: paragraph-level matching (e.g., '§ 280 Abs. 1 BGB' finds § 280 BGB citations), return of Leitsatz and ECLI, and the cited_norms array for cross-referencing. It even explains reverse-mapping of EU instruments to aliases and the EURL 98/59 fallback, which is far beyond the annotation bar.
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 structured, with the primary purpose front-loaded in the first sentence and alternative tool guidance immediately after. The extensive court lists and EU resolution details earn their place given the tool's complexity, though some 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?
With an output schema present, the description's inclusion of Leitsatz, ECLI, and cited_norms adds value without being required. It covers purpose, alternatives, matching semantics, and EU resolution behavior, making it complete for a complex legal research 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?
The input schema has 100% description coverage, so the baseline is 3; the main description adds extra context about paragraph-level matching and representation of EU instruments (aliases vs. EURL compact form). While useful, this mostly reinforces the schema's already detailed cited_norm guidance, so a 4 rather than 5 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 'List' and clearly defines the resource: German, state, and EU court decisions citing a specific legal provision, described as a 'raw citation INVENTORY, newest first.' It distinguishes itself from legal_search, which ranks citing decisions against a case question.
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?
Explicitly states when NOT to use this tool: 'For decisions relevant to a specific question or fact pattern, use legal_search with the cited_norm filter instead.' It also provides contextual guidance on preferring transposition norms for German case law and directive articles for EU-level interpretation.
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 ProvisionsAGet adjacent norms (paragraphs/articles) before and after a target provision in document order. Use when a legal question may span consecutive provisions or when surrounding context is needed to understand a norm's scope.
Requires a norm_id from a prior legal_search or legal_lookup result. Returns the target norm plus up to 10 neighbors in each direction. For a law-wide overview rather than just neighbors, use legal_get_toc.
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | Number of norms after the target (max 10). | |
| before | No | Number of norms before the target (max 10). | |
| norm_id | Yes | norm_id from a prior legal_search or legal_lookup result. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds meaningful behavioral details beyond that: it states the return includes the target norm plus up to 10 neighbors in each direction, and it explicitly requires a norm_id from a prior result. No contradiction exists.
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 efficient. Every sentence serves a purpose: purpose, usage context, prerequisite, return behavior, and an explicit pointer to an alternative tool. No filler or redundancy.
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?
Despite having an output schema, the description covers prerequisite (norm_id), return scope (target plus neighbors), and a clear alternative for broader context. For a tool of this complexity, it is complete and leaves no critical gaps for an agent to guess.
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 provides complete descriptions for all three parameters (norm_id, before, after) with ranges and defaults. The description reinforces the 'up to 10 neighbors' concept but adds little beyond the schema. Baseline of 3 is appropriate due to full schema coverage.
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 explicitly names the action ('Get adjacent norms'), the object (paragraphs/articles before and after a target provision), and the ordering ('document order'). It also distinguishes itself from the sibling tool legal_get_toc by noting the alternative for law-wide 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?
It provides clear when-to-use context: 'Use when a legal question may span consecutive provisions or when surrounding context is needed to understand a norm's scope.' It also names the alternative tool (legal_get_toc) and requires a prior norm_id from legal_search or legal_lookup, setting expectations for prerequisites.
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)AReturn 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.
Reach for it when the question turns 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). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a safe read operation, but the description adds substantial behavioral context: the weight of the Begründung as evidence ('strong evidence of legislative intent but not binding'), the coverage scope ('Covers amendments since 1949... only'), and the source preparation ('Excerpts are prepared from the Bundestag-extracted text, not the original PDF'). No contradictions 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 longer than minimal but well-structured: it front-loads the core purpose, then usage, then output and scope. Each sentence contributes substantive legal context, so it earns its place, though it could be tightened without losing critical 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?
For a legal research tool with output schema present, the description is remarkably complete. It explains purpose, usage triggers, legal weight, output characteristics ('Returns the linked Begründungs-Abschnitte newest first'), scope limits, and relationship to sibling tools—everything an agent needs to decide and invoke 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?
Schema description coverage is 100%, so the baseline is 3. The description adds value by giving a concrete example for the 'norm' parameter ('Pass a provision like '§ 823 BGB' or 'Art. 87a GG'') and by clarifying that an unknown or non-German provision returns no materials. This goes slightly beyond the schema's generic 'e.g.' text.
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 / explanatory memorandum from a Bundestags-Drucksache) for a specific German federal provision'. It clearly distinguishes itself from sibling legal_find_citing_decisions by stating it provides the drafting intent while the sibling covers how courts apply a norm.
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?
Explicit guidance is given for when to use: 'Reach for it when the question turns on a norm's purpose... or what a specific amendment was meant to achieve'. It also names the complementary alternative, legal_find_citing_decisions, and notes coverage limitations ('Covers amendments since 1949 to German federal law only').
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 StatisticsAGet 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 | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context by specifying what statistics are returned (counts of laws, norms, indexed vectors) and the purpose of the tool, which goes beyond the annotations without contradicting them.
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 concise: two sentences, with the first stating the primary function and the second giving explicit use cases. There is no unnecessary verbosity, and the most important information is front-loaded.
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 no-parameter, read-only statistics tool with an output schema and rich annotations, the description is fully complete. It communicates what data is returned and why to use it, covering both behavioral and selection aspects without redundancy.
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, so the baseline is 4. The schema description coverage is trivially 100%, and the description does not need to explain parameter behavior since there are none.
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 uses a specific verb ('Get') and identifies the resource as 'database and search index statistics,' then lists example contents (counts of laws, norms, indexed vectors). This clearly distinguishes the tool from sibling tools like legal_search or legal_lookup, which serve different functions.
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: 'Use for health checks or to understand the scope of the legal corpus.' This provides clear usage context. However, it does not explicitly mention alternatives or exclusions, so it falls short of the highest benchmark.
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 ContentsAGet 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.
Use when you need an overview of a law's structure before drilling into specific provisions. Pass a returned norm_id to legal_get_context to read 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 | 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. | |
| source_type | No | '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. | |
| law_abbreviation | Yes | Law abbreviation, e.g. 'bgb', 'dsgvo', 'stgb'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive behavior. The description adds behavioral details about return format (norm keys, titles, headings in document order), pagination for large laws, and that a norm_id can be used for follow-up calls. This goes beyond the 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?
Three concise, front-loaded sentences: core function, usage guidance, pagination note. Every sentence adds value without redundancy.
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 read-only TOC tool with rich annotations, detailed schema, and output schema present, the description is complete. It explains purpose, usage context, return content, pagination behavior, and next steps, leaving no critical gaps.
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% with descriptive parameter descriptions for all five fields. The description adds no new parameter-specific meaning; it only references a returned norm_id, which is not a parameter. Baseline of 3 is appropriate given the schema already handles semantics.
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 the table of contents of a law or court decision, naming specific return content (norm keys, titles, chapter headings) and document order. It distinguishes itself from siblings by specifying it's for structural overview before drilling into provisions, and it points to legal_get_context for full text.
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?
Explicitly says 'Use when you need an overview of a law's structure before drilling into specific provisions' and mentions passing norm_id to legal_get_context. This gives clear context, though it doesn't explicitly enumerate when not to use it or name other alternatives.
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 LawsAList 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. Found a relevant law? Use legal_get_toc to browse its structure.
NOT an existence check for a specific law: EUR-Lex entries store the official long title, so searching by common name or number can miss laws that ARE in the corpus. To verify a law exists, use legal_lookup with a citation or legal_search with a topic instead.
| 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 | 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. | |
| 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 — pair it with language='en', or the DE default leaves you only the few translated documents. | |
| jurisdiction | No | 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. | |
| 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. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds valuable behavioral context: unfiltered listings can contain thousands of entries, and EUR-Lex entries store official long titles so common-name searches can miss existing laws. These caveats help the agent anticipate large responses and avoid false negatives.
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 well-structured: it opens with the core purpose, then return fields, then performance guidance, then usage context, then exclusions. While longer than the minimal example, every sentence earns its place; the structure is front-loaded and avoids redundancy with the schema.
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 list tool with rich annotations and a detailed input schema, the description is complete. It covers what the tool does, what it returns, when to use it (and when not), performance characteristics, and related tools. No essential context is missing for correct selection and invocation.
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 has 100% coverage with very detailed parameter descriptions, so the baseline is 3 per the rules. The description adds value by explaining search behavior pitfalls (e.g., common names or numbers may not match due to official long titles) and by reinforcing the search/source_type filtering suggestion, which goes beyond the schema's literal field explanations.
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 explicitly states it lists available laws, regulations, and court decisions, and enumerates the returned fields (abbreviation, title, source type, jurisdiction, document kind, version date). It clearly distinguishes itself from sibling tools by describing its role in discovering valid law abbreviations and pointing to legal_get_toc and legal_lookup for other tasks.
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 usage guidance: useful for discovering abbreviations for legal_search, recommends legal_get_toc for browsing a found law's structure, and warns not to use it as an existence check. It names specific alternatives (legal_lookup, legal_search) for verification, making the when-to-use vs. when-not-to-use crystal clear.
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 CitationAGet the full text of a specific legal provision by exact 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. A decision lookup returns its lead section (Leitsatz) — use legal_get_toc / legal_get_context on the result to read further sections.
| Name | Required | Description | Default |
|---|---|---|---|
| citation | Yes | Full citation string, e.g. '§ 823 BGB' or 'VII ZR 184/14' | |
| language | No | 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. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (read-only, idempotent), the description reveals flexible citation order and that decision lookups return the Leitsatz, with a suggestion to use additional tools for further sections. This adds valuable behavioral detail without contradicting 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?
Four sentences, each providing distinct value: purpose, examples, formatting flexibility, and decision-lookup behavior with tool handoff. No redundant or vague 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?
For a read-only lookup tool with an output schema, the description is sufficiently complete. It covers input types, resolution behavior, decision-lookup semantics, and follow-up tools, enabling correct tool selection and invocation.
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 both parameters fully, but the description enhances the citation parameter with concrete examples ('§ 823 BGB', 'ECLI:...') and notes that citation order is flexible. The language parameter is well-documented in the schema and not repeated unnecessarily.
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 that the tool retrieves full legal provisions or court decisions by exact citation/Aktenzeichen/ECLI, with concrete examples. It distinguishes itself from siblings by focusing on exact lookup and recommending legal_get_toc / legal_get_context for further sections.
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 defines when to use this tool (exact citation lookup) and points to alternatives for follow-up (legal_get_toc / legal_get_context). It does not explicitly contrast with search or batch lookup tools, but the context makes the usage clear.
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 ProvisionsALook up full text of multiple legal provisions in a single call (exact match). 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']). Returns exact matches only — citations not found appear as found=false. For fuzzy matching of hard-to-find provisions, use individual legal_lookup.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | 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. | |
| citations | Yes | List of citation strings, e.g. ['§ 823 BGB', 'Art. 6 DSGVO']. Max 20. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds valuable context: exact matches only, citations not found appear as found=false, and a 1-20 citation count limit. These details go beyond the annotations without contradicting them.
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 sentences: purpose, constraints with examples, and alternative usage. Every sentence earns its place with no redundancy or filler. The structure is front-loaded and scannable.
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 is straightforward, output schema exists, and the description covers batch-size limits, exact-match behavior, not-found reporting, and the relationship to the sibling tool. Nothing essential is missing for correct selection and invocation.
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 100% of parameters, so baseline is 3. The description enhances this by giving concrete example citation strings and clarifying that court-decision references are accepted in the same form as legal_lookup, which is not fully explicit in 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 opens with a specific verb and resource: 'Look up full text of multiple legal provisions in a single call (exact match).' This clearly distinguishes it from the individual legal_lookup sibling and communicates the batch scope.
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?
Explicitly provides an alternative: 'For fuzzy matching of hard-to-find provisions, use individual legal_lookup.' This gives a clear when-not condition and directs the agent to the correct sibling for fuzzy needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
legal_searchSearch Legal DocumentsASearch 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.
Rephrase colloquial language into legal terminology for best results. Formuliere Suchanfragen als natürliche Sätze, nicht als Keyword-Listen (z.B. 'Wann verjährt ein Schadensersatzanspruch?' statt 'Verjährung Schadensersatz Frist BGB'). Das System durchsucht Gesetzestexte — verwende die Sprache des Gesetzes, nicht Doktrin-Begriffe (z.B. 'Auslegung mehrdeutiger Klauseln' statt 'contra proferentem'). Set document_kind to match what the question needs: any norm subtype ('statute'/'regulation'/'directive') when it asks for the rule itself — its requirements, definitions or deadlines; 'decision' when it asks how courts apply a rule. The three norm subtypes form ONE filter class — any of them admits all three, so you need not tell statute from regulation from directive, and a reflexive 'statute' never hides an EU regulation/directive. The only real cut this filter makes is norm vs. case-law: 'decision' restricts to court decisions and drops every norm BEFORE ranking, so it can hide the statute that answers a rule question. Leave document_kind empty when the question genuinely needs both (norm + its case-law application), or when German-vs-EU law is unclear (e.g. data protection: BDSG vs DSGVO) — then consider running two searches with different filters instead of guessing. Never combine a statute law_abbreviation with a decision scope ('decision', a decision source_type, court or decision_type): decisions carry file-number identifiers, not statute abbreviations, so that intersection is always empty — use cited_norm instead to find decisions applying a law. See legal://filter_values for the per-value definitions and the disambiguation list. Set law_abbreviation, jurisdiction and source_type only when the user explicitly names a specific law or jurisdiction. When results span multiple laws or versions, check the legal://rechtsrahmen resource to pick the correct jurisdiction (e.g. EU vs national, substantive vs procedural).
COMMON PITFALLS — choose the correct law:
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 | Search query as a natural sentence using statutory language (not keywords or doctrinal terms). | |
| top_k | No | Number of results to return (default 5). | |
| chapter | No | Filter by chapter/section within a law. Rarely needed — can reduce recall. Only useful with law_abbreviation. | |
| date_to | No | Include results until this date (YYYY-MM-DD). | |
| language | No | 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. | |
| 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'). 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. | |
| source_type | No | 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. | |
| 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). For federal statutes ONLY, use source_type='gii' instead. Leave empty for cross-jurisdiction search. | |
| 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 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. | |
| law_abbreviation | No | Filter by law abbreviation, e.g. 'bgb', 'dsgvo'. Leave empty for thematic questions. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety (readOnly, idempotent, non-destructive), and the description adds substantial behavioral context: result snippets not full text, norm subtypes as one filter class, decisions dropped before ranking, materials only appear on request, language corpus differences, and the empty-intersection warning. No contradictions 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 long but well-structured with clear sections, front-loading the core purpose. Some redundancy exists, such as repeating the natural-sentence query guidance in both English and German, which adds some bulk but does not detract from readability. It is appropriately sized for the tool's 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 13-parameter, complex legal search tool, the description is thorough: it covers query formulation, filter interactions, cross-references to legal:// resources, and common legal pitfalls. An output schema exists, so lack of detailed return description is acceptable; the description states what the user needs to know.
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?
Despite 100% schema coverage, the description enriches parameter understanding far beyond schema descriptions: document_kind class semantics, cited_norm paragraph matching and transposition-norm strategy, language corpus size and separation, source_type specifics (bverfge slice, bverwg scope), and the law_abbreviation/decision conflict. All 13 parameters are given practical meaning.
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: 'Search legal documents across jurisdictions... using hybrid semantic + keyword search' and clearly notes returns are ranked snippets, not full text. It distinguishes from sibling tools through inline pointers to alternatives like legal_find_citing_decisions and legal_get_materials, establishing a unique purpose.
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 guidance is explicit and extensive: when to set document_kind (rule vs. application), when to leave it empty, when to use cited_norm vs. document_kind, and when to use alternative tools. It even gives decision rules for two searches and a full section on correct law abbreviations, satisfying the when/when-not requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_resourcesAList 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 | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the readOnlyHint annotation by explaining that the return JSON distinguishes static resources ('uri' field) from templates ('uri_template' field with placeholders). This helps the agent understand the output structure without contradicting the annotation.
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, front-loaded with the core action and a concise structural detail about the return format. Every word earns its place, with no redundancy.
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 zero-parameter listing tool with an output schema and readOnlyHint annotation, the description covers purpose and return structure sufficiently. It explains the resource/template distinction, which is the key contextual information an agent needs.
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, so schema coverage is effectively 100%. The description correctly omits parameter details, and the baseline of 4 applies because there is nothing to add 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 uses the specific verb 'List' and identifies the resource as 'all available resources and resource templates,' clearly distinguishing it from sibling tools like read_resource. It leaves no ambiguity about 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 implies usage for discovering available resources but does not explicitly state when to use this tool versus alternatives such as read_resource. No exclusion or alternative guidance is provided, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_resourceARead 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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given the readOnlyHint annotation, the description adds valuable behavior beyond annotations: it discloses that content is returned as a string and that binary content is base64-encoded. This addresses the return format, which is not itemized in the schema. It does not discuss auth requirements or error behavior, but for a simple read operation the additional context is sufficient.
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 concise at three sentences, with the primary verb and resource in the first sentence. It front-loads the core purpose and then provides two clarifying details (templated URI handling and binary encoding) without redundancy or tangential fluff.
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 single-parameter tool, the description covers the key usage nuances (URI types) and return format (string/base64). An output schema exists to detail structured return values, so the description does not need to repeat that. It is complete for an agent to correctly invoke the 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?
The schema description for 'uri' is brief ('The URI of the resource to read'), but the tool description adds meaningful semantics by explaining how URIs work for static vs. templated resources. This helps the agent correctly construct the parameter value, which is valuable beyond the schema's minimal definition.
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 states 'Read a resource by its URI' with a specific verb and resource, clearly distinguishing this from sibling tools like list_resources (enumeration vs. reading a specific resource). It also distinguishes between static and templated URIs, adding precision.
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 clear context on how to use the tool—by giving exact URIs for static resources and filled-in parameters for templated ones—making the usage pattern explicit. However, it does not explicitly mention when not to use this tool or direct users to alternatives like list_resources for enumeration, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
