Skip to main content
Glama
Sign In
German Legal MCP Server

German Legal MCP Server

by metaneutrons
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

eul_get_document

Retrieve EU legislation by CELEX number from the EU Publications Office as Markdown, with optional section extraction or file export for legal research and document processing.

Instructions

Retrieve EU legislation by CELEX number (e.g., "32016R0679" for GDPR, "32024R1689" for the AI Act) from the EU Publications Office (Cellar). A CELEX beginning with the sector digit (3…) returns the act as published in the Official Journal, without later amendments. For the consolidated text use the leading 0 instead: "02024R1689" returns the latest consolidated version in force, "02024R1689-20240712" a specific one; consolidated texts are documentation, not the binding text. Returns full text in Markdown. Use section for partial content: "Art. 5", "Artikel 5-10", "Anhang III", "Kapitel III", "Kapitel III Abschnitt 2", or "lines:100-200". save_path is for export only — when the user wants the document as a file to keep or process elsewhere.

Input Schema

NameRequiredDescriptionDefault
celexYesCELEX number (e.g., "32016R0679", "32001L0029", "12016E267"; consolidated: "02016R0679" or "02016R0679-20160504")
sectionNoExtract section: "Art. 5", "Artikel 5-10", "Anhang III" (also "Annex 3"), "Kapitel III" (with all its sections), "Kapitel III Abschnitt 2", or "lines:100-200"
languageYesLanguage code (default: DE)DE
save_pathNoAbsolute file path for the full document. Relative paths are not supported.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv4.1.1
    • changedInput schema / properties / celex / description
      Previous value: -"CELEX number (e.g., \"32016R0679\", \"32001L0029\", \"12016E267\")"New value: +"CELEX number (e.g., \"32016R0679\", \"32001L0029\", \"12016E267\"; consolidated: \"02016R0679\" or \"02016R0679-20160504\")"
    • changedInput schema / properties / section / description
      Previous value: -"Extract section: \"Art. 5\", \"Artikel 5-10\", \"Kapitel III\", or \"lines:100-200\""New value: +"Extract section: \"Art. 5\", \"Artikel 5-10\", \"Anhang III\" (also \"Annex 3\"), \"Kapitel III\" (with all its sections), \"Kapitel III Abschnitt 2\", or \"lines:100-200\""
  2. Addedv4.0.0

TDQS

A4.7/5.0
Behavior4/5

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

With no annotations provided, the description carries the behavioral burden well: it discloses the return format (Markdown), explains that consolidated texts are documentation rather than binding law, and clarifies that `save_path` is export-only. It does not cover auth, rate limits, or error behavior, but for a document-retrieval tool the core behavior is clearly disclosed.

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?

The description is dense but front-loaded: the core purpose comes first, followed by CELEX variants, section extraction, and export semantics. Every sentence contributes domain-specific guidance and nothing is redundant.

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?

There is no output schema, so the description must explain return behavior; it does so by stating full text is returned in Markdown and describing partial extraction via `section`. Combined with CELEX and export guidance, it is complete enough for an agent to call the tool correctly.

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 coverage is 100%, so the baseline is 3. The description adds real meaning beyond the schema by explaining CELEX sector semantics, consolidated identifiers, and the export-only role of `save_path`, which helps an agent choose parameter values correctly.

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 states a specific verb and resource: retrieve EU legislation by CELEX number from the EU Publications Office. It distinguishes the CELEX sector forms and consolidated vs Official Journal texts, so an agent can understand exactly what this tool returns.

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?

It gives explicit guidance on when to use a sector-3 CELEX versus a leading-0 consolidated CELEX, when to use `section` for partial extraction, and when `save_path` is appropriate for export. This is concrete routing and usage guidance, not implied context.

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

Deploy Server

Other Tools