STRIDE

get_changes

Read-onlyIdempotent

What changes the law across the whole corpus in a window of dates: what has entered into force, started applying, been replaced by a new version or reached a deadline in the last months, and what will in the next ones. Each event says whether it is an entry into force or an application, and its act's position on as_at. Window with since/until or last_months/next_months (left out: the last 6 and the next 12 months, echoed); filter by kind, jurisdiction (eu, uk), subject_matter or instrument (regulation, directive, decision). Paged by cursor, with the total and the coverage: how many acts have no resolved date, are held, or are not indexed yet. answerable is false when too much of the scope is not indexed yet for the list to be read as complete: an empty list is then not "nothing changes". A uk-only query is read on London's legal day. Answers "what starts applying in the next 12 months" and "what changed in the last 6".

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_changes"
  }
}

Input Schema

Name	Required	Description
`as_at`	No	The day to read the position on, YYYY-MM-DD. Left out, it is the act's legal day today (Brussels for EU law, London for UK law). It is always echoed back.
`kinds`	No	Only these kinds of event. Leave out for all.
`limit`	No
`since`	No	First day of the window, YYYY-MM-DD.
`until`	No	Last day of the window, YYYY-MM-DD.
`cursor`	No	next_cursor from the previous page.
`instrument`	No
`last_months`	No
`next_months`	No
`jurisdiction`	No
`subject_matter`	No	A subject matter label, e.g. 'data protection'.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 3, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well past the readOnly/idempotent annotations: cursor pagination with totals, a coverage report (unresolved dates, held acts, unindexed acts), an `answerable` flag warning that an empty list may mean incomplete indexing, and the timezone convention for UK-only queries. These are exactly the caveats an agent needs before treating results as complete.

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, then window mechanics, then filters, then paging/coverage caveats. Dense and somewhat run-on with heavy parentheticals, but essentially every clause carries information; only the closing answer examples are mildly redundant with earlier text.

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 an 11-parameter, no-required-argument query tool with no output schema, the description covers windows, filters, paging, defaults, timezone handling and the completeness signal. Nothing an agent needs to interpret results correctly (especially the `answerable` trap) is missing.

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 coverage is only 55%, and the description compensates: it explains that since/until and last_months/next_months are alternatives with defaults of 6 and 12 months, that defaults are echoed, what the kind and jurisdiction/instrument filters accept, and how as_at anchors the position. Several undescribed schema parameters (last_months, next_months, instrument, jurisdiction) gain meaning here.

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 – surfacing legal-change events (entry into force, application, replacement, deadline) across the whole corpus within a date window. The 'whole corpus' scope implicitly sets it apart from the per-act sibling get_timeline and from get_legislation, so an agent can tell what it returns without opening the 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?

Gives concrete usage contexts ('what starts applying in the next 12 months', 'what changed in the last 6') plus default windows and filter options. It does not explicitly name an alternative tool or say when to prefer get_timeline or get_legislation, so routing is implied rather than stated.

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

All STRIDE 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?