Global law

Search changes

search_changes

Read-onlyIdempotent

Search the record of changes (each commit message: the law, its dates, what it did) rather than the text of the law. For example "temporary", "COVID", "Bundesrat". With start and end, the changes in force from start to end, both days included.

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_changes"
  }
}

Input Schema

Name	Required	Description
`end`	No	The latest in-force date to include, YYYY-MM-DD or "today". Defaults to no end, so changes not yet in force are included.
`kind`	No	laws (default; "law" is read the same): law only. judgments: court decisions (case law) only. all: both. A jurisdiction that names case law (a path ending in /caselaw) reads it too.
`query`	Yes	Words to look for in the change notes, as plain text; upper and lower case match alike.
`start`	No	The earliest in-force date to include, YYYY-MM-DD. Defaults to the start of the record.
`offset`	No	Rows to skip: the next_offset the answer before gave in "page" (default 0).
`max_results`	No	At most this many (default 30, at most 200).
`jurisdiction`	No	Optional jurisdiction prefix, for example "germany", "united-states/federal" or "united-kingdom/uk/legislation/uksi".

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedNov 10, 2026

changedInput schema / properties / end / description

Previous value: -"An in-force date, YYYY-MM-DD, or \"today\". Defaults to today."New value: +"The latest in-force date to include, YYYY-MM-DD or \"today\". Defaults to no end, so changes not yet in force are included."

changedInput schema / properties / kind / description

Previous value: -"law (default): bodies of law only. judgments: court decisions (case law) only. Case law is also read when the jurisdiction names it (a path ending in /caselaw)."New value: +"laws (default; \"law\" is read the same): law only. judgments: court decisions (case law) only. all: both. A jurisdiction that names case law (a path ending in /caselaw) reads it too."

changedInput schema / properties / kind / enum

Previous value: -[
-  "law",
-  "judgments"
-]New value: +[
+  "laws",
+  "judgments",
+  "all",
+  "law"
+]

changedInput schema / properties / max_results / description

Previous value: -"At most this many (default 30)."New value: +"At most this many (default 30, at most 200)."

addedInput schema / properties / offset

Added value: +{
+  "description": "Rows to skip: the next_offset the answer before gave in \"page\" (default 0).",
+  "type": "integer"
+}

addedInput schema / properties / query / description

Added value: +"Words to look for in the change notes, as plain text; upper and lower case match alike."

changedInput schema / properties / start / description

Previous value: -"An in-force date, YYYY-MM-DD, or \"today\". Defaults to today."New value: +"The earliest in-force date to include, YYYY-MM-DD. Defaults to the start of the record."

First observedNov 10, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely useful behavior beyond that: what a change record consists of and that start/end filter on in-force dates with both endpoints included, which materially affects results. It stops short of describing pagination or result ordering.

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?

Three short sentences, front-loaded with the core distinction between change notes and law text. The final sentence ("With start and end, the changes in force from start to end, both days included") is slightly circular and could be tightened, but nothing is wasted.

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 an output schema, full schema coverage, and annotations present, the description only needs to explain scope and date semantics, which it does. The one gap is that it never relates itself to the similarly named changes_between sibling, leaving an agent to infer the split.

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 coverage is 100%, so the schema already documents all seven parameters including date formats, defaults, and the next_offset pagination contract. The description adds only the inclusivity of the start/end range ("both days included") and the in-force framing, which is a marginal but real clarification. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ("Search the record of changes") and immediately qualifies what the record contains ("each commit message: the law, its dates, what it did"), then explicitly contrasts it with searching law text, which is what search_law does. An agent can distinguish this from search_law without opening either schema.

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

Usage Guidelines4/5

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

Clear context for use: search change notes rather than law text, with concrete example queries ("temporary", "COVID", "Bundesrat"). It does not name the close sibling changes_between or state when to prefer that over this, so the alternative routing is only implicit.

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

All Global law 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.