ISO 20022 Navigator

ISO 20022 code sets

iso20022_code_sets

Read-onlyIdempotent

Use for ANY question about ISO 20022 external code sets: the values of a code set (BalanceType, ReturnReason, Purpose, StatusReason, ...), what a code means (CLBD, OTHR, ...), whether a code is valid in a code set, which code sets a message uses (camt.053, pain.001, ...), or which messages use a code set. Call it even when the answer seems well known: it returns the sourced, current values with their official descriptions and flags deactivated ones.

Send one identifier in message:

A code set (BalanceType, or ExternalBalanceType1Code): its description, its values (code, name, description) and the messages that use it. Add code to check a single value.
A code (CLBD): every code set that contains it, with the name and description in each.
An ISO 20022 message (camt.053): the code sets it uses, with their number of values.

The values, code sets and matches are pipe-delimited text with a header row. Long lists are paged by whole rows: when page.complete is false, call again with the same input and the offset in page.next_offset until it is true, before answering about the whole list.

Not covered: Bank Transaction Codes (PMNT, PMNT-RCDT-ESCT; use iso20022_bank_transaction_codes), which ISO 20022 message replaces a legacy message or which schemes use one (use iso20022_legacy_and_scheme_mappings), and what a message itself contains. Code set usage is message-level, not element-level. The code set description (concept_description) is AI-generated.

Input Schema

Name	Required	Description
`code`	No	Optional, only when message is a code set: check one code in that set, e.g. message 'BalanceType' with code 'CLBD'. Returns just that value, so use it for 'is X a valid ...' questions instead of fetching the whole set.
`offset`	No	Row to start from; 0 (the default) is the first row. Use only to continue a list whose previous response said it was not complete, with the next_offset from that response.
`message`	Yes	A code set (e.g. 'BalanceType', or its full name 'ExternalBalanceType1Code'), a code (e.g. 'CLBD', 'OTHR'), or an ISO 20022 message (e.g. 'camt.053', 'pacs.008.001.08').

Output Schema

Name	Required	Description
`page`	No	Paging of the pipe-delimited list. Continue with next_offset until complete is true.
`found`	Yes
`input`	Yes	The identifier as interpreted by the server: the code set's short name, the ISO 20022 message, or the code
`notes`	No	Caveats to pass on to the user
`values`	No	input_kind code_set: the values, pipe-delimited, one row per line. First line is the header: code\|name\|description\|deactivated_in. deactivated_in is empty for current values.
`matches`	No	input_kind code: every code set containing the code, pipe-delimited, one row per line. First line is the header: concept\|code\|name\|description\|deactivated_in.
`code_set`	No	Attributes of the code set (input_kind code_set)
`code_sets`	No	input_kind message: the code sets the message uses, pipe-delimited, one row per line. First line is the header: concept\|navigator_group\|code_count. code_count is the number of current values.
`input_kind`	Yes
`provenance`	Yes
`used_in_messages`	No	input_kind code_set: IDs of the messages (all variants) that use this code set. Complete on every page.
`iso20022_message_name`	No	Name of the ISO 20022 message, when the input is one
`iso20022_deactivated_in`	No	Navigator data load (quarter) in which the input message was marked deactivated; absent if current

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 13, 2026

addedOutput schema / $defs / CodeSetInfo / properties / message_count

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Number of messages in used_in_messages (all variants). Use it instead of counting the list; absent when the requested code is not in the set",
+  "title": "Message Count"
+}

AddedOct 12, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds real behavioral context beyond that: it returns 'sourced, current values' and flags deactivated codes, and it discloses the pagination contract (page.complete/page.next_offset) with an instruction to finish paging before answering. It also warns that concept_description is AI-generated, a useful trust caveat not available in 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.

Conciseness4/5

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

Front-loaded purpose, then per-identifier behavior, then the 'Not covered' block — a sensible order. Bullets are tight, though the description is on the long side and repeats the paging rule twice (once in prose, once in the schema for offset).

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

Completeness4/5

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

An output schema exists, so return-shape explanation is not required, yet the description still usefully characterizes the return format (pipe-delimited with header row). Coverage of the three identifier modes, exclusions, and paging is enough for correct invocation; the only minor gap is that element-level vs message-level scope is asserted without elaboration.

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 the baseline is 3. The description earns above baseline by explaining the interaction between `message` and `code` (code only applies when message is a code set), advising the `code` shortcut for validity questions instead of fetching a whole set, and describing the paging loop for `offset`.

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?

Opens with a specific directive ('Use for ANY question about ISO 20022 external code sets') and enumerates the concrete question types it answers (values of a code set, meaning of a code, validity, which code sets a message uses). It explicitly names the sibling iso20022_bank_transaction_codes as out of scope, so an agent can route correctly without opening another 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 when-to-use ('Call it even when the answer seems well known'), a when-NOT-to-use section that names two concrete sibling tools for excluded topics, and a concrete alternative for the session-language question ('use iso20022_bank_transaction_codes'). Routing logic is unambiguous.

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.