Skip to main content
Glama
sebastienrousseau

structured-address-fix-mcp

by sebastienrousseau
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Get the ISO 20022 cutover date

get_cutover_date
Read-onlyIdempotent

Check when the ISO 20022 structured-address requirement takes effect, including deferral status and current date, to plan migration.

Instructions

Report when the structured-address requirement binds, if it yet does.

Swift accepted a community request on 27 August 2026 and deferred every
payments change in Standards Release 2026, the structured-address
requirement among them. No replacement date has been set; Swift will
confirm timing by December 2026 at the latest.

``date`` is therefore ``None``. It is left null rather than filled with
the withdrawn date because an agent reading this hands the answer to
somebody planning a migration, and a date with no force is worse than no
date at all. The requirement itself was agreed by the community in 2023
and stands: ``status`` says deferred, not withdrawn.

The deferral is Swift's, and covers CBPR+. Domestic market
infrastructures set their own timing and several were aligned to the same
November date; check the schemes you settle through rather than assuming
they moved with Swift.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.0.2

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly and idempotent annotations, the description discloses that ``date`` is None, that null is intentionally preferred over a withdrawn date, and that ``status`` is deferred rather than withdrawn. This is valuable behavioral context that prevents the agent from fabricating a date or mischaracterizing the requirement.

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?

The purpose is front-loaded in the first sentence, and the subsequent paragraphs earn their place by explaining the deferral, the null semantics, and the domestic-scope caveat. It is wordier than a simple lookup might need, but no sentence is filler given the nuanced context the agent must understand.

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 zero parameters, existing annotations, and an output schema, the description supplies everything else needed: the current status, why the date is null, that the requirement stands, and how far the deferral extends. An agent can select, invoke, and interpret this tool correctly from the definition alone.

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

Parameters4/5

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

The input schema has zero parameters, so there is nothing for the description to enrich on the input side. The description's references to ``date`` and ``status`` concern the output, and the empty schema already has full coverage.

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

Purpose5/5

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

The first sentence, 'Report when the structured-address requirement binds, if it yet does,' names a specific action and resource, and the title ties it to the ISO 20022 cutover date. This clearly identifies what the tool does without ambiguity and separates it from the address-mutation and validation siblings.

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

Usage Guidelines4/5

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

The description draws an explicit scope boundary: the deferral is Swift's and covers CBPR+, while domestic market infrastructures set their own timing. It advises checking the relevant schemes rather than assuming they moved with Swift, which gives the agent useful when-not guidance, though no alternative tool is named.

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

Deploy Server

Other Tools