Payments Law EU
Server Details
Read-only query service for EU payments legislation: 51 curated instruments, by provision.
- Status
- Healthy
- Uptime
- 100.0% over 17 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
Scored across 14 tools
Each tool has a clearly distinct purpose: retrieval (fetch/get_provision), search (search/search_legislation), term handling (get_defined_term, search_defined_terms), version comparison (compare_versions, list_version_changes), and metadata inventory (list_instruments, list_provisions, get_instrument, get_source_notes, get_orientation, resolve_citation). Overlapping tools like fetch and get_provision are explicitly differentiated by capability, and guides steer users to the more comprehensive version when needed. No two tools appear to serve the same function.
All tools use snake_case with consistent verb-noun structure: get_* for direct retrieval, list_* for enumeration, search_* for searching, resolve_* for citation resolution, compare_* for diffing, and fetch for a simple retrieval. The naming pattern is predictable and aligns with the tool's action and target, with no mixed conventions or vague verbs.
With 14 tools, the server is well-scoped for its domain of EU payments legislation. The count supports comprehensive access—search, retrieval, term comparison, version diffs, and metadata—without unnecessary bloat. Each tool earns its place by covering a distinct aspect of the corpus, and the count fits comfortably within the ideal range for a specialized legal document server.
The tool surface covers the full lifecycle needed for this read-only legal corpus: discovery (list_instruments, list_provisions, search_legislation), citation resolution (resolve_citation), retrieval (fetch, get_provision), defined-term analysis (get_defined_term, search_defined_terms), version comparison (compare_versions, list_version_changes), and contextual guidance (get_orientation, get_source_notes, get_instrument). No obvious dead ends exist—every operation points to the next appropriate tool, and missing data (e.g., version_not_served) is handled transparently. The only potential gap is lack of a direct cross-reference tool, but get_provision's include_correspondences covers this adequately.
Available Tools
14 toolscompare_versionsCompare PSR or PSD3 article versionsARead-onlyIdempotentInspect
Use this to compare an article between the held Commission proposal and Council compromise versions of PSR or PSD3, within the same instrument. Serves the word-level comparison the build published: a pair is servable if and only if a diff artefact exists for it — the PSR and PSD3 proposal↔compromise pairs and nothing else. Every other pair, including every consolidated instrument's pinned as-adopted text, is refused with the URL where that text is published; this service never recomputes a comparison. Pairs match in either direction, and a reversed request is the same artefact with the ops inverted. changes reads that artefact structurally — paragraphs added or deleted, figures and durations moved, a heading rewritten — for a caller that needs what KIND of change this was without parsing the word-level ops. It is scoped to the article, not to the page of ops, and locates each entry no more precisely than the served text allows.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | ||
| to_locator | No | The article on the to side. | |
| from_locator | No | The article on the from side. Alignment is identity on the article number, so naming either side names both. | |
| instrument_id | Yes | Registry id of the instrument, e.g. "psr". | |
| to_version_id | Yes | Version id the other side. | |
| from_version_id | Yes | Version id one side of the pair. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| error | Yes | |
| coverage | Yes | |
| warnings | Yes | |
| pagination | Yes | |
| provenance | Yes | |
| derivations | Yes | |
| corpus_release | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnlyHint and idempotentHint annotations by disclosing that the service never recomputes comparisons, refuses unsupported pairs with the URL to published text, treats reversed requests as the same artefact with inverted ops, and reads changes structurally. This is rich behavioral context that an agent could not infer from annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core use case and then layers on precise behavioral constraints. It is dense and uses some domain jargon, but every sentence contributes meaningful information about scope, refusal behavior, or output interpretation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with this complexity, the description covers all critical behavioral aspects: which pairs work, which are refused, what happens on reversed requests, how the structural change reading works, and the precision boundary of locators. The presence of an output schema means return-value details do not need to be repeated here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 71%, and the schema already documents instrument_id, version IDs, and both locators in detail. The description adds useful context about directionality and pair validity, but it does not explain cursor or limit semantics, which are the undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action — compare an article between the held Commission proposal and Council compromise versions of PSR or PSD3 — and clearly delineates the resource scope. It distinguishes itself from siblings by naming the exact instrument types and pair types it serves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit servability conditions: a pair is servable if and only if a diff artefact exists, and only PSR/PSD3 proposal↔compromise pairs qualify. It also states that every other pair is refused, but it does not explicitly name an alternative sibling tool to use instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fetchRead EU legislative text (compatible)ARead-onlyIdempotentInspect
Use this to open and cite an EU legislative provision found by search. OpenAI-compatible retrieval: the full text of one provision by its cite anchor id (e.g. "psd-2 Art 97"), with citation metadata. Accepts only ids this service minted — free-text citations belong to resolve_citation. get_provision returns more: paging, applicability and typed warnings.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | An id from search, or a cite anchor such as "psd-2 Art 97" or "psd-2 Recital 12", or an instrument id such as "psd-2". An optional version qualifier, e.g. "psr (com-2023-367) Art 105", retains its edition and refuses unserved text. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| text | Yes | The legal text selected from the provision. Full referenced note bodies travel separately in metadata.source_notes; notes do not alter legal block counts or content_hash. |
| title | Yes | |
| metadata | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover readOnly/idempotent/openWorld, so the description's added value is the acceptance constraint ('only ids this service minted'), the edition-retention behavior visible in the schema, and the pointer to a richer sibling. It doesn't discuss failure modes like unknown ids, but the safety profile is already carried by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded purpose followed by a dense but earned retrieval/citation/routing cluster. Every clause contributes; the parenthetical example is the only mild padding since the schema repeats it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values needn't be explained, and the description correctly spends its budget on routing and input constraints. The one gap is that it doesn't state what happens on an invalid or foreign id beyond pointing at resolve_citation, leaving error behavior implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the id description already documents accepted anchor formats and the version-qualifier behavior. The description only adds the free-text exclusion, which is routing rather than parameter semantics, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('open and cite an EU legislative provision') and immediately distinguishes itself from siblings by naming search (upstream) and get_provision (the richer alternative). An agent can route between fetch, resolve_citation, and get_provision without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly ties use to output of 'search', excludes free-text citations by routing them to resolve_citation, and points to get_provision when paging/applicability/warnings are needed. This is textbook when/when-not/alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_defined_termRead and compare legal definitionsARead-onlyIdempotentInspect
Use this to read and compare the held legislative definitions of a term, such as payment transaction in PSD2 and PSR. These are source definitions, not a general dictionary or a legal opinion. Every definition verbatim and resolved, clustered by what the text actually says, with the chronological and concurrent views and word-level comparisons between them. Resolution follows the CITED version, never legislative succession: a definition citing a repealed act resolves to that act and is labelled repealed, not silently replaced by its successor's wording. A term the corpus does not define is refused with suggestions — nothing is substituted. references_in gives the reverse edges: which definitions lean on this one.
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | The defined term, as written in the legislation ("payment account"). Matched exactly after normalisation; a term the corpus does not define is refused with suggestions, never answered with a neighbouring one. | |
| view | No | Which text clusters and comparisons run on. "resolved" (default) follows each definition's pointers to its root; "verbatim" uses the text as each instrument prints it. | |
| on_date | No | ISO date. Adds operative_on_date and temporal_state_on_date per definer, and makes the concurrent view that date's rather than the release's. | |
| comparison | No | Which comparisons to compute. "adjacent" (default) compares consecutive distinct clusters in chronological order; {baseline: cluster_id} compares one cluster against every other; {pair: [cite, cite]} compares two named definitions; {concurrent_pairs: {}} compares every pair that was in force at once. | |
| instrument | No | Narrow the definitions listed to one definer. The clusters, views and comparisons stay corpus-wide: what the term means elsewhere does not change because you asked about one instrument. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| error | Yes | |
| coverage | Yes | |
| warnings | Yes | |
| pagination | Yes | |
| provenance | Yes | |
| derivations | Yes | |
| corpus_release | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint), the description discloses key resolution behavior: definitions follow the CITED version rather than legislative succession, repealed acts are labelled as such, undefined terms are refused with suggestions, and references_in provides reverse edges. This is substantive behavioral context that annotations alone do not supply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence serves a purpose: purpose, scope, output style, resolution semantics, refusal behavior, and a related output field. It is front-loaded with the core purpose and avoids filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the annotations, the fully documented schema, and an output schema, the description is complete. It explains subtle behavioral guarantees (cited-version resolution, refusal with suggestions) that an agent needs to call the tool correctly and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all parameters with detailed descriptions, so the baseline is 3. The tool description adds general context about resolved vs verbatim views and comparisons but does not add parameter-specific meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('read and compare') and resource ('held legislative definitions of a term'), giving a concrete example (payment transaction in PSD2 and PSR). It also distinguishes itself from a general dictionary or legal opinion, separating it from broader lookup tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening 'Use this to...' clearly frames the intended scenario, and the 'not a general dictionary or a legal opinion' phrasing sets boundaries. However, it does not explicitly name alternatives or state when to choose a sibling tool like search_defined_terms or compare_versions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_instrumentCheck EU instrument status and versionARead-onlyIdempotentInspect
Use this to check an EU instrument's recorded legal status, source version, dates and amendments, including whether a held PSR or PSD3 text is a proposal or compromise. Metadata, dates, lifecycle and application events, and curated relationships. Each relationship names the operative amending or repealing article where curated (openable with get_provision) and the counterpart's legal status at the release. An operative_cite can arrive without an operative_locator: the article is real but the served text has dropped it, and operative_locator_unavailable says so. An amender outside the corpus is named under source_external, whose via_article carries its article. No article index — use list_provisions. Pass on_date for the multi-axis applicability record on that date.
| Name | Required | Description | Default |
|---|---|---|---|
| on_date | No | ISO date; returns the full applicability record. | |
| instrument_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| error | Yes | |
| coverage | Yes | |
| warnings | Yes | |
| pagination | Yes | |
| provenance | Yes | |
| derivations | Yes | |
| corpus_release | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description adds substantial behavioral detail beyond that: relationships name operative amending/repealing articles, operative_cite can arrive without operative_locator, and source_external handles amenders outside the corpus. This is exactly the edge-case foresight an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is front-loaded and high-value, and the remaining text is dense with useful edge cases rather than filler. Some fragments, like 'Metadata, dates, lifecycle and application events, and curated relationships,' are telegraphic and could be smoother, but every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, idempotent lookup that has an output schema, the description provides the key response-shape caveats (missing locators, external amenders), optional date behavior, and the correct sibling for article-level navigation. An agent has enough context to invoke and interpret this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: only on_date is described in the schema, while instrument_id has no description. The description reinforces on_date as a 'multi-axis applicability record' and identifies the resource as an EU instrument, but it does not clarify the expected form or semantics of instrument_id itself, so it only partially compensates for the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('check') and resource ('EU instrument's recorded legal status, source version, dates and amendments'), and goes further by naming the exact context (PSR/PSD3 proposal vs compromise). It also distinguishes itself from siblings by explicitly directing article-index needs to list_provisions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Frames the tool's primary use directly ('Use this to check an EU instrument's...'), gives an alternative routing ('No article index — use list_provisions'), and notes that relationships are 'openable with get_provision'. It also tells when to pass the optional parameter: 'Pass on_date for the multi-axis applicability record on that date.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_orientationFind an EU payments reading pathwayARead-onlyIdempotentInspect
Use this for a starting reading order in EU payments legislation when a relevant curated pathway exists. For other subjects use search_legislation. Curated reading pathways into the corpus for a stated audience: ordered waypoints with cite anchors every other tool can open, related defined terms and known pitfalls. The prose is editorial and labelled as such — it maps the reading order, never legal weight. Omit the pathway argument for the catalogue; an unknown id is refused with the catalogue, nothing substituted. Catalogue entries and pathway waypoints paginate whole: follow pagination.next_cursor with the same pathway and limit until complete.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum catalogue entries or pathway waypoints per page; whole-item byte bounds may return fewer. | |
| cursor | No | pagination.next_cursor from this tool; repeat the same pathway and limit. | |
| pathway | No | Pathway id from the catalogue. Omit for the catalogue. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| error | Yes | |
| coverage | Yes | |
| warnings | Yes | |
| pagination | Yes | |
| provenance | Yes | |
| derivations | Yes | |
| corpus_release | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description explains the content shape (ordered waypoints, cite anchors, related defined terms, known pitfalls), the editorial non-legal nature of the prose, and safe pagination behavior. It also discloses failure semantics: an unknown id is refused with the catalogue, nothing substituted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence carries operational or conceptual weight: usage condition, alternative tool, output nature, catalogue behavior, and pagination contract. The description is dense but not padded, and the most important selection guidance is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description does not need to explain return values. It covers when to use the tool, how to identify curated pathways, how to avoid the legal-weight misunderstanding, and the complete pagination loop. No critical caller-facing gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by clarifying that an unknown pathway id is refused, that pagination must reuse the same pathway and limit, and that catalogue entries and waypoints paginate as whole items. These details help an agent invoke the parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific purpose: finding a starting reading order in EU payments legislation via curated pathways. It also names the broader catalogue behavior and explicitly differentiates from search_legislation, so an agent can distinguish this tool from its siblings without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit condition for use ('when a relevant curated pathway exists') and an explicit alternative ('For other subjects use search_legislation'). It also provides concrete operational guidance: omit the pathway argument for the catalogue, and treat unknown ids as refused rather than substituted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_provisionRead EU legislative provisionARead-onlyIdempotentInspect
Use this to read or quote an EU legislative provision, such as PSD2 Article 97 or RTS-SCA Article 5. Returns the source text of an article, annex or recital as markdown, with its cite anchor, provenance and text-state disclosure. Large provisions paginate by structural block — never truncated silently. version_id is optional: the service serves one text per instrument, and a pinned version id is refused with the URL where it is published. include_correspondences adds the cross-instrument article equivalences — what a PSR article is amended from, or which PSR articles carry a PSD2 article's obligation — each openable by a second call.
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | Continue a paginated provision. Bound to the release. | |
| locator | Yes | ||
| on_date | No | ISO date; returns the provision-level applicability view. | |
| version_id | No | Omit, or pass "current", for the served text. A pinned version id returns version_not_served with the URL where that text is published. | |
| instrument_id | Yes | Registry id of the instrument, e.g. "psd-2". | |
| include_correspondences | No | Off by default. When true, an article carries `correspondences[]`: the cross-instrument article equivalences the corpus publishes — which PSD2 article a PSR article is amended from, and, from the other side, which PSR articles carry a PSD2 article's obligation. Each entry names the counterpart's own `get_provision` locator, version and cite anchor, so it opens with a second call. The relationship vocabulary is the analysis layer's own — `amended_from`, `supersedes` — plus the mechanical inverses of the reverse view, `amended_into` and `superseded_by`. An annex or a recital carries an empty list: correspondences are article-level: a request narrowed to a paragraph or a point still receives the whole article's mappings, and says so in a warning. `null` means the release predates the mapping table, which is not the same as an article having none. Where the corpus records a mapping this service will not serve — a correlation-table entry numbered against a superseded draft, or a counterpart absent from the served text — the list omits it and a `correspondence_withheld` warning names the instrument and the reason, so an empty or short list is never silently under-claimed. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| error | Yes | |
| coverage | Yes | |
| warnings | Yes | |
| pagination | Yes | |
| provenance | Yes | |
| derivations | Yes | |
| corpus_release | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already declare readOnlyHint=true and idempotentHint=true, the description adds substantial non-obvious behavior: large provisions "paginate by structural block — never truncated silently," a pinned version_id "is refused with the URL where it is published," and the service serves "one text per instrument." For correspondences it discloses empty-vs-null semantics, article-level granularity with a warning on narrowed requests, and the correspondence_withheld condition so under-claiming is never silent. Nothing contradicts the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The prose is dense but every sentence carries a distinct behavioral fact, and the long include_correspondences passage earns its length by documenting withholding, null, and granularity edge cases. It is appropriately sized for a 6-parameter tool with nested objects, though the correspondences section could be tightened without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value documentation is not the description's job — and it still describes the markdown shape. All call-relevant behavior is covered: pagination guarantees, versioning/refusal policy, and correspondence edge cases. The only absence is explicit sibling routing, which is a minor gap against an otherwise complete definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 83%, so the schema already documents most parameters; the description compensates above that baseline for the two trickiest ones. version_id gains the "one text per instrument" rationale and refusal behavior, and include_correspondences gains its vocabulary, null-vs-empty meaning, and withholding rules. The locator sub-fields receive no extra description, but the schema covers them adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: "Use this to read or quote an EU legislative provision," with concrete examples (PSD2 Article 97, RTS-SCA Article 5) and the exact return payload (source text as markdown with cite anchor, provenance, and text-state disclosure). The single-provision scope distinguishes it from siblings such as list_provisions, get_instrument, and compare_versions without needing to open their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states when to call it ("Use this to read or quote an EU legislative provision") and coaches the iterative pattern — correspondence entries are "each openable by a second call." However, it never names explicit alternatives or when-not conditions (e.g., when to prefer search_legislation or list_provisions), so it falls short of the explicit routing a 5 requires.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_source_notesRead legislative source notesARead-onlyIdempotentInspect
Use this to read the original legislative footnotes and source-note bodies for a held instrument, including preamble and annex notes. Omit note_key for the paginated inventory; supply an exact returned key to retrieve one. Keys retain source scope because printed markers may repeat. This tool does not infer ownership by a provision. Historical versions return an explicit version_not_served link.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Notes per page, default 10; complete bodies are never truncated. | |
| cursor | No | Continue with the same arguments; bound to this corpus release. | |
| note_key | No | Exact key returned by this tool. Omit to list notes. Printed markers may be reused and are not necessarily unique keys. | |
| version_id | No | Omit or use current for the served version; pinned versions return an explicit version_not_served link. | |
| instrument_id | Yes | Registry instrument id. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| error | Yes | |
| coverage | Yes | |
| warnings | Yes | |
| pagination | Yes | |
| provenance | Yes | |
| derivations | Yes | |
| corpus_release | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent behavior, and the description adds non-obvious details: keys retain source scope because printed markers repeat, no ownership inference occurs, and historical versions return an explicit version_not_served link. These are valuable behavioral disclosures beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, each with a distinct job: purpose, pagination mode, key semantics, and version caveat. There is no filler or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and annotations covering read-only/idempotent semantics, the description sufficiently covers purpose, pagination, note_key usage, version behavior, and a known limitation. Nothing material is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description goes further by clarifying note_key semantics (omit for inventory, supply exact returned key, printed markers may repeat) and version_id behavior (historical versions return version_not_served link), adding genuine meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('read') and a specific resource ('original legislative footnotes and source-note bodies'), including preamble and annex notes. This clearly distinguishes it from sibling tools like get_provision, get_instrument, and search_legislation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage context: use for source notes of a held instrument, with two modes (paginated inventory vs. single note by exact key). It also adds an exclusion ('does not infer ownership by a provision'), though it does not explicitly name alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_instrumentsDiscover held EU legislationARead-onlyIdempotentInspect
Use this to discover which EU instruments are held before a coverage question, or find their registry ids and legal status. Paginated, filterable by status, category, core/supplementary, and by whether an instrument was in force on a given date. For corpus-coverage questions, filter by category here, enumerate each instrument with list_provisions, then open what you need with get_provision.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | ||
| status | No | Legal status at the release, e.g. "in_force". | |
| is_core | No | ||
| category | No | ||
| in_force_on_date | No | ISO date; keeps instruments in force on that date. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| error | Yes | |
| coverage | Yes | |
| warnings | Yes | |
| pagination | Yes | |
| provenance | Yes | |
| derivations | Yes | |
| corpus_release | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent behavior, so the description adds value by disclosing that the result is paginated and filterable by status, category, core/supplementary status, and in-force date. This enriches the agent's understanding of behavior beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core purpose, then filters, then a workflow. Every sentence earns its place and there is no redundant restatement of the tool name or title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-parameter, read-only listing tool with an output schema, the description covers purpose, filtering, pagination, and how to chain with related tools. It is missing some parameter-level detail, but the output schema and workflow guidance make it sufficiently complete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, so the description must compensate. It explains category, core/supplementary, status, and date filtering at a high level, but it does not clarify limit, cursor, or possible values for category and status beyond the schema's lone 'in_force' example. Useful but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'discover which EU instruments are held' and 'find their registry ids and legal status.' It clearly establishes the tool's role in the coverage workflow and distinguishes it from provision-level tools like list_provisions and get_provision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit context for use ('before a coverage question') and a concrete workflow: filter by category, use list_provisions, then get_provision. However, it does not explicitly say when not to use this tool or how it compares to searching siblings like search_legislation, so a small gap remains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_provisionsBrowse an instrument's provisionsARead-onlyIdempotentInspect
Use this to browse an EU instrument's article, annex or recital index, or enumerate its topic-tagged provisions for a coverage question. Metadata only: each item carries the exact locator get_provision accepts. Articles and annexes by default; pass kind=recital for recitals.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | ||
| limit | No | ||
| topic | No | ||
| cursor | No | ||
| chapter | No | ||
| instrument_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| error | Yes | |
| coverage | Yes | |
| warnings | Yes | |
| pagination | Yes | |
| provenance | Yes | |
| derivations | Yes | |
| corpus_release | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide read-only and idempotent hints; the description adds that results are metadata only, that articles/annexes are included by default, and that kind=recital is needed for recitals. This is meaningful behavioral context beyond annotations. It does not explain pagination/cursor semantics, but the output schema covers the return shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler, front-loading the purpose and then delivering defaults and related-tool context. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool returns, how to invoke common variants, and how it connects to get_provision, with an output schema supplying return details. Pagination and filtering (cursor/limit/chapter) are not spelled out, so an agent may need to infer standard semantics; otherwise sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are absent (0% coverage), so the description must carry the parameter documentation burden. It explains kind and its default and hints at topic via 'topic-tagged provisions', but leaves instrument_id format, chapter, limit, and cursor meaning/use undocumented. Self-descriptive names mitigate this somewhat, but the description does not fully compensate for the zero schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Uses an action verb 'browse' plus a concrete resource (EU instrument provisions), defines the scope (article, annex, recital index, topic-tagged provisions), and explicitly distinguishes itself from get_provision by noting each item carries the exact locator that tool accepts. This is specific enough for an agent to select it correctly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States the intended use case ('coverage question'), the default behavior ('Articles and annexes by default'), and the conditional for recitals ('pass kind=recital'). It also implicitly routes the agent: use this for metadata/indexing, then get_provision for the located provision. This gives clear directional guidance among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_version_changesBrowse PSR or PSD3 text changesARead-onlyIdempotentInspect
Use this to browse which articles changed between the held proposal and Council compromise versions of PSR or PSD3. For one article's wording changes use compare_versions. Across the instrument's two published texts, lists every aligned article with its classification, filterable by status, materiality and article range. The editorial materiality markers travel on every response whatever the filters, because they exist precisely where the mechanical classification does not show what matters — a re-scoped defined term changes articles whose text did not change at all. Classifications are mechanical, and the response says on what basis.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | ||
| status | No | One of the classification statuses, e.g. "amended_substantial". | |
| articles | No | Article-number range, in legal order. | |
| instrument_id | Yes | ||
| material_only | No | Keep only articles carrying an editorial materiality marker. | |
| to_version_id | No | ||
| from_version_id | No | Optional; where given, must name the published pair. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| error | Yes | |
| coverage | Yes | |
| warnings | Yes | |
| pagination | Yes | |
| provenance | Yes | |
| derivations | Yes | |
| corpus_release | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true), and the description adds non-obvious response behavior: 'editorial materiality markers travel on every response whatever the filters,' with a rationale for their existence. It also discloses that 'classifications are mechanical' and that the response states its basis, tempering expectations about classification reliability. This is meaningful context beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose is front-loaded in the first sentence, with sibling routing in the second. The materiality-marker explanation is lengthy but earns its place by disclosing non-obvious response behavior; the clause about 'a re-scoped defined term changes articles whose text did not change at all' is somewhat convoluted but substantively valuable. Every sentence has a job.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter tool with complex version-pair semantics and a nuanced classification concept, the description covers purpose, filters, response behavior, and classification reliability. An output schema exists, so return values need no description. The remaining gaps — pagination behavior and instrument_id format — are left to schema names and convention, which is acceptable at this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 4 of 8 parameters (status, articles, material_only, from_version_id) for 50% coverage. The description partially compensates by naming the filter dimensions ('status, materiality and article range') and framing the version pair as 'the instrument's two published texts,' but limit, cursor, to_version_id, and instrument_id gain no added semantics. The compensation is partial, so the score sits at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('browse') and resource ('articles changed between the held proposal and Council compromise versions of PSR or PSD3'), naming the instrument scope explicitly. It differentiates from its closest sibling: 'For one article's wording changes use compare_versions.' No ambiguity remains about what this tool is for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the primary use case ('browse which articles changed between the held proposal and Council compromise versions') and routes to the alternative with a clear condition ('For one article's wording changes use compare_versions'). The mention of filters ('status, materiality and article range') further tells the agent when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_citationResolve an EU legal citationARead-onlyIdempotentInspect
Use this to resolve a written EU legal citation, such as Article 97(1) PSD2, into an instrument and provision locator. For a topic rather than a citation, use search_legislation. Ranked candidates with ambiguity flagged and confidence stated: exact (instrument certain, provision found), strong (instrument certain, provision not verified or not named) or ambiguous (more than one reading). A citation of an instrument this corpus does not hold is named, with its CELEX and ELI, rather than guessed at.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | ||
| citation | Yes | A citation in any form a reader would write: "Article 97(1) PSD2", "Art. 5a of Regulation (EU) No 910/2014", a CELEX number, an ELI path, or a bare acronym. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| error | Yes | |
| coverage | Yes | |
| warnings | Yes | |
| pagination | Yes | |
| provenance | Yes | |
| derivations | Yes | |
| corpus_release | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only/idempotent annotations, the description discloses the ranked-candidate behavior, the three confidence tiers (exact/strong/ambiguous, with precise definitions), and the handling of citations for instruments outside the corpus: those are named with CELEX and ELI rather than guessed. This is substantial behavioral context not present in the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three dense sentences with no filler. The primary instruction and usage boundary come first, followed by output behavior and edge-case handling. Every sentence adds information that the schema and annotations do not already provide.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the read-only/idempotent annotations, an output schema, and a single required citation parameter, the description covers the key operational details: what inputs look like, how results are ranked and scored, how ambiguity is surfaced, and what happens for out-of-corpus citations. Nothing essential for calling this tool correctly appears to be missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the description does not explain the limit or cursor parameters. However, the central citation parameter is well illustrated with concrete forms, and the description ties the citation to the output semantics (instrument and provision locator). The two undocumented parameters are generic pagination controls whose purposes are largely self-evident, so the gap is minor.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a concrete verb and resource: 'resolve a written EU legal citation ... into an instrument and provision locator,' and gives a real example (Article 97(1) PSD2). It also distinguishes itself from search_legislation by stating that search_legislation handles topics rather than citations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool ('Use this to resolve a written EU legal citation') and when not to ('For a topic rather than a citation, use search_legislation'). This gives an agent a clear decision rule instead of leaving the alternative inference to sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchSearch EU payments legislation (compatible)ARead-onlyIdempotentInspect
Use this to find EU payments legislation on topics such as SCA, open banking and safeguarding in the held PSD2, RTS-SCA, PSD3/PSR and related instruments. OpenAI-compatible search: the top hits as {id, title, url}, where id is the cite anchor fetch accepts. For filters, snippets, scores and paging use search_legislation, which returns more.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | EU payments legislative terms or citation, e.g. "strong customer authentication", "safeguarding" or "Article 97 PSD2". |
Output Schema
| Name | Required | Description |
|---|---|---|
| results | Yes | Top hits, best first. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds useful detail about the return shape (id, title, url) and the meaning of id, going beyond the annotation baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundant content. The distinction from search_legislation is packed efficiently without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single well-described parameter and an output schema present, the description covers the essential behavior and return shape. It also points to the richer sibling tool for advanced needs, making it complete for its intended lightweight use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description already includes illustrative examples. The tool description reinforces the query semantics by listing relevant topics, adding modest value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('find') and resource ('EU payments legislation'), with concrete topic examples. Clearly distinguishes itself from search_legislation by indicating it returns simple top hits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly directs users to search_legislation for filters, snippets, scores, and paging, making the intended use case for this simpler search unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_defined_termsFind EU legislative definitionsARead-onlyIdempotentInspect
Use this to find which EU instruments define a legal term, such as payment transaction or payment account, and where their definitions differ. For definition wording use get_defined_term. A listing: term, definers and divergence flags, with no definition text. Matching is over the term itself, never the definition body. Divergence is judged on the RESOLVED text as well as the verbatim one, because several instruments defining a term by pointing at the same root agree, however differently their pointers read. Pass only_divergent to find where the corpus does not agree with itself.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | Term text to match. Matching is over the TERM only, never the definition body. Omit for the full alphabetical listing of every term the corpus defines. | |
| cursor | No | ||
| instrument | No | Keep only terms defined in this instrument, e.g. "psd-2". | |
| only_divergent | No | Keep only terms whose definers disagree — on the resolved text, the verbatim text, or both. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| error | Yes | |
| coverage | Yes | |
| warnings | Yes | |
| pagination | Yes | |
| provenance | Yes | |
| derivations | Yes | |
| corpus_release | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already declare readOnlyHint and idempotentHint, the description adds meaningful behavioral detail: no definition text is returned, matching is restricted to the term field, and divergence is judged on both resolved and verbatim text. The explanation about instruments pointing at the same root is valuable context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with purpose, then alternatives, output shape, matching behavior, and a key divergence nuance. Every sentence contributes unique information without repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations cover safety and idempotency, the description is sufficient for correct invocation. It states what the result contains, how matching works, how divergence is computed, and when to use only_divergent. No essential decision for the agent is left unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 60%, and the description reinforces the meanings of query and only_divergent, including the resolved-versus-verbatim nuance. It does not explain limit or cursor, but these are conventional pagination parameters and the schema provides partial descriptions for the main filters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'find which EU instruments define a legal term' and explicitly names the output as a listing with term, definers, and divergence flags. It also distinguishes itself from the sibling get_defined_term by saying 'For definition wording use get_defined_term.' This leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear use context, tells the agent when to prefer get_defined_term instead, and clarifies that matching is over the term only, never the definition body. It also instructs to 'Pass only_divergent' when looking for disagreement, giving an explicit condition for parameter use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_legislationFind EU payments requirementsARead-onlyIdempotentInspect
Use this to find EU legislative provisions on payment-services questions: strong customer authentication (SCA), dynamic linking, open banking, safeguarding and payment liability. The held corpus includes PSD2, RTS-SCA, PSD3/PSR and DORA. For exact wording use get_provision; for defined-term wording use get_defined_term. This searches held legislation, not national law or regulator guidance. Full-text search across articles, annexes and recitals, ranked in that order of authority. Every hit carries the exact locator get_provision accepts, its cite anchor, the matched passage and why it matched. A citation-shaped query resolves through the citation grammar first; instrument acronyms become ranking hints; initialisms of the corpus's defined terms are expanded. Absence of a result is not evidence that no relevant law exists. The matched passage is a snippet of at most 320 characters, not the provision: open the hit with get_provision before citing it, and echo the cite it serves. topic narrows these hits rather than widening them: a topic-tagged provision whose words the query misses is never reached, so a page of hits is not a sweep. For coverage questions ('everything on X', 'which instruments deal with Y') pick the instruments with list_instruments by category, enumerate each with list_provisions filtered by topic, then open them with get_provision.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Restrict to one source type. Articles, annexes and recitals are all searched by default, ranked in that order of authority. | |
| limit | No | ||
| query | Yes | EU legislative search terms, e.g. "strong customer authentication", "dynamic linking", "safeguarding" or "DORA ICT risk". Use words expected in the legal text, not an entire advice request. Quoted phrases are honoured; AND, OR and NOT are the only operators. A citation-shaped query ("Article 97(1) PSD2") is resolved through the citation grammar first. | |
| topic | No | Keep only provisions carrying this topic. | |
| cursor | No | ||
| instrument_id | No | Restrict to one instrument, e.g. "rts-sca". | |
| in_force_on_date | No | ISO date; keeps hits from instruments in force on that date, on the same semantics list_instruments uses. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| error | Yes | |
| coverage | Yes | |
| warnings | Yes | |
| pagination | Yes | |
| provenance | Yes | |
| derivations | Yes | |
| corpus_release | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent hints, and the description adds substantial behavioral context: ranking order of authority, snippet length cap of 320 characters, citation-grammar resolution, acronym expansion, and the fact that topic narrowing means hits are not a sweep. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence carries operational information, front-loading the purpose and corpus before caveats and alternative workflows. It uses one compact paragraph rather than burying key points in boilerplate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Coupled with an output schema and annotations, the description covers scope, result semantics, precise action on hits (open with get_provision, echo the cite), pitfalls, and alternative workflows for coverage questions. An agent has everything needed to invoke it correctly and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 71% schema coverage the schema already documents most parameters, and the description adds real value beyond it by explaining query behavior (citation-shaped queries, initialisms) and the crucial topic semantics: topic narrows rather than widens, so a missed provision is unreachable. Only minor parameters like limit and cursor are not elaborated, but their names make them self-evident.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific verb and resource ('find EU legislative provisions on payment-services questions') and enumerates the held corpus (PSD2, RTS-SCA, PSD3/PSR, DORA) and search surface (articles, annexes, recitals). It also differentiates from related tools by routing exact wording to get_provision and defined terms to get_defined_term, so an agent can select it unambiguously.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance and names concrete alternatives: use get_provision for exact wording, get_defined_term for defined terms, and a list_instruments/list_provisions/get_provision workflow for coverage questions. It also states exclusions ('not national law or regulator guidance') and warns that absence of a result is not evidence of absence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
12 tool updates
- Changed
compare_versions6 fields changed- removed
Input schema / properties / cursor / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / cursor / typeAdded value: +[ + "string", + "null" +] - changed
Input schema / properties / from_locator / anyOfPrevious value: -[ - { - "properties": { - "annex": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Annex number, roman or arabic (\"I\", \"1\"); omit for an instrument whose single annex is unnumbered." - }, - "article": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Article number as printed: \"97\", \"45a\", \"69-a\"." - }, - "kind": { - "description": "Which kind of provision the locator names.", - "enum": [ - "article", - "annex", - "recital" - ], - "type": "string" - }, - "paragraph": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Numbered paragraph within the article, e.g. \"2\"." - }, - "point": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Lettered point within the paragraph, e.g. \"b\"." - }, - "recital": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Recital number, e.g. \"95\"." - }, - "subpoint": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Sub-point within the point." - } - }, - "required": [ - "kind" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "properties": { + "annex": { + "description": "Annex number, roman or arabic (\"I\", \"1\"); omit for an instrument whose single annex is unnumbered.", + "type": [ + "string", + "null" + ] + }, + "article": { + "description": "Article number as printed: \"97\", \"45a\", \"69-a\".", + "type": [ + "string", + "null" + ] + }, + "kind": { + "description": "Which kind of provision the locator names.", + "enum": [ + "article", + "annex", + "recital" + ], + "type": "string" + }, + "paragraph": { + "description": "Numbered paragraph within the article, e.g. \"2\".", + "type": [ + "string", + "null" + ] + }, + "point": { + "description": "Lettered point within the paragraph, e.g. \"b\".", + "type": [ + "string", + "null" + ] + }, + "recital": { + "description": "Recital number, e.g. \"95\".", + "type": [ + "string", + "null" + ] + }, + "subpoint": { + "description": "Sub-point within the point.", + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "kind" + ], + "type": "object" + }, + { + "type": "null" + } +] - changed
Input schema / properties / to_locator / anyOfPrevious value: -[ - { - "properties": { - "annex": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Annex number, roman or arabic (\"I\", \"1\"); omit for an instrument whose single annex is unnumbered." - }, - "article": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Article number as printed: \"97\", \"45a\", \"69-a\"." - }, - "kind": { - "description": "Which kind of provision the locator names.", - "enum": [ - "article", - "annex", - "recital" - ], - "type": "string" - }, - "paragraph": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Numbered paragraph within the article, e.g. \"2\"." - }, - "point": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Lettered point within the paragraph, e.g. \"b\"." - }, - "recital": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Recital number, e.g. \"95\"." - }, - "subpoint": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Sub-point within the point." - } - }, - "required": [ - "kind" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "properties": { + "annex": { + "description": "Annex number, roman or arabic (\"I\", \"1\"); omit for an instrument whose single annex is unnumbered.", + "type": [ + "string", + "null" + ] + }, + "article": { + "description": "Article number as printed: \"97\", \"45a\", \"69-a\".", + "type": [ + "string", + "null" + ] + }, + "kind": { + "description": "Which kind of provision the locator names.", + "enum": [ + "article", + "annex", + "recital" + ], + "type": "string" + }, + "paragraph": { + "description": "Numbered paragraph within the article, e.g. \"2\".", + "type": [ + "string", + "null" + ] + }, + "point": { + "description": "Lettered point within the paragraph, e.g. \"b\".", + "type": [ + "string", + "null" + ] + }, + "recital": { + "description": "Recital number, e.g. \"95\".", + "type": [ + "string", + "null" + ] + }, + "subpoint": { + "description": "Sub-point within the point.", + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "kind" + ], + "type": "object" + }, + { + "type": "null" + } +] - changed
Output schema / properties / data / anyOfPrevious value: -[ - { - "additionalProperties": {}, - "properties": { - "article": { - "type": "string" - }, - "changes": { - "anyOf": [ - { - "items": { - "additionalProperties": {}, - "properties": { - "type": { - "type": "string" - } - }, - "required": [ - "type" - ], - "type": "object" - }, - "type": "array" - }, - { - "type": "null" - } - ], - "description": "What KIND of change this comparison evidences, read off the same artefact as pairs[]. Types: paragraph_added, paragraph_deleted, paragraph_amended (with words_changed, counting both sides of a substitution), figure_changed (with from/to quoting the served text), heading_changed, the article_* counterparts of the first three for an article's text outside any numbered paragraph, and none_detected where nothing was found — never an empty list. An entry carries `paragraph` and, where the served text settles it, `point` and `subpoint`, in the §7 locator model's own field names; an article_* entry carries none of them. Those components are a CITATION, not a promise of retrieval: a sub-point is often not a block get_provision serves, so open an entry at the enclosing point, and then the paragraph, which does serve the text the entry quotes. A roman sub-point is always qualified by its letter point (PSR Art 97(2)(a)(ii), never (ii) alone), and a list the text does not settle is left unlocated. ARTICLE-SCOPED, not page-scoped: the whole inventory travels with every page of pairs[], so a client paging through must not concatenate it. Repeated identical entries are repeated occurrences in one paragraph, not duplicates. Null means this release predates the inventory, which is not the same as none_detected." - }, - "cite": { - "type": "string" - }, - "classification_note": { - "type": "string" - }, - "direction": { - "type": "string" - }, - "editorial_review_state": { - "type": "string" - }, - "from": { - "additionalProperties": {}, - "properties": { - "version_id": { - "type": "string" - } - }, - "required": [ - "version_id" - ], - "type": "object" - }, - "instrument_id": { - "type": "string" - }, - "pairs": { - "items": { - "additionalProperties": {}, - "properties": { - "ops": { - "items": { - "prefixItems": [ - { - "type": "string" - }, - { - "type": "string" - } - ], - "type": "array" - }, - "type": "array" - } - }, - "required": [ - "ops" - ], - "type": "object" - }, - "type": "array" - }, - "status": { - "type": "string" - }, - "to": { - "additionalProperties": {}, - "properties": { - "version_id": { - "type": "string" - } - }, - "required": [ - "version_id" - ], - "type": "object" - } - }, - "required": [ - "instrument_id", - "article", - "cite", - "from", - "to", - "status", - "direction", - "editorial_review_state", - "classification_note", - "changes", - "pairs" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": {}, + "properties": { + "article": { + "type": "string" + }, + "changes": { + "anyOf": [ + { + "items": { + "additionalProperties": {}, + "properties": { + "type": { + "type": "string" + } + }, + "required": [ + "type" + ], + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } + ], + "description": "What KIND of change this comparison evidences, read off the same artefact as pairs[]. Types: paragraph_added, paragraph_deleted, paragraph_amended (with words_changed, counting both sides of a substitution), figure_changed (with from/to quoting the served text), heading_changed, the article_* counterparts of the first three for an article's text outside any numbered paragraph, and none_detected where nothing was found — never an empty list. An entry carries `paragraph` and, where the served text settles it, `point` and `subpoint`, in the §7 locator model's own field names; an article_* entry carries none of them. Those components are a CITATION, not a promise of retrieval: a sub-point is often not a block get_provision serves, so open an entry at the enclosing point, and then the paragraph, which does serve the text the entry quotes. A roman sub-point is always qualified by its letter point (PSR Art 97(2)(a)(ii), never (ii) alone), and a list the text does not settle is left unlocated. ARTICLE-SCOPED, not page-scoped: the whole inventory travels with every page of pairs[], so a client paging through must not concatenate it. Repeated identical entries are repeated occurrences in one paragraph, not duplicates. Null means this release predates the inventory, which is not the same as none_detected." + }, + "cite": { + "type": "string" + }, + "classification_note": { + "type": "string" + }, + "direction": { + "type": "string" + }, + "editorial_review_state": { + "type": "string" + }, + "from": { + "additionalProperties": {}, + "properties": { + "version_id": { + "type": "string" + } + }, + "required": [ + "version_id" + ], + "type": "object" + }, + "instrument_id": { + "type": "string" + }, + "pairs": { + "items": { + "additionalProperties": {}, + "properties": { + "ops": { + "items": { + "items": false, + "maxItems": 2, + "minItems": 2, + "prefixItems": [ + { + "type": "string" + }, + { + "type": "string" + } + ], + "type": "array" + }, + "type": "array" + } + }, + "required": [ + "ops" + ], + "type": "object" + }, + "type": "array" + }, + "status": { + "type": "string" + }, + "to": { + "additionalProperties": {}, + "properties": { + "version_id": { + "type": "string" + } + }, + "required": [ + "version_id" + ], + "type": "object" + } + }, + "required": [ + "instrument_id", + "article", + "cite", + "from", + "to", + "status", + "direction", + "editorial_review_state", + "classification_note", + "changes", + "pairs" + ], + "type": "object" + }, + { + "type": "null" + } +] - changed
Output schema / properties / pagination / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "complete": { - "type": "boolean" - }, - "next_cursor": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "total": { - "type": "number" - } - }, - "required": [ - "complete", - "next_cursor" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "complete": { + "type": "boolean" + }, + "next_cursor": { + "type": [ + "string", + "null" + ] + }, + "total": { + "type": "number" + } + }, + "required": [ + "complete", + "next_cursor" + ], + "type": "object" + }, + { + "type": "null" + } +]
- Changed
get_defined_term7 fields changed- changed
Input schema / properties / comparison / anyOfPrevious value: -[ - { - "anyOf": [ - { - "const": "adjacent", - "type": "string" - }, - { - "properties": { - "baseline": { - "type": "string" - } - }, - "required": [ - "baseline" - ], - "type": "object" - }, - { - "properties": { - "pair": { - "prefixItems": [ - { - "type": "string" - }, - { - "type": "string" - } - ], - "type": "array" - } - }, - "required": [ - "pair" - ], - "type": "object" - }, - { - "properties": { - "concurrent_pairs": { - "properties": { - "cursor": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - } - }, - "type": "object" - } - }, - "required": [ - "concurrent_pairs" - ], - "type": "object" - } - ] - }, - { - "type": "null" - } -]New value: +[ + { + "anyOf": [ + { + "const": "adjacent", + "type": "string" + }, + { + "properties": { + "baseline": { + "type": "string" + } + }, + "required": [ + "baseline" + ], + "type": "object" + }, + { + "properties": { + "pair": { + "items": false, + "maxItems": 2, + "minItems": 2, + "prefixItems": [ + { + "type": "string" + }, + { + "type": "string" + } + ], + "type": "array" + } + }, + "required": [ + "pair" + ], + "type": "object" + }, + { + "properties": { + "concurrent_pairs": { + "properties": { + "cursor": { + "type": [ + "string", + "null" + ] + } + }, + "type": "object" + } + }, + "required": [ + "concurrent_pairs" + ], + "type": "object" + } + ] + }, + { + "type": "null" + } +] - removed
Input schema / properties / instrument / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / instrument / typeAdded value: +[ + "string", + "null" +] - removed
Input schema / properties / on_date / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / on_date / typeAdded value: +[ + "string", + "null" +] - changed
Output schema / properties / data / anyOfPrevious value: -[ - { - "additionalProperties": {}, - "properties": { - "clusters": { - "items": { - "additionalProperties": {}, - "properties": { - "cluster_id": { - "type": "string" - }, - "member_cites": { - "items": { - "type": "string" - }, - "type": "array" - } - }, - "required": [ - "cluster_id", - "member_cites" - ], - "type": "object" - }, - "type": "array" - }, - "comparisons": { - "items": { - "additionalProperties": {}, - "properties": { - "from_cite": { - "type": "string" - }, - "ops": { - "anyOf": [ - { - "items": { - "prefixItems": [ - { - "type": "string" - }, - { - "type": "string" - } - ], - "type": "array" - }, - "type": "array" - }, - { - "type": "null" - } - ] - }, - "to_cite": { - "type": "string" - } - }, - "required": [ - "from_cite", - "to_cite", - "ops" - ], - "type": "object" - }, - "type": "array" - }, - "definitions": { - "items": { - "additionalProperties": {}, - "properties": { - "cite": { - "type": "string" - }, - "defined_within": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "instrument_id": { - "type": "string" - }, - "qualifier": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "resolution_status": { - "type": "string" - }, - "resolved_definition": { - "type": "string" - }, - "verbatim_definition": { - "type": "string" - } - }, - "required": [ - "instrument_id", - "qualifier", - "defined_within", - "cite", - "verbatim_definition", - "resolved_definition", - "resolution_status" - ], - "type": "object" - }, - "type": "array" - }, - "references_in": { - "items": { - "additionalProperties": {}, - "properties": { - "cite": { - "type": "string" - }, - "instrument_id": { - "type": "string" - } - }, - "required": [ - "instrument_id", - "cite" - ], - "type": "object" - }, - "type": "array" - }, - "term": { - "type": "string" - }, - "view": { - "type": "string" - }, - "views": { - "additionalProperties": {}, - "properties": { - "concurrent": { - "items": { - "additionalProperties": {}, - "properties": { - "cite": { - "type": "string" - } - }, - "required": [ - "cite" - ], - "type": "object" - }, - "type": "array" - }, - "evolution": { - "items": { - "additionalProperties": {}, - "properties": { - "cite": { - "type": "string" - } - }, - "required": [ - "cite" - ], - "type": "object" - }, - "type": "array" - } - }, - "required": [ - "evolution", - "concurrent" - ], - "type": "object" - } - }, - "required": [ - "term", - "view", - "definitions", - "clusters", - "views", - "comparisons", - "references_in" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": {}, + "properties": { + "clusters": { + "items": { + "additionalProperties": {}, + "properties": { + "cluster_id": { + "type": "string" + }, + "member_cites": { + "items": { + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "cluster_id", + "member_cites" + ], + "type": "object" + }, + "type": "array" + }, + "comparisons": { + "items": { + "additionalProperties": {}, + "properties": { + "from_cite": { + "type": "string" + }, + "ops": { + "anyOf": [ + { + "items": { + "items": false, + "maxItems": 2, + "minItems": 2, + "prefixItems": [ + { + "type": "string" + }, + { + "type": "string" + } + ], + "type": "array" + }, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "to_cite": { + "type": "string" + } + }, + "required": [ + "from_cite", + "to_cite", + "ops" + ], + "type": "object" + }, + "type": "array" + }, + "definitions": { + "items": { + "additionalProperties": {}, + "properties": { + "cite": { + "type": "string" + }, + "defined_within": { + "type": [ + "string", + "null" + ] + }, + "instrument_id": { + "type": "string" + }, + "qualifier": { + "type": [ + "string", + "null" + ] + }, + "resolution_status": { + "type": "string" + }, + "resolved_definition": { + "type": "string" + }, + "verbatim_definition": { + "type": "string" + } + }, + "required": [ + "instrument_id", + "qualifier", + "defined_within", + "cite", + "verbatim_definition", + "resolved_definition", + "resolution_status" + ], + "type": "object" + }, + "type": "array" + }, + "references_in": { + "items": { + "additionalProperties": {}, + "properties": { + "cite": { + "type": "string" + }, + "instrument_id": { + "type": "string" + } + }, + "required": [ + "instrument_id", + "cite" + ], + "type": "object" + }, + "type": "array" + }, + "term": { + "type": "string" + }, + "view": { + "type": "string" + }, + "views": { + "additionalProperties": {}, + "properties": { + "concurrent": { + "items": { + "additionalProperties": {}, + "properties": { + "cite": { + "type": "string" + } + }, + "required": [ + "cite" + ], + "type": "object" + }, + "type": "array" + }, + "evolution": { + "items": { + "additionalProperties": {}, + "properties": { + "cite": { + "type": "string" + } + }, + "required": [ + "cite" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "evolution", + "concurrent" + ], + "type": "object" + } + }, + "required": [ + "term", + "view", + "definitions", + "clusters", + "views", + "comparisons", + "references_in" + ], + "type": "object" + }, + { + "type": "null" + } +] - changed
Output schema / properties / pagination / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "complete": { - "type": "boolean" - }, - "next_cursor": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "total": { - "type": "number" - } - }, - "required": [ - "complete", - "next_cursor" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "complete": { + "type": "boolean" + }, + "next_cursor": { + "type": [ + "string", + "null" + ] + }, + "total": { + "type": "number" + } + }, + "required": [ + "complete", + "next_cursor" + ], + "type": "object" + }, + { + "type": "null" + } +]
- Changed
get_instrument4 fields changed- removed
Input schema / properties / on_date / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / on_date / typeAdded value: +[ + "string", + "null" +] - changed
Output schema / properties / data / anyOfPrevious value: -[ - { - "additionalProperties": {}, - "properties": { - "instrument_id": { - "type": "string" - }, - "legal_status_at_release": { - "type": "string" - }, - "relationships": { - "anyOf": [ - { - "items": { - "additionalProperties": {}, - "properties": { - "direction": { - "type": "string" - }, - "kind": { - "type": "string" - }, - "operative_cite": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "operative_locator": { - "anyOf": [ - { - "additionalProperties": {}, - "properties": { - "article": { - "type": "string" - }, - "instrument_id": { - "type": "string" - }, - "kind": { - "type": "string" - } - }, - "required": [ - "instrument_id", - "kind", - "article" - ], - "type": "object" - }, - { - "type": "null" - } - ] - }, - "operative_locator_unavailable": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "source_external": { - "anyOf": [ - { - "additionalProperties": {}, - "properties": { - "celex": { - "type": "string" - }, - "title": { - "type": "string" - }, - "via_article": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - } - }, - "required": [ - "celex", - "title", - "via_article" - ], - "type": "object" - }, - { - "type": "null" - } - ] - }, - "target_external": { - "anyOf": [ - { - "additionalProperties": {}, - "properties": { - "celex": { - "type": "string" - }, - "title": { - "type": "string" - } - }, - "required": [ - "celex", - "title" - ], - "type": "object" - }, - { - "type": "null" - } - ] - }, - "target_instrument_id": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "target_status": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - } - }, - "required": [ - "kind", - "direction", - "target_status", - "operative_locator", - "operative_cite", - "operative_locator_unavailable" - ], - "type": "object" - }, - "type": "array" - }, - { - "type": "null" - } - ] - }, - "text_state": { - "type": "string" - }, - "title": { - "type": "string" - }, - "url": { - "type": "string" - }, - "version_id": { - "type": "string" - } - }, - "required": [ - "instrument_id", - "title", - "legal_status_at_release", - "version_id", - "text_state", - "url", - "relationships" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": {}, + "properties": { + "instrument_id": { + "type": "string" + }, + "legal_status_at_release": { + "type": "string" + }, + "relationships": { + "anyOf": [ + { + "items": { + "additionalProperties": {}, + "properties": { + "direction": { + "type": "string" + }, + "kind": { + "type": "string" + }, + "operative_cite": { + "type": [ + "string", + "null" + ] + }, + "operative_locator": { + "anyOf": [ + { + "additionalProperties": {}, + "properties": { + "article": { + "type": "string" + }, + "instrument_id": { + "type": "string" + }, + "kind": { + "type": "string" + } + }, + "required": [ + "instrument_id", + "kind", + "article" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "operative_locator_unavailable": { + "type": [ + "string", + "null" + ] + }, + "source_external": { + "anyOf": [ + { + "additionalProperties": {}, + "properties": { + "celex": { + "type": "string" + }, + "title": { + "type": "string" + }, + "via_article": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "celex", + "title", + "via_article" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "target_external": { + "anyOf": [ + { + "additionalProperties": {}, + "properties": { + "celex": { + "type": "string" + }, + "title": { + "type": "string" + } + }, + "required": [ + "celex", + "title" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "target_instrument_id": { + "type": [ + "string", + "null" + ] + }, + "target_status": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "kind", + "direction", + "target_status", + "operative_locator", + "operative_cite", + "operative_locator_unavailable" + ], + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "text_state": { + "type": "string" + }, + "title": { + "type": "string" + }, + "url": { + "type": "string" + }, + "version_id": { + "type": "string" + } + }, + "required": [ + "instrument_id", + "title", + "legal_status_at_release", + "version_id", + "text_state", + "url", + "relationships" + ], + "type": "object" + }, + { + "type": "null" + } +] - changed
Output schema / properties / pagination / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "complete": { - "type": "boolean" - }, - "next_cursor": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "total": { - "type": "number" - } - }, - "required": [ - "complete", - "next_cursor" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "complete": { + "type": "boolean" + }, + "next_cursor": { + "type": [ + "string", + "null" + ] + }, + "total": { + "type": "number" + } + }, + "required": [ + "complete", + "next_cursor" + ], + "type": "object" + }, + { + "type": "null" + } +]
- Changed
get_orientation6 fields changed- removed
Input schema / properties / cursor / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / cursor / typeAdded value: +[ + "string", + "null" +] - removed
Input schema / properties / pathway / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / pathway / typeAdded value: +[ + "string", + "null" +] - changed
Output schema / properties / data / anyOfPrevious value: -[ - { - "additionalProperties": {}, - "properties": { - "items": { - "anyOf": [ - { - "items": { - "additionalProperties": {}, - "properties": { - "pathway_id": { - "type": "string" - }, - "title": { - "type": "string" - } - }, - "required": [ - "pathway_id", - "title" - ], - "type": "object" - }, - "type": "array" - }, - { - "type": "null" - } - ] - }, - "mode": { - "enum": [ - "catalogue", - "pathway" - ], - "type": "string" - }, - "pathway_id": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "stages": { - "anyOf": [ - { - "items": { - "additionalProperties": {}, - "properties": { - "stage_id": { - "type": "string" - }, - "title": { - "type": "string" - }, - "waypoints": { - "items": { - "additionalProperties": {}, - "properties": { - "cite": { - "type": "string" - }, - "why": { - "type": "string" - } - }, - "required": [ - "cite", - "why" - ], - "type": "object" - }, - "type": "array" - } - }, - "required": [ - "stage_id", - "title", - "waypoints" - ], - "type": "object" - }, - "type": "array" - }, - { - "type": "null" - } - ] - } - }, - "required": [ - "mode" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": {}, + "properties": { + "items": { + "anyOf": [ + { + "items": { + "additionalProperties": {}, + "properties": { + "pathway_id": { + "type": "string" + }, + "title": { + "type": "string" + } + }, + "required": [ + "pathway_id", + "title" + ], + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "mode": { + "enum": [ + "catalogue", + "pathway" + ], + "type": "string" + }, + "pathway_id": { + "type": [ + "string", + "null" + ] + }, + "stages": { + "anyOf": [ + { + "items": { + "additionalProperties": {}, + "properties": { + "stage_id": { + "type": "string" + }, + "title": { + "type": "string" + }, + "waypoints": { + "items": { + "additionalProperties": {}, + "properties": { + "cite": { + "type": "string" + }, + "why": { + "type": "string" + } + }, + "required": [ + "cite", + "why" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "stage_id", + "title", + "waypoints" + ], + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "mode" + ], + "type": "object" + }, + { + "type": "null" + } +] - changed
Output schema / properties / pagination / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "complete": { - "type": "boolean" - }, - "next_cursor": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "total": { - "type": "number" - } - }, - "required": [ - "complete", - "next_cursor" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "complete": { + "type": "boolean" + }, + "next_cursor": { + "type": [ + "string", + "null" + ] + }, + "total": { + "type": "number" + } + }, + "required": [ + "complete", + "next_cursor" + ], + "type": "object" + }, + { + "type": "null" + } +]
- Changed
get_provision22 fields changed- removed
Input schema / properties / cursor / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / cursor / typeAdded value: +[ + "string", + "null" +] - removed
Input schema / properties / include_correspondences / anyOfRemoved value: -[ - { - "type": "boolean" - }, - { - "type": "null" - } -] - added
Input schema / properties / include_correspondences / typeAdded value: +[ + "boolean", + "null" +] - removed
Input schema / properties / locator / properties / annex / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / locator / properties / annex / typeAdded value: +[ + "string", + "null" +] - removed
Input schema / properties / locator / properties / article / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / locator / properties / article / typeAdded value: +[ + "string", + "null" +] - removed
Input schema / properties / locator / properties / paragraph / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / locator / properties / paragraph / typeAdded value: +[ + "string", + "null" +] - removed
Input schema / properties / locator / properties / point / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / locator / properties / point / typeAdded value: +[ + "string", + "null" +] - removed
Input schema / properties / locator / properties / recital / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / locator / properties / recital / typeAdded value: +[ + "string", + "null" +] - removed
Input schema / properties / locator / properties / subpoint / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / locator / properties / subpoint / typeAdded value: +[ + "string", + "null" +] - removed
Input schema / properties / on_date / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / on_date / typeAdded value: +[ + "string", + "null" +] - removed
Input schema / properties / version_id / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / version_id / typeAdded value: +[ + "string", + "null" +] - changed
Output schema / properties / data / anyOfPrevious value: -[ - { - "additionalProperties": {}, - "properties": { - "blocks_in_page": { - "type": "number" - }, - "blocks_in_provision": { - "type": "number" - }, - "blocks_total": { - "type": "number" - }, - "cite": { - "type": "string" - }, - "content_hash": { - "type": "string" - }, - "correspondences": { - "anyOf": [ - { - "items": { - "additionalProperties": {}, - "properties": { - "derivation": { - "type": "string" - }, - "note": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "relationship": { - "type": "string" - }, - "target": { - "additionalProperties": {}, - "properties": { - "cite": { - "type": "string" - }, - "instrument_id": { - "type": "string" - }, - "locator": { - "additionalProperties": false, - "properties": { - "annex": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Annex number, roman or arabic (\"I\", \"1\"); omit for an instrument whose single annex is unnumbered." - }, - "article": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Article number as printed: \"97\", \"45a\", \"69-a\"." - }, - "kind": { - "description": "Which kind of provision the locator names.", - "enum": [ - "article", - "annex", - "recital" - ], - "type": "string" - }, - "paragraph": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Numbered paragraph within the article, e.g. \"2\"." - }, - "point": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Lettered point within the paragraph, e.g. \"b\"." - }, - "recital": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Recital number, e.g. \"95\"." - }, - "subpoint": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Sub-point within the point." - } - }, - "required": [ - "kind" - ], - "type": "object" - }, - "url": { - "type": "string" - }, - "version_id": { - "type": "string" - } - }, - "required": [ - "instrument_id", - "version_id", - "cite", - "url", - "locator" - ], - "type": "object" - } - }, - "required": [ - "relationship", - "derivation", - "note", - "target" - ], - "type": "object" - }, - "type": "array" - }, - { - "type": "null" - } - ] - }, - "instrument_id": { - "type": "string" - }, - "kind": { - "type": "string" - }, - "markdown": { - "type": "string" - }, - "narrowed": { - "type": "boolean" - }, - "source_notes": { - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "complete": { - "const": true, - "description": "All notes referenced in this response's text, not the whole document or later pages.", - "type": "boolean" - }, - "items": { - "items": { - "additionalProperties": false, - "properties": { - "key": { - "type": "string" - }, - "marker": { - "type": "string" - }, - "text": { - "type": "string" - } - }, - "required": [ - "key", - "marker", - "text" - ], - "type": "object" - }, - "type": "array" - }, - "scope": { - "const": "returned_text", - "type": "string" - }, - "source_version_id": { - "type": "string" - } - }, - "required": [ - "scope", - "source_version_id", - "complete", - "items" - ], - "type": "object" - }, - { - "type": "null" - } - ], - "description": "Null means unverified/unsupported coverage or an older release; consult the typed warning. Not an empty note inventory. Legal content_hash and block counts exclude this attachment." - }, - "url": { - "type": "string" - }, - "version_id": { - "type": "string" - } - }, - "required": [ - "instrument_id", - "version_id", - "cite", - "kind", - "markdown", - "source_notes", - "narrowed", - "blocks_in_page", - "blocks_total", - "blocks_in_provision", - "content_hash", - "url" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": {}, + "properties": { + "blocks_in_page": { + "type": "number" + }, + "blocks_in_provision": { + "type": "number" + }, + "blocks_total": { + "type": "number" + }, + "cite": { + "type": "string" + }, + "content_hash": { + "type": "string" + }, + "correspondences": { + "anyOf": [ + { + "items": { + "additionalProperties": {}, + "properties": { + "derivation": { + "type": "string" + }, + "note": { + "type": [ + "string", + "null" + ] + }, + "relationship": { + "type": "string" + }, + "target": { + "additionalProperties": {}, + "properties": { + "cite": { + "type": "string" + }, + "instrument_id": { + "type": "string" + }, + "locator": { + "additionalProperties": false, + "properties": { + "annex": { + "description": "Annex number, roman or arabic (\"I\", \"1\"); omit for an instrument whose single annex is unnumbered.", + "type": [ + "string", + "null" + ] + }, + "article": { + "description": "Article number as printed: \"97\", \"45a\", \"69-a\".", + "type": [ + "string", + "null" + ] + }, + "kind": { + "description": "Which kind of provision the locator names.", + "enum": [ + "article", + "annex", + "recital" + ], + "type": "string" + }, + "paragraph": { + "description": "Numbered paragraph within the article, e.g. \"2\".", + "type": [ + "string", + "null" + ] + }, + "point": { + "description": "Lettered point within the paragraph, e.g. \"b\".", + "type": [ + "string", + "null" + ] + }, + "recital": { + "description": "Recital number, e.g. \"95\".", + "type": [ + "string", + "null" + ] + }, + "subpoint": { + "description": "Sub-point within the point.", + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "kind" + ], + "type": "object" + }, + "url": { + "type": "string" + }, + "version_id": { + "type": "string" + } + }, + "required": [ + "instrument_id", + "version_id", + "cite", + "url", + "locator" + ], + "type": "object" + } + }, + "required": [ + "relationship", + "derivation", + "note", + "target" + ], + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "instrument_id": { + "type": "string" + }, + "kind": { + "type": "string" + }, + "markdown": { + "type": "string" + }, + "narrowed": { + "type": "boolean" + }, + "source_notes": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "complete": { + "const": true, + "description": "All notes referenced in this response's text, not the whole document or later pages.", + "type": "boolean" + }, + "items": { + "items": { + "additionalProperties": false, + "properties": { + "key": { + "type": "string" + }, + "marker": { + "type": "string" + }, + "text": { + "type": "string" + } + }, + "required": [ + "key", + "marker", + "text" + ], + "type": "object" + }, + "type": "array" + }, + "scope": { + "const": "returned_text", + "type": "string" + }, + "source_version_id": { + "type": "string" + } + }, + "required": [ + "scope", + "source_version_id", + "complete", + "items" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "description": "Null means unverified/unsupported coverage or an older release; consult the typed warning. Not an empty note inventory. Legal content_hash and block counts exclude this attachment." + }, + "url": { + "type": "string" + }, + "version_id": { + "type": "string" + } + }, + "required": [ + "instrument_id", + "version_id", + "cite", + "kind", + "markdown", + "source_notes", + "narrowed", + "blocks_in_page", + "blocks_total", + "blocks_in_provision", + "content_hash", + "url" + ], + "type": "object" + }, + { + "type": "null" + } +] - changed
Output schema / properties / pagination / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "complete": { - "type": "boolean" - }, - "next_cursor": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "total": { - "type": "number" - } - }, - "required": [ - "complete", - "next_cursor" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "complete": { + "type": "boolean" + }, + "next_cursor": { + "type": [ + "string", + "null" + ] + }, + "total": { + "type": "number" + } + }, + "required": [ + "complete", + "next_cursor" + ], + "type": "object" + }, + { + "type": "null" + } +]
- Changed
get_source_notes6 fields changed- removed
Input schema / properties / cursor / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / cursor / typeAdded value: +[ + "string", + "null" +] - removed
Input schema / properties / version_id / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / version_id / typeAdded value: +[ + "string", + "null" +] - changed
Output schema / properties / data / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "instrument_id": { - "type": "string" - }, - "items": { - "items": { - "additionalProperties": false, - "properties": { - "instrument_id": { - "type": "string" - }, - "marker": { - "type": "string" - }, - "note_key": { - "type": "string" - }, - "text": { - "type": "string" - }, - "url": { - "type": "string" - }, - "version_id": { - "type": "string" - } - }, - "required": [ - "instrument_id", - "version_id", - "note_key", - "marker", - "text", - "url" - ], - "type": "object" - }, - "type": "array" - }, - "next_cursor": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "total": { - "type": "number" - }, - "version_id": { - "type": "string" - } - }, - "required": [ - "instrument_id", - "version_id", - "items", - "total", - "next_cursor" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "instrument_id": { + "type": "string" + }, + "items": { + "items": { + "additionalProperties": false, + "properties": { + "instrument_id": { + "type": "string" + }, + "marker": { + "type": "string" + }, + "note_key": { + "type": "string" + }, + "text": { + "type": "string" + }, + "url": { + "type": "string" + }, + "version_id": { + "type": "string" + } + }, + "required": [ + "instrument_id", + "version_id", + "note_key", + "marker", + "text", + "url" + ], + "type": "object" + }, + "type": "array" + }, + "next_cursor": { + "type": [ + "string", + "null" + ] + }, + "total": { + "type": "number" + }, + "version_id": { + "type": "string" + } + }, + "required": [ + "instrument_id", + "version_id", + "items", + "total", + "next_cursor" + ], + "type": "object" + }, + { + "type": "null" + } +] - changed
Output schema / properties / pagination / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "complete": { - "type": "boolean" - }, - "next_cursor": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "total": { - "type": "number" - } - }, - "required": [ - "complete", - "next_cursor" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "complete": { + "type": "boolean" + }, + "next_cursor": { + "type": [ + "string", + "null" + ] + }, + "total": { + "type": "number" + } + }, + "required": [ + "complete", + "next_cursor" + ], + "type": "object" + }, + { + "type": "null" + } +]
- Changed
list_instruments12 fields changed- removed
Input schema / properties / category / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / category / typeAdded value: +[ + "string", + "null" +] - removed
Input schema / properties / cursor / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / cursor / typeAdded value: +[ + "string", + "null" +] - removed
Input schema / properties / in_force_on_date / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / in_force_on_date / typeAdded value: +[ + "string", + "null" +] - removed
Input schema / properties / is_core / anyOfRemoved value: -[ - { - "type": "boolean" - }, - { - "type": "null" - } -] - added
Input schema / properties / is_core / typeAdded value: +[ + "boolean", + "null" +] - removed
Input schema / properties / status / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / status / typeAdded value: +[ + "string", + "null" +] - changed
Output schema / properties / data / anyOfPrevious value: -[ - { - "additionalProperties": {}, - "properties": { - "items": { - "items": { - "additionalProperties": {}, - "properties": { - "instrument_id": { - "type": "string" - } - }, - "required": [ - "instrument_id" - ], - "type": "object" - }, - "type": "array" - }, - "next_cursor": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "total": { - "type": "number" - } - }, - "required": [ - "items", - "next_cursor", - "total" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": {}, + "properties": { + "items": { + "items": { + "additionalProperties": {}, + "properties": { + "instrument_id": { + "type": "string" + } + }, + "required": [ + "instrument_id" + ], + "type": "object" + }, + "type": "array" + }, + "next_cursor": { + "type": [ + "string", + "null" + ] + }, + "total": { + "type": "number" + } + }, + "required": [ + "items", + "next_cursor", + "total" + ], + "type": "object" + }, + { + "type": "null" + } +] - changed
Output schema / properties / pagination / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "complete": { - "type": "boolean" - }, - "next_cursor": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "total": { - "type": "number" - } - }, - "required": [ - "complete", - "next_cursor" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "complete": { + "type": "boolean" + }, + "next_cursor": { + "type": [ + "string", + "null" + ] + }, + "total": { + "type": "number" + } + }, + "required": [ + "complete", + "next_cursor" + ], + "type": "object" + }, + { + "type": "null" + } +]
- Changed
list_provisions8 fields changed- removed
Input schema / properties / chapter / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / chapter / typeAdded value: +[ + "string", + "null" +] - removed
Input schema / properties / cursor / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / cursor / typeAdded value: +[ + "string", + "null" +] - removed
Input schema / properties / topic / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / topic / typeAdded value: +[ + "string", + "null" +] - changed
Output schema / properties / data / anyOfPrevious value: -[ - { - "additionalProperties": {}, - "properties": { - "instrument_id": { - "type": "string" - }, - "items": { - "items": { - "additionalProperties": {}, - "properties": { - "cite": { - "type": "string" - } - }, - "required": [ - "cite" - ], - "type": "object" - }, - "type": "array" - }, - "kinds_listed": { - "items": { - "type": "string" - }, - "type": "array" - }, - "next_cursor": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "total": { - "type": "number" - } - }, - "required": [ - "instrument_id", - "kinds_listed", - "items", - "next_cursor", - "total" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": {}, + "properties": { + "instrument_id": { + "type": "string" + }, + "items": { + "items": { + "additionalProperties": {}, + "properties": { + "cite": { + "type": "string" + } + }, + "required": [ + "cite" + ], + "type": "object" + }, + "type": "array" + }, + "kinds_listed": { + "items": { + "type": "string" + }, + "type": "array" + }, + "next_cursor": { + "type": [ + "string", + "null" + ] + }, + "total": { + "type": "number" + } + }, + "required": [ + "instrument_id", + "kinds_listed", + "items", + "next_cursor", + "total" + ], + "type": "object" + }, + { + "type": "null" + } +] - changed
Output schema / properties / pagination / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "complete": { - "type": "boolean" - }, - "next_cursor": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "total": { - "type": "number" - } - }, - "required": [ - "complete", - "next_cursor" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "complete": { + "type": "boolean" + }, + "next_cursor": { + "type": [ + "string", + "null" + ] + }, + "total": { + "type": "number" + } + }, + "required": [ + "complete", + "next_cursor" + ], + "type": "object" + }, + { + "type": "null" + } +]
- Changed
list_version_changes13 fields changed- changed
Input schema / properties / articles / anyOfPrevious value: -[ - { - "properties": { - "from": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "to": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - } - }, - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "properties": { + "from": { + "type": [ + "string", + "null" + ] + }, + "to": { + "type": [ + "string", + "null" + ] + } + }, + "type": "object" + }, + { + "type": "null" + } +] - removed
Input schema / properties / cursor / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / cursor / typeAdded value: +[ + "string", + "null" +] - removed
Input schema / properties / from_version_id / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / from_version_id / typeAdded value: +[ + "string", + "null" +] - removed
Input schema / properties / material_only / anyOfRemoved value: -[ - { - "type": "boolean" - }, - { - "type": "null" - } -] - added
Input schema / properties / material_only / typeAdded value: +[ + "boolean", + "null" +] - removed
Input schema / properties / status / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / status / typeAdded value: +[ + "string", + "null" +] - removed
Input schema / properties / to_version_id / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / to_version_id / typeAdded value: +[ + "string", + "null" +] - changed
Output schema / properties / data / anyOfPrevious value: -[ - { - "additionalProperties": {}, - "properties": { - "classification_note": { - "type": "string" - }, - "counts": { - "additionalProperties": { - "type": "number" - }, - "propertyNames": { - "type": "string" - }, - "type": "object" - }, - "definition_markers": { - "items": { - "additionalProperties": {}, - "properties": { - "term": { - "type": "string" - } - }, - "required": [ - "term" - ], - "type": "object" - }, - "type": "array" - }, - "instrument_id": { - "type": "string" - }, - "items": { - "items": { - "additionalProperties": {}, - "properties": { - "article": { - "type": "string" - }, - "status": { - "type": "string" - } - }, - "required": [ - "article", - "status" - ], - "type": "object" - }, - "type": "array" - }, - "materiality_markers": { - "items": { - "additionalProperties": {}, - "properties": { - "article": { - "type": "string" - } - }, - "required": [ - "article" - ], - "type": "object" - }, - "type": "array" - }, - "next_cursor": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "pair": { - "additionalProperties": {}, - "properties": { - "from": { - "additionalProperties": {}, - "properties": { - "version_id": { - "type": "string" - } - }, - "required": [ - "version_id" - ], - "type": "object" - }, - "to": { - "additionalProperties": {}, - "properties": { - "version_id": { - "type": "string" - } - }, - "required": [ - "version_id" - ], - "type": "object" - } - }, - "required": [ - "from", - "to" - ], - "type": "object" - }, - "total": { - "type": "number" - } - }, - "required": [ - "instrument_id", - "pair", - "items", - "next_cursor", - "total", - "counts", - "materiality_markers", - "definition_markers", - "classification_note" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": {}, + "properties": { + "classification_note": { + "type": "string" + }, + "counts": { + "additionalProperties": { + "type": "number" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "definition_markers": { + "items": { + "additionalProperties": {}, + "properties": { + "term": { + "type": "string" + } + }, + "required": [ + "term" + ], + "type": "object" + }, + "type": "array" + }, + "instrument_id": { + "type": "string" + }, + "items": { + "items": { + "additionalProperties": {}, + "properties": { + "article": { + "type": "string" + }, + "status": { + "type": "string" + } + }, + "required": [ + "article", + "status" + ], + "type": "object" + }, + "type": "array" + }, + "materiality_markers": { + "items": { + "additionalProperties": {}, + "properties": { + "article": { + "type": "string" + } + }, + "required": [ + "article" + ], + "type": "object" + }, + "type": "array" + }, + "next_cursor": { + "type": [ + "string", + "null" + ] + }, + "pair": { + "additionalProperties": {}, + "properties": { + "from": { + "additionalProperties": {}, + "properties": { + "version_id": { + "type": "string" + } + }, + "required": [ + "version_id" + ], + "type": "object" + }, + "to": { + "additionalProperties": {}, + "properties": { + "version_id": { + "type": "string" + } + }, + "required": [ + "version_id" + ], + "type": "object" + } + }, + "required": [ + "from", + "to" + ], + "type": "object" + }, + "total": { + "type": "number" + } + }, + "required": [ + "instrument_id", + "pair", + "items", + "next_cursor", + "total", + "counts", + "materiality_markers", + "definition_markers", + "classification_note" + ], + "type": "object" + }, + { + "type": "null" + } +] - changed
Output schema / properties / pagination / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "complete": { - "type": "boolean" - }, - "next_cursor": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "total": { - "type": "number" - } - }, - "required": [ - "complete", - "next_cursor" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "complete": { + "type": "boolean" + }, + "next_cursor": { + "type": [ + "string", + "null" + ] + }, + "total": { + "type": "number" + } + }, + "required": [ + "complete", + "next_cursor" + ], + "type": "object" + }, + { + "type": "null" + } +]
- Changed
resolve_citation4 fields changed- removed
Input schema / properties / cursor / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / cursor / typeAdded value: +[ + "string", + "null" +] - changed
Output schema / properties / data / anyOfPrevious value: -[ - { - "additionalProperties": {}, - "properties": { - "ambiguous": { - "type": "boolean" - }, - "items": { - "items": { - "additionalProperties": {}, - "properties": { - "cite": { - "type": "string" - }, - "confidence": { - "enum": [ - "exact", - "strong", - "ambiguous" - ], - "type": "string" - }, - "instrument_id": { - "type": "string" - }, - "kind": { - "type": "string" - }, - "locator": { - "anyOf": [ - { - "additionalProperties": {}, - "propertyNames": { - "type": "string" - }, - "type": "object" - }, - { - "type": "null" - } - ] - }, - "url": { - "type": "string" - }, - "why": { - "type": "string" - } - }, - "required": [ - "instrument_id", - "cite", - "kind", - "locator", - "confidence", - "why", - "url" - ], - "type": "object" - }, - "type": "array" - }, - "next_cursor": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "not_in_corpus": { - "items": { - "additionalProperties": {}, - "properties": { - "celex": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "named": { - "type": "string" - } - }, - "required": [ - "named", - "celex" - ], - "type": "object" - }, - "type": "array" - }, - "total": { - "type": "number" - }, - "unresolved": { - "type": "boolean" - } - }, - "required": [ - "items", - "next_cursor", - "total", - "ambiguous", - "unresolved", - "not_in_corpus" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": {}, + "properties": { + "ambiguous": { + "type": "boolean" + }, + "items": { + "items": { + "additionalProperties": {}, + "properties": { + "cite": { + "type": "string" + }, + "confidence": { + "enum": [ + "exact", + "strong", + "ambiguous" + ], + "type": "string" + }, + "instrument_id": { + "type": "string" + }, + "kind": { + "type": "string" + }, + "locator": { + "anyOf": [ + { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + { + "type": "null" + } + ] + }, + "url": { + "type": "string" + }, + "why": { + "type": "string" + } + }, + "required": [ + "instrument_id", + "cite", + "kind", + "locator", + "confidence", + "why", + "url" + ], + "type": "object" + }, + "type": "array" + }, + "next_cursor": { + "type": [ + "string", + "null" + ] + }, + "not_in_corpus": { + "items": { + "additionalProperties": {}, + "properties": { + "celex": { + "type": [ + "string", + "null" + ] + }, + "named": { + "type": "string" + } + }, + "required": [ + "named", + "celex" + ], + "type": "object" + }, + "type": "array" + }, + "total": { + "type": "number" + }, + "unresolved": { + "type": "boolean" + } + }, + "required": [ + "items", + "next_cursor", + "total", + "ambiguous", + "unresolved", + "not_in_corpus" + ], + "type": "object" + }, + { + "type": "null" + } +] - changed
Output schema / properties / pagination / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "complete": { - "type": "boolean" - }, - "next_cursor": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "total": { - "type": "number" - } - }, - "required": [ - "complete", - "next_cursor" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "complete": { + "type": "boolean" + }, + "next_cursor": { + "type": [ + "string", + "null" + ] + }, + "total": { + "type": "number" + } + }, + "required": [ + "complete", + "next_cursor" + ], + "type": "object" + }, + { + "type": "null" + } +]
- Changed
search_defined_terms10 fields changed- removed
Input schema / properties / cursor / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / cursor / typeAdded value: +[ + "string", + "null" +] - removed
Input schema / properties / instrument / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / instrument / typeAdded value: +[ + "string", + "null" +] - removed
Input schema / properties / only_divergent / anyOfRemoved value: -[ - { - "type": "boolean" - }, - { - "type": "null" - } -] - added
Input schema / properties / only_divergent / typeAdded value: +[ + "boolean", + "null" +] - removed
Input schema / properties / query / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / query / typeAdded value: +[ + "string", + "null" +] - changed
Output schema / properties / data / anyOfPrevious value: -[ - { - "additionalProperties": {}, - "properties": { - "items": { - "items": { - "additionalProperties": {}, - "properties": { - "defined_in": { - "items": { - "additionalProperties": {}, - "properties": { - "cite": { - "type": "string" - }, - "defined_within": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "instrument_id": { - "type": "string" - }, - "qualifier": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - } - }, - "required": [ - "instrument_id", - "qualifier", - "defined_within", - "cite" - ], - "type": "object" - }, - "type": "array" - }, - "divergent_resolved": { - "type": "boolean" - }, - "divergent_verbatim": { - "type": "boolean" - }, - "term": { - "type": "string" - } - }, - "required": [ - "term", - "defined_in", - "divergent_verbatim", - "divergent_resolved" - ], - "type": "object" - }, - "type": "array" - }, - "next_cursor": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "total": { - "type": "number" - } - }, - "required": [ - "items", - "next_cursor", - "total" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": {}, + "properties": { + "items": { + "items": { + "additionalProperties": {}, + "properties": { + "defined_in": { + "items": { + "additionalProperties": {}, + "properties": { + "cite": { + "type": "string" + }, + "defined_within": { + "type": [ + "string", + "null" + ] + }, + "instrument_id": { + "type": "string" + }, + "qualifier": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "instrument_id", + "qualifier", + "defined_within", + "cite" + ], + "type": "object" + }, + "type": "array" + }, + "divergent_resolved": { + "type": "boolean" + }, + "divergent_verbatim": { + "type": "boolean" + }, + "term": { + "type": "string" + } + }, + "required": [ + "term", + "defined_in", + "divergent_verbatim", + "divergent_resolved" + ], + "type": "object" + }, + "type": "array" + }, + "next_cursor": { + "type": [ + "string", + "null" + ] + }, + "total": { + "type": "number" + } + }, + "required": [ + "items", + "next_cursor", + "total" + ], + "type": "object" + }, + { + "type": "null" + } +] - changed
Output schema / properties / pagination / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "complete": { - "type": "boolean" - }, - "next_cursor": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "total": { - "type": "number" - } - }, - "required": [ - "complete", - "next_cursor" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "complete": { + "type": "boolean" + }, + "next_cursor": { + "type": [ + "string", + "null" + ] + }, + "total": { + "type": "number" + } + }, + "required": [ + "complete", + "next_cursor" + ], + "type": "object" + }, + { + "type": "null" + } +]
- Changed
search_legislation10 fields changed- removed
Input schema / properties / cursor / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / cursor / typeAdded value: +[ + "string", + "null" +] - removed
Input schema / properties / in_force_on_date / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / in_force_on_date / typeAdded value: +[ + "string", + "null" +] - removed
Input schema / properties / instrument_id / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / instrument_id / typeAdded value: +[ + "string", + "null" +] - removed
Input schema / properties / topic / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / topic / typeAdded value: +[ + "string", + "null" +] - changed
Output schema / properties / data / anyOfPrevious value: -[ - { - "additionalProperties": {}, - "properties": { - "citation_routed": { - "type": "boolean" - }, - "items": { - "items": { - "additionalProperties": {}, - "properties": { - "cite": { - "type": "string" - }, - "instrument_id": { - "type": "string" - }, - "locator": { - "additionalProperties": {}, - "propertyNames": { - "type": "string" - }, - "type": "object" - }, - "matched_via": { - "type": "string" - }, - "score": { - "anyOf": [ - { - "type": "number" - }, - { - "type": "null" - } - ] - }, - "snippet": { - "type": "string" - }, - "source_type": { - "type": "string" - }, - "url": { - "type": "string" - }, - "why": { - "type": "string" - } - }, - "required": [ - "instrument_id", - "cite", - "source_type", - "locator", - "url", - "snippet", - "score", - "why", - "matched_via" - ], - "type": "object" - }, - "type": "array" - }, - "match_mode": { - "type": "string" - }, - "next_cursor": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "query_terms": { - "items": { - "type": "string" - }, - "type": "array" - }, - "total": { - "type": "number" - } - }, - "required": [ - "query_terms", - "match_mode", - "citation_routed", - "items", - "next_cursor", - "total" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": {}, + "properties": { + "citation_routed": { + "type": "boolean" + }, + "items": { + "items": { + "additionalProperties": {}, + "properties": { + "cite": { + "type": "string" + }, + "instrument_id": { + "type": "string" + }, + "locator": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "matched_via": { + "type": "string" + }, + "score": { + "type": [ + "number", + "null" + ] + }, + "snippet": { + "type": "string" + }, + "source_type": { + "type": "string" + }, + "url": { + "type": "string" + }, + "why": { + "type": "string" + } + }, + "required": [ + "instrument_id", + "cite", + "source_type", + "locator", + "url", + "snippet", + "score", + "why", + "matched_via" + ], + "type": "object" + }, + "type": "array" + }, + "match_mode": { + "type": "string" + }, + "next_cursor": { + "type": [ + "string", + "null" + ] + }, + "query_terms": { + "items": { + "type": "string" + }, + "type": "array" + }, + "total": { + "type": "number" + } + }, + "required": [ + "query_terms", + "match_mode", + "citation_routed", + "items", + "next_cursor", + "total" + ], + "type": "object" + }, + { + "type": "null" + } +] - changed
Output schema / properties / pagination / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "complete": { - "type": "boolean" - }, - "next_cursor": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "total": { - "type": "number" - } - }, - "required": [ - "complete", - "next_cursor" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "complete": { + "type": "boolean" + }, + "next_cursor": { + "type": [ + "string", + "null" + ] + }, + "total": { + "type": "number" + } + }, + "required": [ + "complete", + "next_cursor" + ], + "type": "object" + }, + { + "type": "null" + } +]
1 tool update
- Changed
fetch1 field changed- changed
Input schema / properties / id / descriptionPrevious value: -"An id from search, or a cite anchor such as \"psd-2 Art 97\" or \"psd-2 Recital 12\", or an instrument id such as \"psd-2\"."New value: +"An id from search, or a cite anchor such as \"psd-2 Art 97\" or \"psd-2 Recital 12\", or an instrument id such as \"psd-2\". An optional version qualifier, e.g. \"psr (com-2023-367) Art 105\", retains its edition and refuses unserved text."
2 tool updates
- Changed
search1 field changed- changed
Input schema / properties / query / descriptionPrevious value: -"A single query string."New value: +"EU payments legislative terms or citation, e.g. \"strong customer authentication\", \"safeguarding\" or \"Article 97 PSD2\"."
- Changed
search_legislation1 field changed- changed
Input schema / properties / query / descriptionPrevious value: -"What to search for, in the words you expect in the legal text. Quoted phrases are honoured; AND, OR and NOT are the only operators. A citation-shaped query (\"Article 97(1) PSD2\") is resolved through the citation grammar first."New value: +"EU legislative search terms, e.g. \"strong customer authentication\", \"dynamic linking\", \"safeguarding\" or \"DORA ICT risk\". Use words expected in the legal text, not an entire advice request. Quoted phrases are honoured; AND, OR and NOT are the only operators. A citation-shaped query (\"Article 97(1) PSD2\") is resolved through the citation grammar first."
1 tool update
- Changed
get_orientation2 fields changed- added
Input schema / properties / cursorAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "pagination.next_cursor from this tool; repeat the same pathway and limit." +} - added
Input schema / properties / limitAdded value: +{ + "anyOf": [ + { + "maximum": 100, + "minimum": 1, + "type": "integer" + }, + { + "type": "null" + } + ], + "description": "Maximum catalogue entries or pathway waypoints per page; whole-item byte bounds may return fewer." +}
1 tool update
- Added
get_source_notes
13 tool updates
- First observed
compare_versions - First observed
fetch - First observed
get_defined_term - First observed
get_instrument - First observed
get_orientation - First observed
get_provision - First observed
list_instruments - First observed
list_provisions - First observed
list_version_changes - First observed
resolve_citation - First observed
search - First observed
search_defined_terms - First observed
search_legislation
Related MCP Connectors
- acquisOAuthcom.acquislaw
Verified EU law: verbatim, signed provisions with EUR-Lex links. Read-only, not legal advice.
EU law, article-level: GDPR, NIS2, DORA, EU AI Act + more, with EUR-Lex citations. Keyless.
EU regulations (GDPR, DORA, NIS2, AI Act, etc.) via Ansvar Gateway. Cited, OAuth + paid.
Temporal search and comparison for official Luxembourg and reviewed EU law, with provenance.
Related MCP Servers
- AlicenseAqualityBmaintenanceProvides deterministic, read-only retrieval of authoritative EU legal materials, including legislation, case law, and EDPB/EDPS documents, with exact text, structural identifiers, and provenance.16MIT
- AlicenseNot gradedqualityFmaintenanceEnables querying 40 Slovenian statutes with full-text search, provision retrieval, and EU law integration, providing verified references from official PISRS sources.33 npmApache 2.0
- AlicenseNot gradedqualityBmaintenanceAcquis gives your assistant exact, verifiable access to EU digital regulation. Instead of paraphrasing from training data, it returns the verbatim provision of the current consolidated version — with the full citation (act, article, paragraph, point), its in-force status, the consolidation date, and a deep link to EUR-Lex so every claim can be checked. The legal text is rendered from the signed cMIT
- AlicenseNot gradedqualityFmaintenanceEnables querying and analyzing Slovak legislation via natural language, including full-text search, provision retrieval, and EU law integration.38 npm2Apache 2.0
Glama MCP Gateway
Add one secure layer between your agents and this server.