Skip to main content
Glama

Payments Law — EU payments legislation

Show what changed to the reader

show_changes
Read-onlyIdempotent

Shows the reader what changed: presents a comparison or a change inventory to the reader as an interactive card, this service's intended way of showing what changed between the two texts of a served pair. With article, the card is that article's word-level comparison, side by side with every change marked, as compare_versions serves it. With articles, one card holds those articles as a filtered inventory, each opening its comparison in place. Without either, the card is the instrument's inventory of changed articles grouped by kind of change, with the editors' notes, as list_version_changes serves it. The result is a one-line summary with the site link; the card loads its own data. compare_versions and list_version_changes return the same comparison as data, for an answer that quotes or reasons over the wording.

Input Schema

NameRequiredDescriptionDefault
articleNoAn article number. With it, the card is that article's comparison; without it and without articles, the instrument's change inventory.
articlesNoSeveral article numbers: one card holding those articles as a filtered inventory, each opening its comparison in place. Not with article.
instrument_idYesRegistry id of the instrument, e.g. "psr".
to_version_idNoWith from_version_id, the later text of the pair: both ids or neither. The same ids and aliases.
from_version_idNoOptional; both ids or neither. Where the instrument has one published pair, that pair is shown. A version id, or an alias the instrument defines: proposal, compromise, council, published.

Output Schema

NameRequiredDescriptionDefault
cardYes
textYes
warningsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / warnings
      Added value: +{
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "code": {
      +        "type": "string"
      +      },
      +      "details": {
      +        "additionalProperties": {},
      +        "propertyNames": {
      +          "type": "string"
      +        },
      +        "type": "object"
      +      },
      +      "message": {
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "code",
      +      "message"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
  2. Added
  3. Removed
  4. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower. The description still adds real context beyond structured fields: the result is a one-line summary with the site link, and the card lazy-loads its own data, which tells the agent not to expect the comparison payload in the call result.

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

Conciseness4/5

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

Purpose and the primary sibling distinction are front-loaded, and each following sentence maps to a distinct invocation branch. The sentences are long and densely nested, which costs some readability, but no sentence is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With five parameters, rich schema descriptions, annotations, and an output schema present, the definition supplies exactly the missing layer: what the tool renders versus returns, how the argument branches map to cards, and which siblings return raw data. Nothing needed to invoke it correctly is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description goes further by framing the parameter combinations in terms of the resulting card ('with article... without it and without articles...'), clarifying the mutual exclusivity of article vs articles and the both-or-neither rule for the version pair — semantics that help an agent choose arguments, not just fill them.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and outcome ('shows the reader what changed') and names the exact artifact produced (interactive card). It explicitly distinguishes itself from siblings compare_versions and list_version_changes, which 'return the same comparison as data,' so an agent can route correctly without opening any schema.

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

Usage Guidelines5/5

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

Gives explicit branching conditions: with 'article' the card is that article's word-level comparison; with 'articles' it is a filtered inventory; with neither it is the instrument's change inventory. It also names the alternative tools and the condition that selects them ('for an answer that quotes or reasons over the wording').

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources