Skip to main content
Glama
nulegal-startup

recht-mcp

by nulegal-startup
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

List citing decisions

listCitingDecisions
Read-onlyIdempotent

Find court decisions that cite a given statute provision or case. Enter a law and reference (e.g., DSGVO § 83) or a case identifier to retrieve ranked citing rulings.

Instructions

Incoming citation edges. Give EITHER law + ref (which decisions apply this statute provision) OR case (which decisions cite this decision) — exactly one of the two.

Results are ranked by citation weight, then court tier, then recency. Read the ranking honestly: for a provision with many EU decisions the first ten can be almost all CJEU, and the German courts appear only further down. If total exceeds what you read, page on with offset (pagination.next_offset) before concluding anything about national case law.

NEWEST FIRST: pass sort: "recent" when the question is about current case law ('fünf aktuelle Entscheidungen zu …'). Paging works the same way. This ordering is bounded — for a handful of procedural giants (§ 154 VwGO, § 708 ZPO) it cannot be computed inside the query budget, and then the answer comes back in WEIGHT order and says so in sort_applied and sort_note. Check sort_applied before you describe a list as the most recent decisions.

For a decision, each citer carries citing_rn: the Randnummer of the CITING decision's own text that holds the citation, as that court numbered it, and the URL is anchored to it.

COVERAGE: the graph is built over federal case law. A Land provision can answer total: 0 because it is not indexed, not because no court has cited it — coverage.complete_for_this_norm tells you which, and for a Land provision you should fall back to search on the provision's wording.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
lawNo
refNo
caseNoA juris doknr, an ECLI, or this site's decision URL as `search` returns it.
sortNo'weight' (default) is citation weight, then court tier, then recency. 'recent' is newest decision first; where it cannot be computed the answer falls back to 'weight' and says so in `sort_applied`.weight
limitNo
offsetNoRows to skip, for reading past the first page.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description's added context is valuable. It discloses ranking internals (weight → court tier → recency), coverage gaps (Land provisions may yield total:0 even when cited), the bounded nature of 'recent' ordering with fallback to weight, and the meaning of citing_rn. None of this contradicts the annotations.

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

Conciseness4/5

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

The description is lengthy but well-structured into clear paragraphs (core modes, ranking, sorting, coverage). Every sentence adds operational value, and key constraints (exactly one mode, check sort_applied) are front-loaded. It could be trimmed slightly, but the density is justified for a tool with this complexity.

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?

For a tool with no output schema, the description covers all critical call-time knowledge: how to select parameters, ranking order, pagination, coverage limitations, and the citing_rn anchor. It explains edge cases like procedural giants and Land provisions, so an agent can call it correctly and interpret results without additional lookups.

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 description coverage is 50% (case, sort, offset have descriptions; law, ref, limit do not). The description clarifies the required pairing of law+ref and the alternative case, explains sorting behavior and pagination via offset, and adds the coverage caveat. While the schema already documents sort and offset, the description adds contextual meaning beyond the raw field definitions, compensating for the half without schema descriptions.

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 purpose: listing incoming citation edges, with two mutually exclusive query modes (law+ref or case). It clearly distinguishes itself from siblings like listCitedAuthorities by focusing on incoming edges, and explicitly requires exactly one of the two modes, preventing ambiguity.

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 when-to-use guidance: the law+ref mode for statute provisions, case mode for decisions, and when to pass sort:"recent" for current case law. It also names a fallback to the `search` sibling for Land provisions, and instructs checking `sort_applied` before drawing conclusions. No exclusions are left implicit.

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