STRIDE

get_timeline

Read-onlyIdempotent

Every dated event of one act, past and future, each classified: entry_into_force and application (kept apart, with their scope: the whole act, a staged tranche or a set of provisions), deadline (an obligation due date inside the act, never a state of any provision), transposition_deadline (directives; the subject is member_states), new_version (a change in the words, with the consolidated version), end_of_validity, and proposal (labelled proposed, never law). Each event states its date, kind, axis, subject and reach, scope, source, whether its date is held, and when it falls relative to as_at. The act's position (status and whom it is about) on as_at comes with it, with the coverage of what we hold. Answers "what is the full dated history and future of this act".

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": {
      "celex_id": "<celex_id>"
    },
    "name": "get_timeline"
  }
}

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.
`since`	No	Only events on or after this date.
`until`	No	Only events on or before this date.
`celex_id`	Yes	The act: a CELEX ID, Lex-Ray ID or nickname (e.g., '32024R1689', 'ai act').
`include_proposals`	No	Include in-flight proposals to amend the act, labelled proposed.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 3, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already cover the read-only, idempotent safety profile, so the description is free to add the substantive behavior: proposals are labelled proposed and 'never law', deadlines are obligations 'never a state of any provision', and the response includes the act's position on as_at plus 'the coverage of what we hold'. That last point usefully signals possible gaps in data completeness.

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

Conciseness3/5

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

The scope statement is front-loaded, but the middle sentences are dense run-ons — the parenthetical about entry_into_force scope and the long 'Each event states...' enumeration take effort to parse. The content is largely justified given there is no output schema, but the phrasing could be tighter.

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?

With no output schema available, the description carries the return-value burden and does so thoroughly, enumerating event fields (date, kind, axis, subject, reach, scope, source, date-held flag, relative position to as_at) and the accompanying act position. Nothing material is missing for an agent to call it correctly.

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 description coverage is 100%, so each parameter is already documented, and the description mostly mirrors that. It does add indirect meaning by tying include_proposals to the 'proposal' event class and as_at to the returned 'position', but no date syntax or filtering interaction between since/until and as_at is clarified.

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 — 'Every dated event of one act, past and future' — and enumerates the event kinds returned (entry_into_force, application, deadline, transposition_deadline, new_version, end_of_validity, proposal). This is clearly distinguishable from siblings like get_changes and get_legislation, which lack the per-act full-history scope.

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

Usage Guidelines3/5

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

The closing line 'Answers "what is the full dated history and future of this act"' implies when to reach for it, but no sibling is named and no exclusion condition is stated. An agent must infer that get_changes or get_legislation are the alternatives for other questions.

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?