Validates IBAN/ISBN/EAN/Luhn checksums and finds the one wrong digit
Maintain this server? Claim it
Call this server's tools from your browser. Nothing to install.
Requests go through mcptry because browsers can't call most MCP servers directly. Header values are sent to the server for that request only and are never stored or logged.
Tool list from our last check. Connect live to refresh it.
Validate the check digit(s) on an IBAN, ISBN-10, ISBN-13, EAN-13, UPC-A, or Luhn-checked card number, and when it fails, try to say which digit is wrong. Use this instead of computing the checksum yourself. Mod-97 arithmetic on a rearranged 15-34 character IBAN, or a weighted sum mod 10/11 over 10-19 digits, is exactly the kind of long deterministic calculation language models get wrong silently and confidently — there is no way for a reader to tell a fabricated "valid" from a real one without redoing the math. This tool actually redoes the math, and when the checksum fails, searches for the single adjacent-digit swap or single-character substitution that would repair it, because a transposed pair is the most common real cause of a bounced payment or a mistyped barcode. IMPORTANT, and easy to get wrong: for ISBN-13/EAN-13/UPC-A and Luhn, the digit alphabet (0-9) almost exactly spans the checksum's modulus, so a failing check usually admits MANY equally valid single-digit substitutions — the math genuinely cannot narrow it to one digit unless the error was an adjacent transposition. When that happens, the response reports the full candidate list rather than picking one; treat that as the honest answer, not a failure to find it. IBAN (mod 97) is the exception and usually does localize to one digit. Inputs: `input` (the number; spaces and hyphens are stripped automatically) and `format`, one of iban | isbn10 | isbn13 | ean13 | upca | luhn — required, never auto-detected, because the same digit string can be validly checked under more than one format with different results. Refuses rather than guesses: an IBAN country code not in the ISO 13616 length registry, the wrong length for a declared format, or characters outside the format's alphabet (e.g. a letter in a card number). A passing checksum is a syntax check only — it does not confirm an IBAN names an open account, an ISBN is a real book, or a card is active or unstolen.
The number to check, e.g. "DE89370400440532013000". Spaces and hyphens are stripped automatically; anything else must match the declared format exactly.
Which checksum to apply — one of: iban, isbn10, isbn13, ean13, upca, luhn. Required; a bare number is not auto-detected because the same digits can be validly checked under more than one format with different results.
Validate the check digit(s) on an IBAN, ISBN-10, ISBN-13, EAN-13, UPC-A, or Luhn-checked card number, and when it fails, try to say which digit is wrong. Use this instead of computing the checksum yourself. Mod-97 arithmetic on a rearranged 15-34 character IBAN, or a weighted sum mod 10/11 over 10-19 digits, is exactly the kind of long deterministic calculation language models get wrong silently and confidently — there is no way for a reader to tell a fabricated "valid" from a real one without redoing the math. This tool actually redoes the math, and when the checksum fails, searches for the single adjacent-digit swap or single-character substitution that would repair it, because a transposed pair is the most common real cause of a bounced payment or a mistyped barcode. IMPORTANT, and easy to get wrong: for ISBN-13/EAN-13/UPC-A and Luhn, the digit alphabet (0-9) almost exactly spans the checksum's modulus, so a failing check usually admits MANY equally valid single-digit substitutions — the math genuinely cannot narrow it to one digit unless the error was an adjacent transposition. When that happens, the response reports the full candidate list rather than picking one; treat that as the honest answer, not a failure to find it. IBAN (mod 97) is the exception and usually does localize to one digit. Inputs: `input` (the number; spaces and hyphens are stripped automatically) and `format`, one of iban | isbn10 | isbn13 | ean13 | upca | luhn — required, never auto-detected, because the same digit string can be validly checked under more than one format with different results. Refuses rather than guesses: an IBAN country code not in the ISO 13616 length registry, the wrong length for a declared format, or characters outside the format's alphabet (e.g. a letter in a card number). A passing checksum is a syntax check only — it does not confirm an IBAN names an open account, an ISBN is a real book, or a card is active or unstolen.
| Argument | Type | Description |
|---|---|---|
| input* | string | The number to check, e.g. "DE89370400440532013000". Spaces and hyphens are stripped automatically; anything else must match the declared format exactly. |
| format* | string | Which checksum to apply — one of: iban, isbn10, isbn13, ean13, upca, luhn. Required; a bare number is not auto-detected because the same digits can be validly checked under more than one format with different results. |
{
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"required": [
"input",
"format"
],
"properties": {
"input": {
"type": "string",
"description": "The number to check, e.g. \"DE89370400440532013000\". Spaces and hyphens are stripped automatically; anything else must match the declared format exactly."
},
"format": {
"enum": [
"iban",
"isbn10",
"isbn13",
"ean13",
"upca",
"luhn"
],
"type": "string",
"description": "Which checksum to apply — one of: iban, isbn10, isbn13, ean13, upca, luhn. Required; a bare number is not auto-detected because the same digits can be validly checked under more than one format with different results."
}
}
}