Lawbster
Server Details
MCP server for German & EU law. Verified, citable legal context for any LLM. Daily updates from official sources, hosted in Germany
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 4.5/5 across 10 of 10 tools scored.
Each tool has a clearly distinct purpose: search, lookup, batch lookup, context, TOC, listing laws, citing decisions, statistics, and resource management. No functional overlap exists.
All legal tools follow a consistent 'legal_verb_noun' snake_case pattern. Two standard MCP tools (list_resources, read_resource) lack the prefix, but this is a minor deviation.
10 tools is well-scoped for a legal information retrieval server. It covers search, lookup, context, TOC, listing, statistics, and citing decisions without being too sparse or overwhelming.
The tool surface covers the core workflow (search→lookup→context→citing decisions) and auxiliary features (TOC, listing, statistics). A minor gap is the lack of a tool to retrieve the full text of an entire law, but this is not essential.
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) 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. Does not cover state court decisions.
| 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'. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent; the description adds extensive behavioral context such as paragraph-level matching, cited_norms array, resolution of EU instruments, and limitations, with no contradictions.
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 but quite verbose with multiple paragraphs detailing edge cases; conciseness could be improved while maintaining clarity.
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 exists, the description covers usage, matching behavior, output elements, integration with siblings, and limitations, providing comprehensive context.
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%, and the description adds value by explaining paragraph-level matching for cited_norm and default ordering (newest first), beyond the schema descriptions.
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 lists court decisions citing a legal provision, uses specific verbs and resource, and distinguishes from the sibling 'legal_search' by noting it provides raw inventory instead of relevance ranking.
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 when to use this tool (for raw citation inventory) and when to use alternative (legal_search for relevance), and guides to use legal_lookup for resolving norms.
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 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds behavioral detail about the return ('Returns the target norm plus up to 10 neighbors in each direction') and does not contradict annotations. No additional behavioral gaps remain.
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 two short paragraphs. Every sentence adds value: the first states action and use case, the second provides prerequisite, output limits, and alternative. It is front-loaded and contains no 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?
Given an output schema exists (not shown but noted), the description need not detail return structure, yet it still summarizes output. It covers purpose, prerequisites, boundaries, and alternative. For a tool with 3 parameters and clear annotations, this is fully adequate.
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 baseline is 3. The description adds context beyond the schema by explaining that norm_id must come from a prior legal_search or legal_lookup result, and reiterates the maximum neighbor count. This extra meaning pushes the score above 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 uses a specific verb 'Get' and resource 'adjacent norms (paragraphs/articles) before and after a target provision in document order'. It distinguishes itself from sibling tool legal_get_toc by explicitly noting the difference: 'For a law-wide overview rather than just neighbors, use legal_get_toc.'
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 guidance on when to use ('when a legal question may span consecutive provisions or when surrounding context is needed'), a prerequisite ('Requires a norm_id from a prior legal_search or legal_lookup result'), and an alternative tool ('For a law-wide overview rather than just neighbors, use legal_get_toc').
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.
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). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds useful behavioral details: returns excerpts from Bundestag-extracted text (not original PDF), covers amendments since 1949 to German federal law (gesetze-im-internet corpus). No contradictions.
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 with clear sections (purpose, when to use, output format, limitations) and front-loads key information. It is slightly verbose but every sentence adds value.
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 complexity and rich annotations, the description covers purpose, usage, return format, limitations, and weight. It mentions the output structure (Fundstelle, reasoning text, target_norm_keys) and complements sibling tools without relying on them.
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 descriptions for both parameters (norm and limit). The description reinforces the norm format with examples ('§ 823 BGB') and explains the limit's purpose, but adds only marginal value 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 returns legislative reasoning (Gesetzesbegründung) for a German federal provision, specifies the source (Bundestags-Drucksache), and explicitly distinguishes it from sibling tool legal_find_citing_decisions by noting it complements that tool with drafting intent.
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 guidance on when to use: 'when the question turns on a norm's purpose, meaning of unclear term, whether regulatory gap is planwidrig, what amendment meant to achieve.' Also states limitations (unknown/non-German provisions return nothing) and weight (strong evidence but not binding).
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 | ||
Tool Definition Quality
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 well-established. The description adds value by specifying the exact types of statistics returned (counts of laws, norms, indexed vectors), but does not disclose additional behavioral traits beyond what annotations provide.
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 extremely concise: two sentences front-loaded with action and resource, followed by usage guidance. Every sentence adds value, with no fluff or repetition.
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 has no parameters and includes a detailed output schema, the description is complete. It explains what statistics are returned and when to use the tool, which is sufficient for an agent to understand its role.
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?
There are no parameters (0 params, 100% schema coverage), so the baseline is 4. The description does not need to add parameter information, and it correctly describes the tool's purpose without referencing nonexistent parameters.
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 verb 'Get' and resource 'database and search index statistics' with specific counts of laws, norms, and indexed vectors. This effectively distinguishes it from sibling tools like legal_search or legal_lookup which focus on searching or retrieving specific items.
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 recommends using this tool for 'health checks or to understand the scope of the legal corpus,' providing clear context for when to use it. It does not mention when not to use or list alternatives, but the usage guidance is clear enough.
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.
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', 'sachsen_rechtsprechung', 'bayern_gesetze', or 'nrw_gesetze'. Leave empty to auto-detect. | |
| law_abbreviation | Yes | Law abbreviation, e.g. 'bgb', 'dsgvo', 'stgb'. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive. The description adds useful behavioral context: returns items in document order, paginated for large laws. This goes beyond annotations by explaining the output structure and pagination 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?
The description is four sentences long, front-loaded with the main purpose. Every sentence provides essential information: purpose, output, usage context, and note on pagination. 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 tool's complexity (5 parameters, output schema, annotations), the description covers the main usage, workflow with a sibling tool, and pagination. It could mention the required parameter law_abbreviation explicitly, but the schema covers that. Overall, it provides sufficient context for an agent.
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 detailed descriptions for each parameter, so the baseline is 3. The description does not add significant new meaning beyond what the schema already provides; it only implicitly references law_abbreviation. No extra semantics are needed.
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 'Get the table of contents of a specific law or court decision' and specifies the output format (norm keys, titles, chapter headings). It distinguishes from siblings by outlining a workflow: use this for overview, then pass norm_id 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?
The description explicitly states when to use the tool: 'Use when you need an overview of a law's structure before drilling into specific provisions.' It also provides guidance on the next step: 'Pass a returned norm_id to legal_get_context to read the full text.' This directly addresses 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 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. 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 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. | |
| 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', 'sachsen_rechtsprechung', 'bayern_gesetze', or 'nrw_gesetze'. | |
| 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_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' is separate and restricts to court case-law. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context: unfiltered listings can contain thousands of entries, search parameter also accepts CELEX numbers/EU references, and EUR-Lex entries use official long titles so common name search may miss. No contradictions.
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 well-structured paragraphs: purpose/output, usage guidance with tool links, limitations and alternatives. 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?
Given 7 parameters (all with enums), sibling tools, and output schema, the description covers purpose, behavior, filtering tips, limitations, and links to related tools. Complete guidance for correct agent 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 description coverage is 100%, so baseline 3. The description adds significant extra meaning: search parameter resolves CELEX/EU references, document_kind filter has special grouping behavior (norm subtypes form one class), jurisdiction 'de' matches federal+state law with suggestion to use source_type for federal only.
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 verb 'list', the resource 'available laws, regulations, and court decisions', and specifies the returned fields. It distinguishes from siblings like legal_get_toc, legal_search, legal_lookup by positioning itself as a discovery tool for abbreviations.
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 to use ('discovering valid law abbreviations to use as filters') and when not to use ('NOT an existence check'), with alternatives: use legal_lookup or legal_search instead. Advises passing search term or source_type to avoid unfiltered listings.
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
Get 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it explains that the tool returns full text for provisions but only the lead section for decisions, and that citation order is flexible. Annotations already indicate readOnly and idempotent behavior, so the description enriches without 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?
The description is three sentences long, front-loading the main purpose and then efficiently covering behavior and guidance. No extraneous words; every sentence adds necessary 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 presence of an output schema, the return values need not be elaborated. The description covers input flexibility, behavior for different citation types, and provides next-step guidance, making it fully complete for a tool of this complexity.
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 adds significant meaning: it explains flexible citation order with examples and clarifies the language parameter's corpus scope with practical guidance ('DE and EN are separate corpora...'). This goes beyond the schema's formal definition and helps the agent use parameters correctly.
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 that the tool retrieves full text of a legal provision by exact citation or a court decision by case number or ECLI. It distinguishes itself from sibling tools by noting that for decisions it returns only the lead section and suggests using legal_get_toc or legal_get_context for further reading, preventing confusion.
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 usage context for when to use this tool (exact citation) and gives explicit alternatives for further actions (legal_get_toc, legal_get_context). However, it does not explicitly state when not to use the tool, such as for vague queries where legal_search would be more appropriate, so it lacks a definitive exclusion.
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
Look 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare safe and idempotent. Description adds that it returns exact matches only and citations not found appear as found=false, plus corpus language behavior. No contradictions.
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?
4 sentences, front-loaded with main action, every sentence adds value. No 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?
Covers key aspects: purpose, exact match, error handling (found=false), language corpora. Output schema exists but not fully described; still sufficiently complete 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?
Schema coverage is 100%, so baseline is 3. Description adds example citation forms and the 1-20 range, adding some value beyond schema but not substantial.
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?
Description clearly states 'Look up full text of multiple legal provisions in a single call (exact match)' and provides examples, distinguishing from sibling legal_lookup.
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 'For fuzzy matching of hard-to-find provisions, use individual legal_lookup', giving clear when-to-use and when-not-to-use guidance.
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, 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. The single soft case is law_abbreviation: when it is set and contradicts document_kind, the use case reconciles document_kind to the law's actual class. 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, 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. | |
| 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), '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. | |
| 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_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'. 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. | |
| law_abbreviation | No | Filter by law abbreviation, e.g. 'bgb', 'dsgvo'. Leave empty for thematic questions. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe, non-destructive behavior. The description adds behavioral details beyond annotations: it explains the hybrid search method, return format (ranked results with snippets, not full text), and filter behaviors (e.g., document_kind class filtering, cited_norm restriction). No contradictions.
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 with sections (purpose, common pitfalls, parameter advice). However, it is quite lengthy and contains some redundancy (e.g., document_kind explanation appears in multiple places). It earns its length due to high utility but could be slightly trimmed.
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 complexity (13 parameters, multiple jurisdictions, filter interactions), the description is exceptionally complete. It covers query formulation, parameter usage, filter nuances, common pitfalls, and references to additional resources (legal://filter_values, legal://rechtsrahmen). Output schema exists, so return values are not needed.
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%, with each parameter having a description. The description adds significant context beyond the schema, especially for query (formulation advice), document_kind (filter class nuances), language (corpora explanation), and cited_norm (usage details). It compensates for potential ambiguity 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 clearly states the tool's purpose: 'Search legal documents across jurisdictions (DE federal, EU, Bavaria, Saxony) using hybrid semantic + keyword search.' It specifies the resource (legal documents) and action (search), and distinguishes from siblings like legal_find_citing_decisions and legal_lookup by mentioning hybrid search and snippet return.
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 extensive guidance on when to use the tool and how to configure filters (e.g., document_kind, law_abbreviation, jurisdiction). It includes common pitfalls and advice on query formulation. However, it could be more explicit about when not to use this tool versus alternatives (e.g., legal_find_citing_decisions is mentioned but not contrasted directly).
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, so the tool is safe. The description adds transparency by describing the return format (JSON with metadata) and differentiating static resources from templates, which is beyond 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?
Two concise sentences with no wasted words. The main action is front-loaded, and additional details are provided efficiently.
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 simplicity of the tool (zero parameters, output schema exists), the description is complete. It explains the output structure and the difference between resource types, which is sufficient.
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?
With no parameters and 100% schema coverage, the description does not need to add parameter details. According to guidelines, empty parameter list yields baseline score of 4.
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 lists all available resources and resource templates, distinguishing between static resources and templates with placeholders. This is specific and distinct from sibling tools like read_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?
The description implies when to use (to list all resources) but does not explicitly mention when not to use or compare with siblings like read_resource. No exclusions or alternatives are provided.
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only. The description adds value by explaining return format (string, base64 for binary), which is beyond annotations. No contradictions.
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 are concise and front-loaded with the main action. Could be slightly more streamlined, but no unnecessary 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?
Output schema exists, so return value details are not required. Description covers both resource types and encoding. Minor omission: no mention of error handling or missing resources, but overall complete for a simple read 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?
With only one parameter and schema coverage 100%, the description adds critical semantics: it explains how to use the URI parameter for static vs templated resources, which the schema description ('The URI of the resource to read') does not convey.
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 'Read a resource by its URI', which is a specific verb+resource pair. It distinguishes from sibling 'list_resources' by focusing on reading a single resource by URI, and adds nuance about static vs templated URIs.
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 guidance for static and templated URIs, telling the agent when to use exact URI vs filled template. Does not explicitly state when not to use or alternatives, but context from sibling names makes it clear.
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.
Discussions
No comments yet. Be the first to start the discussion!