OnlineCyberTools MCP (280+ filterable tools)

osint_bic_swift_validate

Read-onlyIdempotent

Validate and decode BIC/SWIFT bank codes (ISO 9362): checks format, extracts bank code, country, location, and branch details. Pure structural validation with no external network calls.

Instructions

BIC / SWIFT Code Validator. Validate the format and structure of a BIC/SWIFT bank code (ISO 9362) and decode its four parts: 4-letter bank code, 2-letter ISO country code, 2-character location code, and optional 3-character branch code. Confirms the code is 8 or 11 characters, matches the BIC character pattern, and has a recognised country, then reports the location type (primary office, passive, test), message-routing type, and whether it is a head office or a specific branch. Use osint_iban_validator instead when you have a full International Bank Account Number rather than a bank identifier code. Pure structural validation that runs locally on the code you provide: read-only, non-destructive, contacts no external service and does not look up the bank over the network, and is rate-limited (20 requests/minute for anonymous callers). Returns overall validity plus the parsed bank/country/location/branch structure, decoded details, and a space-grouped formatted code.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`code`	No	BIC/SWIFT code to validate (8 or 11 characters). Case-insensitive and spaces/punctuation are stripped before validation. Must not be blank.
`bic_swift_code`	No	Alias for code, accepted when code is not supplied. If both are present, code takes precedence.

Output Schema

TableJSON Schema

Name	Required	Description
`success`	No	True when the code was validated; false when the input was missing or rejected as malformed.
`error`	No	Human-readable failure reason, present only when success is false.
`result`	No	Validation result, present only when success is true.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.5.1Jun 3, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

addedInput schema / properties / bic_swift_code

Added value: +{
+  "description": "Alias for code, accepted when code is not supplied. If both are present, code takes precedence.",
+  "type": "string"
+}

addedInput schema / properties / code / description

Added value: +"BIC/SWIFT code to validate (8 or 11 characters). Case-insensitive and spaces/punctuation are stripped before validation. Must not be blank."

removedInput schema / required
```
Removed value: -[
-  "code"
-]
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "error": {
+      "description": "Human-readable failure reason, present only when success is false.",
+      "type": "string"
+    },
+    "result": {
+      "description": "Validation result, present only when success is true.",
+      "properties": {
+        "code": {
+          "description": "The normalised (uppercased, stripped) BIC/SWIFT code.",
+          "type": "string"
+        },
+        "details": {
+          "description": "Human-readable decoding of the location and branch segments.",
+          "properties": {
+            "branch": {
+              "description": "Branch description (specific branch code, head office, or implied head office).",
+              "type": "string"
+            },
+            "country": {
+              "description": "Full country name resolved from the country code.",
+              "type": "string"
+            },
+            "isTest": {
+              "description": "Present and true only when character 7 is 0, marking a test (non-production) BIC.",
+              "type": "boolean"
+            },
+            "locationType": {
+              "description": "Meaning of character 7 (primary office, passive participant, reverse billing, or test BIC).",
+              "type": "string"
+            },
+            "messageType": {
+              "description": "Meaning of character 8 (FIN routing capability).",
+              "type": "string"
+            }
+          },
+          "type": "object"
+        },
+        "formatted": {
+          "description": "The code regrouped with spaces between bank, country, location, and branch segments.",
+          "type": "string"
+        },
+        "length": {
+          "description": "Character length of the normalised code (8 or 11).",
+          "type": "integer"
+        },
+        "structure": {
+          "description": "The four positional segments of the BIC/SWIFT code.",
+          "properties": {
+            "bankCode": {
+              "description": "Characters 1-4: institution/bank code.",
+              "type": "string"
+            },
+            "branchCode": {
+              "description": "Characters 9-11 for 11-char codes, otherwise the literal XXX (Head Office) marker.",
+              "type": "string"
+            },
+            "countryCode": {
+              "description": "Characters 5-6: ISO 3166-1 alpha-2 country code.",
+              "type": "string"
+            },
+            "locationCode": {
+              "description": "Characters 7-8: location/status code.",
+              "type": "string"
+            }
+          },
+          "type": "object"
+        },
+        "valid": {
+          "description": "Always true within result; structural validation passed.",
+          "type": "boolean"
+        }
+      },
+      "type": "object"
+    },
+    "success": {
+      "description": "True when the code was validated; false when the input was missing or rejected as malformed.",
+      "type": "boolean"
+    }
+  },
+  "type": "object"
+}

First observedv0.1.0May 31, 2026

TDQS

A4.9/5.0

Behavior5/5

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

The description adds behavioral context beyond annotations: it states the validation runs locally, is read-only, non-destructive, contacts no external service, and has a rate limit of 20 requests/minute. This complements the readOnlyHint, destructiveHint, and idempotentHint annotations.

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

Conciseness5/5

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

The description is well-structured and front-loaded. It begins with a one-line summary, then expands on purpose, usage guidance, behavioral details, and return value. Every sentence adds necessary information without redundancy.

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?

Given the tool's complexity (ISO 9362 validation, decoding, rate limits), the description covers all essential aspects: purpose, when to use, behavioral traits, parameter semantics, and return structure. It is fully adequate for an AI agent to understand and invoke correctly.

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 100% description coverage, providing basic parameter info. The description further explains that the 'code' parameter is case-insensitive and strips spaces/punctuation, and that 'bic_swift_code' is an alias with precedence rules. This adds value beyond the schema.

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 description clearly states the tool validates a BIC/SWIFT code, decodes its four parts, and confirms format and structure. It specifies the code length (8 or 11 characters), character pattern, and country recognition, while distinguishing itself from the sibling osint_iban_validator.

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?

The description explicitly directs to use osint_iban_validator when the user has a full IBAN instead of a bank identifier code. This provides a clear alternative and implies the appropriate context for this tool.

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

Deploy Server