Open Legal Data (Germany)

Search laws

search_laws

Read-onlyIdempotent

Full-text search across law sections via Elasticsearch.

    Returns matching law sections with highlighted snippets. Does NOT
    return full text - use get_law_section to retrieve the complete
    content of a specific section.

    Args:
        query: Search query text (supports Lucene syntax).
        book_code: Optional filter by law book code, any case (e.g.
            "BGB", "BranntwMonG"). An unknown code returns an error
            with ``suggestions`` instead of an empty result.
        limit: Maximum results (default 10, max 50). Values above 50 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_laws"
  }
}

Input Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavior: snippet-only responses, unknown book_code yielding an error with suggestions, and limit clamping that sets limit_clamped and echoes requested_limit. Only the exact response shape (total counts, pagination) is left unstated, which keeps it just under a 5.

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 capability and the snippet-vs-full-text caveat are front-loaded, and the Args block is compact. Some of the limit default/max restates schema defaults, but that redundancy is defensible given 0% schema coverage; the prose is otherwise waste-free.

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?

With no output schema, the description still explains what comes back (matching sections with highlighted snippets, error suggestions, limit_clamped). It stops short of describing result ordering or any total-count field, which would be the remaining piece for a search tool, but an agent has enough to call it correctly.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries the full burden and does so for all three parameters: query supports Lucene syntax, book_code is case-insensitive and errors with suggestions on unknown values, and limit defaults to 10, caps at 50, and is clamped with a flag. This meaningfully exceeds the bare type/default declarations in the 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?

States a specific verb and resource ('Full-text search across law sections via Elasticsearch') and immediately distinguishes itself from get_law_section by declaring it returns only highlighted snippets, not full text. An agent can tell from the first sentence what this tool does and what it does not.

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?

Explicitly names the when-not ('Does NOT return full text') and the alternative to use instead ('use get_law_section to retrieve the complete content'). It also gives a usage rule for book_code: an unknown code produces an error with suggestions rather than an empty result, so the agent knows how to react to a miss.

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.