de-eli-mcp

de_search

Read-onlyIdempotent

Search and retrieve German federal legislation from NeuRIS, providing official ELI identifiers and citations for legal verification.

Instructions

Search German federal legislation in NeuRIS.

Maps to GET /v1/legislation. Each item gets eli_uri, human_readable_citation, source_url (per Art. 4 CONSTITUTION).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`query`	Yes	``SearchQuery`` - search_term, eli, date_from/to, temporal_coverage_from/to, size (1..300), page_index, sort.

Output Schema

TableJSON Schema

Name	Required	Default
`items`	No
`query_echo`	No
`total_items`	Yes
`dataset_note`	No	NeuRIS is a beta service and its dataset is not yet complete. For exhaustive research cross-check gesetze-im-internet.de / rechtsprechung-im-internet.de.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.2Jul 14, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds endpoint mapping and returned fields, providing moderate additional context but no behavioral surprises.

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?

Two sentences: first states purpose, second maps endpoint and key return fields. No wasted words; front-loaded with core information.

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

Completeness4/5

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

Given complexity (nested object, many parameters) and rich schema/annotations, the description is adequate. Missing pagination or sorting details but schema covers those.

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 schema documents parameters well. Tool description adds no further parameter explanation beyond stating what fields are returned, which is already in the output 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?

Describes the tool as 'Search German federal legislation in NeuRIS', a specific verb+resource. Differentiates from siblings like de_case_search by specifying 'legislation' vs. case law.

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

Usage Guidelines3/5

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

Implies use for German federal legislation but no explicit when-to-use, when-not-to-use, or alternative tools mentioned. Lacks guidance beyond scope.

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

Deploy Server