Skip to main content
Glama

Ansvar: EU Compliance & Legal Intelligence

Get Changes

get_changes
Read-only

Find observed rows from legislative change feeds in a jurisdiction or framework, or from an explicit source. Use this for questions such as 'what laws changed in Sweden this month' only when the requested scope is listed as amendment-capable. If since is omitted, the gateway defaults to the last 90 days. Coverage is per corpus. The EU Regulations source is baseline-only during the current interim: it is excluded from amendment-capable dispatch, and a framework it owns is advertised only if another reachable feed supports that framework. A successful empty response is not evidence that no amendments occurred. On a capability miss, the response names supported source, framework, and jurisdiction scopes — or, when no corpus advertises change feeds at all, says so explicitly with supported_scopes empty on every axis. Every dispatched response reports whether baseline rows were actually withheld and whether the producer supplied typed event metadata. Legacy rows without typed event metadata remain visible with event_kind unknown. A scope value that names nothing we serve is refused, not ignored: the call errors and names the value, never returning changes for only the part that resolved. Use diff for a known provision. Boundary: this tool reports amendments observed in SERVED corpus text; for newly published official acts and regulator announcements (what is new, not what changed in a text we serve), use search_regulatory_updates. The response ends with a 'Sources used' section — a markdown table carrying the audit receipt for each returned row, or a labelled zero-result note — and meta.render_contract carries the versioned evidence-curation contract for reproducing source attributions when the answer is rendered.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum change entries per source (default 20; values above 50 are clamped; total entries can reach limit × resolved sources).
sinceNoEarliest change date to report, as an ISO date, e.g. '2026-01-01'. Empty defaults to the last 90 days.
sourcesNoExact corpus source ids to read change feeds from, such as swedish-law.
frameworksNoRegistered framework scope ids such as GDPR or NIS2, restricted to frameworks a reachable change feed supports.
regulationNoNarrow the feed to one instrument by name, such as 'GDPR'. Optional; leave empty for every instrument in scope.
jurisdictionsNoISO-2 jurisdiction scope codes such as SE or EU. Only scopes a corpus advertises as amendment-capable are dispatched; a capability miss names the supported scopes.
regulation_idNoNarrow the feed to one instrument by the corpus's own identifier (e.g. a CELEX number). Optional alternative to regulation.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. Changed6 schema fields changed
    • addedInput schema / properties / frameworks / description
      Added value: +"Registered framework scope ids such as GDPR or NIS2, restricted to frameworks a reachable change feed supports."
    • addedInput schema / properties / jurisdictions / description
      Added value: +"ISO-2 jurisdiction scope codes such as SE or EU. Only scopes a corpus advertises as amendment-capable are dispatched; a capability miss names the supported scopes."
    • addedInput schema / properties / regulation / description
      Added value: +"Narrow the feed to one instrument by name, such as 'GDPR'. Optional; leave empty for every instrument in scope."
    • addedInput schema / properties / regulation_id / description
      Added value: +"Narrow the feed to one instrument by the corpus's own identifier (e.g. a CELEX number). Optional alternative to regulation."
    • addedInput schema / properties / since / description
      Added value: +"Earliest change date to report, as an ISO date, e.g. '2026-01-01'. Empty defaults to the last 90 days."
    • addedInput schema / properties / sources / description
      Added value: +"Exact corpus source ids to read change feeds from, such as swedish-law."
  4. First observed

TDQS

A4.5/5.0
Behavior5/5

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

The description goes well beyond the readOnly/destructive annotations by disclosing important runtime behaviors: empty responses are not evidence of no amendments, capability misses name supported scopes, responses include a 'Sources used' section, and meta.render_contract carries the evidence-curation contract.

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

Conciseness2/5

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

The description is overly verbose and repetitive, with long clauses and duplicated concepts like capability-miss behavior and source attribution. It would benefit from tighter structuring and shorter sentences.

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?

Given the absence of an output schema, the description supplies important output context including the 'Sources used' markdown table, zero-result note behavior, and the render_contract field, making it reasonably complete for correct invocation.

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?

The input schema already covers 100% of parameters, and the description adds useful operational nuances such as limit clamping, per-corpus coverage, amendment-capable dispatch for jurisdictions, and the regulation/regulation_id alternative.

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 clearly states the tool 'find[s] observed rows from legislative change feeds' and distinguishes it from related tools such as diff and search_regulatory_updates, making the purpose and boundaries explicit.

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?

It provides explicit when-to-use guidance with examples like 'what laws changed in Sweden this month', specifies the amendment-capable scope condition, and tells the agent to use diff for known provisions and search_regulatory_updates for newly published acts.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.