Server definition

Hash: sha256:79fb455cd69ee38b7333c699b8f178282019e70a501901c2b2c66ccdf909b70d
What it is: What a remote MCP server returned when asked what it offers: 1 tools

The blob, as servednamed by its sha256

{
  "instructions": null,
  "tools": [
    {
      "description": "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.\n\nUse 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.\n\nIMPORTANT, 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.\n\nInputs: `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.\n\nRefuses 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.",
      "inputSchema": {
        "$schema": "https://json-schema.org/draft/2020-12/schema",
        "properties": {
          "format": {
            "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.",
            "enum": [
              "iban",
              "isbn10",
              "isbn13",
              "ean13",
              "upca",
              "luhn"
            ],
            "type": "string"
          },
          "input": {
            "description": "The number to check, e.g. \"DE89370400440532013000\". Spaces and hyphens are stripped automatically; anything else must match the declared format exactly.",
            "type": "string"
          }
        },
        "required": [
          "input",
          "format"
        ],
        "type": "object"
      },
      "name": "run",
      "outputSchema": null
    }
  ]
}

Verify it yourself

curl -s https://api.teppi.xyz/v1/evidence/sha256:79fb455cd69ee38b7333c699b8f178282019e70a501901c2b2c66ccdf909b70d | sha256sum