PRIMAMCP

List Available Laws

legal_list_laws

Read-onlyIdempotent

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; legal_get_toc shows a listed law's structure.

Not an existence check for a specific law: EUR-Lex entries store the official long title, so a short name or number can miss a law that is in the corpus. legal_lookup with a citation or legal_search with a topic is the existence check.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Max results per page (default 50).
`offset`	No	Start position for pagination.
`search`	No	Case-insensitive search on abbreviation, title and official short designation ('Elektronischer-Rechtsverkehr-Verordnung'), e.g. 'bgb', 'datenschutz'. Also accepts a CELEX number ('32022L2555') or an EU instrument reference ('2022/2555', 'Richtlinie (EU) 2022/2555') and resolves it to the stored law.
`language`	No	Corpus language: 'de' (default — the full German + EU corpus) or 'en' (English-language corpus: currently EDPB/EDSA data-protection guidance only; much smaller than 'de'). DE and EN are separate corpora — a document published in both languages has one entry per language under the same abbreviation. 'en' selects the English corpus regardless of the answer language; 'edsa' is published mostly in English.
`source_type`	No	Filter: 'gii', 'eurlex', 'eurlex_caselaw', 'rechtsprechung', 'bverfge', 'bverwg', 'sachsen_rechtsprechung', 'nrw_rechtsprechung', 'bayern_gesetze', 'nrw_gesetze', 'verwaltungsvorschriften', 'edsa', 'dsk' or 'gesetzesmaterialien'. Note: 'edsa' is published mostly in English: language='en' covers the full set, the DE default only the translated documents.
`jurisdiction`	No	Filter by jurisdiction: 'de' (all German law — matches federal AND state law; for federal only use source_type='gii'), 'eu', 'de_by' (Bavaria only), 'de_nw' (North Rhine-Westphalia only), 'de_sn' (Saxony only). Leave empty for all jurisdictions.
`document_kind`	No	Filter by document class: the norm subtypes 'statute', 'regulation' and 'directive' form ONE class (any of them lists all three); 'decision' (court case-law), 'guidance' (supervisory-authority soft law, EDSA/DSK) and 'explanatory_memorandum' (legislative materials) are separate classes.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 8, 2026

changedInput schema / properties / language / description

Previous value: -"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."New value: +"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. 'en' selects the English corpus regardless of the answer language; 'edsa' is published mostly in English."

changedInput schema / properties / source_type / description

Previous value: -"Filter: 'gii', 'eurlex', 'eurlex_caselaw', 'rechtsprechung', 'bverfge', 'bverwg', 'sachsen_rechtsprechung', 'nrw_rechtsprechung', 'bayern_gesetze', 'nrw_gesetze', 'verwaltungsvorschriften', 'edsa', 'dsk' or 'gesetzesmaterialien'. Note: 'edsa' is published mostly in English — pair it with language='en', or the DE default leaves you only the few translated documents."New value: +"Filter: 'gii', 'eurlex', 'eurlex_caselaw', 'rechtsprechung', 'bverfge', 'bverwg', 'sachsen_rechtsprechung', 'nrw_rechtsprechung', 'bayern_gesetze', 'nrw_gesetze', 'verwaltungsvorschriften', 'edsa', 'dsk' or 'gesetzesmaterialien'. Note: 'edsa' is published mostly in English: language='en' covers the full set, the DE default only the translated documents."

First observedSep 8, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds meaningful behavioral context: unfiltered results can contain thousands of entries, and EUR-Lex stores official long titles so short names/numbers may miss existing laws. These caveats go beyond structured fields and help the agent set expectations.

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 tightly written paragraphs: first states the core function, second gives filtering and sibling-tool guidance, third clarifies edge-case behavior. Every sentence earns its place and important caveats are front-loaded near the top.

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?

Given the tool's complexity (7 parameters, rich enums), the schema descriptions cover parameter semantics, annotations cover safety/idempotency, an output schema exists, and the description covers purpose, filters, caveats, and alternatives. Nothing essential for correct selection or invocation is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description adds a practical recommendation to pass a search term or source_type for focused responses, but it does not add new semantics for individual parameters beyond what the detailed schema already provides.

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-resource pair ('List available laws, regulations, and court decisions') and states the exact fields returned per entry. It clearly differentiates itself from siblings by naming legal_get_toc for structure and legal_lookup/legal_search 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.

Usage Guidelines5/5

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

Provides explicit guidance: use this tool to discover valid law abbreviations for legal_search, use legal_get_toc for a listed law's structure, and use legal_lookup/legal_search as the existence check for a specific law. It also advises passing a search term or source_type to handle unfiltered listings.

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

All PRIMAMCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.