ISO 20022 Navigator

ISO 20022 message details

iso20022_message_details

Read-onlyIdempotent

Use for ANY question about what an ISO 20022 message is: its official name, purpose, business area, latest version, and the size and shape of its structure. Send a message identifier such as pacs.008, camt.053 or pain.001. Call it even when the message looks familiar: it returns the official name, a plain-English description, the business area and domain, the Navigator's own functional grouping, whether the message is retired, structure statistics (total elements, maximum depth, element counts at each depth) and the number of external code sets the message uses.

Covers the standard variant (variant 1) of each message, at the latest version held. For legacy equivalents (SWIFT MT, NACHA, CHAPS) and the schemes that use a message, use iso20022_legacy_and_scheme_mappings. For the list of code sets a message uses, use iso20022_code_sets (the response's next_calls names it).

Input Schema

Name	Required	Description	Default
`message_id`	Yes	An ISO 20022 message identifier: four letters and three digits, e.g. 'pacs.008' or 'camt.053'. Any case works, and a hyphen, underscore, space or no separator also works ('pacs-008', 'pacs008'). A full identifier with variant and version ('pacs.008.001.13') is accepted; the response gives the latest version held and notes any difference.

Output Schema

Name	Required	Description
`name`	No	Official message name, e.g. BankToCustomerAccountReport
`found`	Yes
`input`	Yes	The message identifier as interpreted by the server, e.g. pacs.008
`notes`	No	Caveats to pass on to the user
`structure`	No	Size and shape of the message definition; absent when no structure is held
`next_calls`	No	Follow-up calls that return related data too large to include here, each with the tool and the arguments to send; absent when there is nothing to follow up
`provenance`	Yes
`closest_ids`	No	Not found only: up to 5 held messages in the same business area, nearest number first
`description`	No	AI-generated plain-English description of the message.
`business_area`	No
`code_set_count`	No	Number of external code sets the message uses
`deactivated_in`	No	Navigator data load (quarter) in which this message was marked deactivated; absent if current
`latest_version`	No	Full identifier of the latest version held, e.g. camt.053.001.14
`navigator_group`	No	The Navigator's own functional grouping of messages. It is not part of the ISO 20022 standard.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 13, 2026

addedOutput schema / $defs / NextCall

Added value: +{
+  "properties": {
+    "arguments": {
+      "additionalProperties": {
+        "type": "string"
+      },
+      "description": "The arguments to send to that tool",
+      "title": "Arguments",
+      "type": "object"
+    },
+    "purpose": {
+      "description": "What the call returns",
+      "title": "Purpose",
+      "type": "string"
+    },
+    "tool": {
+      "description": "Name of the tool that returns the related data",
+      "title": "Tool",
+      "type": "string"
+    }
+  },
+  "required": [
+    "tool",
+    "arguments",
+    "purpose"
+  ],
+  "title": "NextCall",
+  "type": "object"
+}

addedOutput schema / properties / next_calls

Added value: +{
+  "description": "Follow-up calls that return related data too large to include here, each with the tool and the arguments to send; absent when there is nothing to follow up",
+  "items": {
+    "$ref": "#/$defs/NextCall"
+  },
+  "title": "Next Calls",
+  "type": "array"
+}

AddedOct 12, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, closed-world, non-destructive behavior. The description adds real context beyond those: it covers only variant 1, returns the latest version held and notes differences, flags retired messages, and points to next_calls. It stops short of describing pagination or error behavior, so not a full 5.

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 first sentence is front-loaded with the core promise and the alternatives follow immediately after. It is slightly long and the long enumeration of return fields borders on restating the output schema, but no sentence is purely 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 one required parameter, full schema coverage, an output schema present and sibling routing provided, an agent has everything needed to call this correctly. The variant/version and retirement caveats close the remaining ambiguity.

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

Parameters3/5

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

Schema description coverage is 100%, with the pattern, length bounds and accepted separators already documented in the schema, so the baseline is 3. The description reinforces accepted forms ('pacs.008', 'camt.053', 'pain.001') but adds only the latest-version-resolved behavior, which the schema description already states.

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 resource (an ISO 20022 message) and enumerates exactly what it returns: official name, purpose, business area, latest version, structure statistics. It also names the siblings it is not for (legacy/scheme mappings, code sets), so the agent can separate it from alternatives 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.

Usage Guidelines5/5

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

Gives explicit routing: use this for any 'what is this message' question, use iso20022_legacy_and_scheme_mappings for MT/NACHA/CHAPS equivalents and schemes, and iso20022_code_sets for code-set lists. It even tells the agent to call it despite familiarity, removing the main false-negative risk.

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

All ISO 20022 Navigator tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.