Lawbster

Look Up Multiple Provisions

legal_lookup_batch

Read-onlyIdempotent

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.

Input Schema

TableJSON Schema

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

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds valuable context: exact matches only, citations not found appear as found=false, and a 1-20 citation count limit. These details go beyond the annotations without contradicting them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences: purpose, constraints with examples, and alternative usage. Every sentence earns its place with no redundancy or filler. The structure is front-loaded and scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is straightforward, output schema exists, and the description covers batch-size limits, exact-match behavior, not-found reporting, and the relationship to the sibling tool. Nothing essential is missing for correct selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema descriptions cover 100% of parameters, so baseline is 3. The description enhances this by giving concrete example citation strings and clarifying that court-decision references are accepted in the same form as legal_lookup, which is not fully explicit in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Look up full text of multiple legal provisions in a single call (exact match).' This clearly distinguishes it from the individual legal_lookup sibling and communicates the batch scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly provides an alternative: 'For fuzzy matching of hard-to-find provisions, use individual legal_lookup.' This gives a clear when-not condition and directs the agent to the correct sibling for fuzzy needs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Lawbster tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation5/5

Each legal tool targets a distinct operation: finding citing decisions, retrieving context, legislative history, stats, TOC, law lists, and exact lookups. The batch lookup is clearly a convenience wrapper for the single lookup, and the generic resource tools are unmistakably separate from the legal research functions.

Naming Consistency5/5

All legal tools follow a consistent 'legal_' prefix plus verb_noun pattern (e.g., legal_find_citing_decisions, legal_get_context, legal_list_laws). The two generic MCP tools also follow verb_noun (list_resources, read_resource), maintaining overall consistency.

Tool Count5/5

With 11 tools, the server is well-scoped for a comprehensive legal research domain. Each tool provides a distinct capability, and none feels redundant or excessive. The count is within the ideal 3-15 range.

Completeness4/5

The tool set covers the core legal research lifecycle: discovery (list_laws, search), lookup (lookup, lookup_batch), citation analysis (find_citing_decisions), structural navigation (get_toc, get_context), and legislative intent (get_materials). Minor gaps exist, such as the lack of coverage for certain state court decisions and non-German legislative materials, but these are explicitly documented and workarounds are provided.

Resources

Need Help?