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.6/5 across 11 of 11 tools scored.
Each tool has a distinct purpose: citing decisions, context, materials, stats, TOC, list laws, lookup, batch lookup, search, and generic resources. No significant overlap.
Most tools follow a 'legal_verb_noun' pattern. The exceptions are 'list_resources' and 'read_resource', which are generic MCP tools but break the prefix consistency.
11 tools cover all essential legal research tasks without being excessive. The count is well-scoped for the domain.
The tool surface covers discovery, lookup, citation analysis, legislative history, and search. No obvious gaps for a read-only legal research server.
Available Tools
11 toolslegal_find_citing_decisionsFind Citing Court DecisionsARead-onlyIdempotentInspect
List German federal court decisions (BGH, BVerwG, BFH, BAG, BSG, BVerfG, BPatG, GmSOGB), German state court decisions (Sächsisches OVG, Oberverwaltungsgericht NRW, Oberlandesgericht Düsseldorf, Oberlandesgericht Hamm, Oberlandesgericht Köln, Landesarbeitsgericht Düsseldorf, Landesarbeitsgericht Hamm, Landesarbeitsgericht Köln, Landessozialgericht NRW, Finanzgericht Düsseldorf, Finanzgericht Köln, Finanzgericht Münster, Verfassungsgerichtshof NRW) and EU court decisions (EuGH, EuG) citing a specific legal provision — the raw citation INVENTORY, newest first. 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'. 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. |
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 and idempotentHint, but description adds rich context: paragraph-level matching, return fields (Leitsatz, ECLI, cited_norms array), resolution behavior for EU instruments, and how to walk citation graph via legal_lookup. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is long but well-structured: front-loaded with purpose and sibling distinction, then behavioral details, then resolution mechanics. Each sentence adds value, though could be slightly more concise. Loses a point for verbosity.
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 (many court types, EU law, output schema exists), description fully covers return format, how to use results, and edge cases like EU instrument aliasing. No gaps remain.
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?
Both parameters (limit, cited_norm) have detailed explanations in description beyond schema. For cited_norm, gives examples, explains EU directive vs. transposition norm usage, and mentions resolution behavior. Schema coverage is 100%.
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 states specific verb 'List' and resource 'German federal court decisions ... citing a specific legal provision', and distinguishes from sibling 'legal_search' by explicitly contrasting the use case: raw citation inventory vs. relevance-ranked results.
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 when-to-use vs. alternatives: 'For decisions relevant to a specific question or fact pattern, use legal_search with the cited_norm filter instead.' Also gives guidance on preferring transposition norm over directive article for German case law.
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', 'nrw_rechtsprechung', 'bayern_gesetze', 'nrw_gesetze', or 'verwaltungsvorschriften'. 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 declare readOnlyHint=true and idempotentHint=true, so safety is covered. The description adds value by noting 'Paginated for large laws' and that results are in document order, which are useful behavioral traits beyond 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 efficient sentences: purpose, usage, and pagination note. No fluff, front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what is returned (norm keys, titles, chapter headings) and mentions pagination. With a few parameters and good schema, this is sufficiently complete for a read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented. The description adds minimal extra meaning beyond the schema, only implicitly referencing law_abbreviation. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the table of contents of a specific law or court decision' and specifies the return value (norm keys, titles, chapter headings). It differentiates from siblings by referencing legal_get_context as a next step.
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 directs to pass norm_id to legal_get_context, providing clear when-to-use and chaining guidance.
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', 'nrw_rechtsprechung', 'bayern_gesetze', 'nrw_gesetze', or 'verwaltungsvorschriften'. | |
| 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 indicate read-only and idempotent. Description adds that unfiltered listings can be large, warns about search pitfalls. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: purpose, behavior note, usage guidance, warnings. Every sentence adds value without redundancy. Appropriate length.
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 output schema present and all parameters described in schema, the description covers necessary context: purpose, usage, behavioral traits, and limitations.
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 has 100% coverage with descriptions for all 7 parameters. Description provides minor extra guidance (example search terms, filter advice) but does not significantly enhance parameter understanding beyond 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 lists available laws, regulations, and court decisions, specifying return fields. It distinguishes from siblings by noting it's for discovering abbreviations, not for existence checks.
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 advises when to use (discovering abbreviations, browsing corpus) and when not to (existence check). Recommends alternatives like legal_get_toc, legal_lookup, legal_search. Suggests filters to manage large results.
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, 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), 'sachsen_rechtsprechung' (Saxon OVG decisions), 'nrw_rechtsprechung' (NRW higher-court decisions: OVG/OLG/LAG/LSG/FG/VerfGH), 'bayern_gesetze' (Bavaria), 'nrw_gesetze' (North Rhine-Westphalia), 'verwaltungsvorschriften' (federal administrative regulations, e.g. TA Luft, BMGVwV), 'gesetzesmaterialien' (legislative materials — Gesetzesbegründung from Bundestag Drucksachen, the legislator's intent behind a federal norm; the corpus includes draft bills that never became law. Materials appear ONLY when explicitly requested via this value or document_kind='explanatory_memorandum' — an unfiltered search never returns them). Leave empty for cross-source search. | |
| 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?
Adds value beyond annotations by explaining that document_kind filter classes merge norm subtypes, decision restricts to case law, explanatory_memorandum is opt-in, and that DE/EN are separate corpora. Mentions resource links for disambiguation. 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?
Well-structured with a clear opening, parameter guidance, and a 'COMMON PITFALLS' section. However, it is lengthy due to detailed bilingual instructions and extensive examples. Could be slightly more concise without losing essential 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?
Covers all major use cases, filter interactions, and edge cases. References external resources (legal://filter_values, legal://rechtsrahmen) for further help. With output schema existing, the description is fully adequate for a complex search tool with 13 parameters.
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 every parameter with contextual meaning: query format, document_kind filter behavior (non-discriminating norm class), law_abbreviation/document_kind reconciliation, cited_norm citation-graph explanation, source_type/jurisdiction mapping, and decision_type exclusions.
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 'Search legal documents across jurisdictions' using hybrid search, returns snippets not full text. It distinguishes from siblings like legal_find_citing_decisions and legal_get_materials by mentioning them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Extensive guidance on when to use filters (document_kind, source_type, etc.), when to leave empty (e.g., mixed questions), how to rephrase queries, and common pitfalls for law abbreviations. It also tells when to use alternatives (legal_find_citing_decisions, legal_get_materials).
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!