Open Legal Data (Germany)

Search laws and court decisions

search_legal

Read-onlyIdempotent

Search BOTH legislation and court cases in one call.

    Returns the most relevant law sections AND court decisions for the
    query, **grouped by type**. Use this when a legal question may be
    answered by statute or by case law and you don't yet know which —
    e.g. "ortsübliche Vergleichsmiete" surfaces § 558 BGB *and* BGH
    decisions together. For type-specific control (citation filters,
    court/date filters), use ``search_cases`` / ``search_laws``.

    Matching is on the words of the text: a law section is found only
    if it contains the query terms. Colloquial terms that the statute
    doesn't use (e.g. "Eigenbedarf"; § 573 BGB says "die Räume als
    Wohnung für sich ... benötigt") find case law but not that section.
    Then search with the statute's wording, or read the cases' cited
    sections via ``get_case_references``.

    Results are grouped rather than merged into one ranked list on
    purpose: court decisions are long and out-score short statute
    texts on relevance, so a naive merged ranking returns only cases
    and buries the on-point law.

    Args:
        query: Search query text (supports Lucene syntax and "phrases").
        limit: Max results per type (default 5, max 25). Values above 25
            are clamped; the response then includes ``limit_clamped:
            true`` and the original ``requested_limit``.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "search_legal"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No
`query`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: it discloses that results are grouped by type rather than merged and explains why (long decisions out-rank short statutes and would bury on-point law), plus the exact-match token behavior that causes colloquial terms to miss statute sections. It also documents the limit-clamping contract, including the limit_clamped and requested_limit fields returned in that case.

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?

Front-loaded with the core purpose and the routing decision, then progressively deeper detail on matching quirks and arguments. The paragraph justifying grouped output is genuinely useful context but is longer than strictly needed, and the parenthetical example inside the routing sentence is dense.

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 two-parameter, read-only search tool with no output schema, the description covers purpose, routing, matching semantics, result shape (grouped by type), and the clamping contract. There is nothing an agent needs in order to select and call this correctly that is missing.

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 0%, so the description must carry both parameters, and it largely does: query is described as supporting Lucene syntax and quoted phrases, and limit has a default of 5, a max of 25, and clamp behavior with a visible response flag. Only minor gaps remain (no note on whether limit applies per type — though 'per type' is implied earlier — or on empty-result behavior).

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?

States a specific verb (search) and a precise, dual resource (legislation AND court cases in one call), and explicitly contrasts itself with type-specific siblings search_cases / search_laws. An agent can distinguish it from the sibling pair without opening any schema.

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?

Gives an explicit when-to-use condition ('a legal question may be answered by statute or by case law and you don't yet know which'), an example query, and an explicit routing rule to search_cases / search_laws when citation, court, or date filters are needed. It also advises the fallback path (re-search with statutory wording, or get_case_references) when a colloquial term misses a statute.

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

All Open Legal Data (Germany) 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.