LawDB

Search Provisions Tool

search_provisions

Read-onlyIdempotent

Searches inside one legislative act and returns the provisions that match — with marker, heading, an excerpt of the wording and the lawdb.eu link.

Use this whenever a question is about what a named act says: "does the BGB say anything about Übereignung?", "which provision of the GDPR governs consent?". search_legal_documents ranks whole documents and is dominated by case law for such questions; this tool works section by section.

Name the act however you have it: its curated short name ("BGB", "DSGVO"), its official abbreviation, or the id of a search result, an ELI or a CELEX number. Read the full wording of a hit with get_provision, passing back the act and the marker from the result.

Every matching provision of the act is available, not just the best few: total reports how many there are, and next_offset — present whenever more remain — goes back as offset for the next page. Where search_legal_documents shows at most three provisions per act, this is the tool that finds all of them ("Bienenschwarm" is § 961 to § 964 BGB).

The match is literal: the words you pass are compared against the wording, without stemming, inflection or synonyms. "Zuständigkeit" does not find "zuständig". Search the shortest distinctive word, not a full phrase, and vary the wording if nothing comes back.

Consolidated EU acts are held as one continuous text rather than as separately addressable articles. For those, act.structured_provisions is false and the results carry the article heading a passage sits under instead of a marker — quote it, but do not pass it to get_provision.

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": {
      "act": "<act>",
      "query": "<query>"
    },
    "name": "search_provisions"
  }
}

Input Schema

Name	Required	Description
`act`	Yes	The act: a short name such as "BGB" or "DSGVO", the `id` of a search result, an ELI or a CELEX number.
`limit`	No	Maximum number of provisions per page.
`query`	Yes	What to look for in the act — a term, a phrase or a provision heading.
`offset`	No	Skip this many provisions. Pass back the `next_offset` of the previous page.
`language`	No	ISO 639-1 code of the desired language version. Defaults to German, then English.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A4.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint and idempotentHint, so safety and repeatability are covered upstream; the description earns credit for what they cannot say — literal, non-stemmed matching ("Zuständigkeit" will not find "zuständig"), exhaustive rather than top-3 coverage, and pagination via `total`/`next_offset`. It also discloses the structural exception where consolidated EU acts expose a `heading` instead of a `marker`. The remaining gap is the response envelope itself, but with no output schema the field-level description largely compensates.

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 purpose and scope, then alternatives, then operational caveats — a sensible ordering across six short paragraphs. It is on the long side and repeats the exhaustiveness point twice (the general statement about all matches and the later "at most three provisions per act" contrast), though the parenthetical bee-swarm example does usefully anchor it.

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?

No output schema exists, so the description has to carry the return shape, and it does: marker, heading, excerpt, link, plus `total` and `next_offset` for paging. It also covers the non-obvious edge case of unstructured consolidated EU acts, which is exactly the kind of trap that would otherwise cause a bad follow-up call to `get_provision`.

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 a 3 would be the floor, but the description adds real meaning the schema lacks: the `act` parameter accepts a curated short name, official abbreviation, search-result `id`, ELI or CELEX number, and the `query` guidance recommends the shortest distinctive word rather than a full phrase and warns that varying wording is the fix for empty results. `offset` is tied to feeding back `next_offset`, which clarifies intent beyond the generic schema text.

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?

Opens with a specific verb and scope: searching inside one named legislative act for matching provisions, and lists the returned fields (marker, heading, excerpt, lawdb.eu link). It also draws an explicit line against siblings: `search_legal_documents` ranks whole documents and is case-law dominated, while `get_provision` reads full wording. An agent can route correctly without consulting 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 concrete when-to-use framing with realistic example questions ("does the BGB say anything about Übereignung?") and names the alternative that is wrong for this job. It also states the follow-up step explicitly: read a hit with `get_provision`, passing back `act` and `marker`, and warns not to pass an article `heading` from unstructured EU acts to `get_provision`.

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

All LawDB 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.

Resources

Need Help?