Validates Discover card numbers using Luhn checksum and length rules, and detects the brand from the BIN.
Validates JCB card numbers using Luhn checksum and length rules, and detects the brand from the BIN.
Validates Mastercard card numbers using Luhn checksum and length rules, and detects the brand from the BIN.
Validates Visa card numbers using Luhn checksum and length rules, and detects the brand from the BIN.
Verified validation of structured identifiers for AI agents — checksums, not guesses.
LLMs cheerfully accept malformed IBANs, mistype card check digits, invent ISBN and VIN
check digits, and guess a card's brand wrong. veridigit gives an agent a deterministic,
authoritative answer instead: it runs the real checksum algorithms and returns structured
results with the parsed parts and clear error reasons.
It ships as both an MCP server (for agents to call live) and a typed TypeScript library (for apps to import).
Supported in v1:
IBAN — ISO 7064 mod-97 checksum + country-specific length, for 75+ countries.
Payment cards — Luhn (ISO/IEC 7812) checksum, brand detection from the BIN (Visa, Mastercard, Amex, Discover, Diners, JCB, UnionPay), and length rules.
ISBN-13 — 978/979 prefix and mod-10 weighted check digit.
VIN — ISO 3779 alphabet (no I/O/Q) and the position-9 transliteration check digit.
On 32 randomly generated, non-memorised identifiers, a frontier model with no tool got the
check digit wrong 91% of the time — IBAN 100%, VIN 100%, ISBN-13 88%, card/Luhn 75% —
versus 0% for veridigit. The failure is invisible: the model returns a confident,
well-formatted answer that happens to be wrong. veridigit replaces the guess with the
algorithm.
Benchmark and reproducible harness: https://qinisolabs.github.io/veridigit
The 91% figure is one frontier model, tool-free, at temperature 0. Run it on any model yourself with the harness in
bench/.
Related MCP server: mcp-europe-business
// in your MCP client config
{
"mcpServers": {
"veridigit": { "command": "npx", "args": ["-y", "veridigit"] }
}
}Tools exposed: validate_iban, validate_card, validate_isbn, validate_vin.
npm install veridigitimport { validateIban, validateCard, validateIsbn13, validateVin } from "veridigit";
validateIban("GB82 WEST 1234 5698 7654 32");
// { valid: true, countryCode: "GB", country: "United Kingdom", checkDigits: "82", ... }
validateCard("4111 1111 1111 1111");
// { valid: true, luhnValid: true, brand: "Visa", lengthValid: true, ... }
validateIsbn13("978-0-306-40615-7"); // { valid: true, type: "ISBN-13", checkDigit: "7", ... }
validateVin("1HGCM82633A004352"); // { valid: true, checkDigit: "3", ... }Helper exports are also available: ibanCheckDigits, luhnValid, luhnCheckDigit,
detectBrand, isbn13CheckDigit, vinCheckDigit, supportedIbanCountries.
veridigit validates the structure of an identifier — its format and checksum. It
does not confirm that a bank account, card, book or vehicle actually exists, is active,
or belongs to anyone. It performs no network calls.
npm install
npm run build # tsc -> dist/
npm test # parity/known-answer tests via tsxThe curated reference data (IBAN country specs, card BIN ranges) lives in data/.
Apache-2.0
USE THIS to check a payment card number's structure before using it — never assume a card number is valid or guess its brand. Verifies the Luhn checksum, detects the brand (Visa, Mastercard, Amex, Discover, Diners, JCB, UnionPay) from its BIN, and checks the length. Does NOT check whether the card is real, active or has funds.
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | The card number; spaces and dashes are ignored. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: verifies Luhn, detects brand from BIN, checks length, and states what it does not check. Does not describe output format or error handling, but for a validation tool the behavior is well communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with usage instruction, no wasted words. Efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing description of return value or output format (no output schema). For a validation tool, agents may need to know what the tool returns (e.g., boolean or result object). Otherwise, the description is specific and complete for its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the 'number' parameter description already covering spaces/dashes ignored. The description adds context on what validation is performed, but does not add new parameter-specific details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks payment card number structure, verifies Luhn checksum, detects brand from BIN, and checks length. It distinguishes from other validation tools by specifying card-specific checks and what it does not do (real/active/funds).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use this tool for checking card structure before use, and warns against assuming validity or guessing brand. It also clarifies what the tool does not check. No alternatives explicitly named, but sibling context makes this clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
USE THIS to verify an IBAN (international bank account number) before relying on it — instead of guessing whether it looks right. Checks the country, the country-specific length, and the ISO 7064 mod-97 checksum, and returns the country, check digits and BBAN. Call this whenever a user supplies a bank account for a payment, payout or invoice.
| Name | Required | Description | Default |
|---|---|---|---|
| iban | Yes | The IBAN to validate; spaces are ignored. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes validation logic (country, length, checksum) and return values. No annotations to contradict; description adds value beyond no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. First sentence gives imperative use, second lists checks and outputs. Very concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter validation tool with no output schema, the description fully covers what it does, how it validates, and what it returns. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already fully describes the parameter (100% coverage). Description does not add new parameter-level detail beyond schema, so baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it validates IBAN, specifies checks (country, length, checksum) and outputs (country, check digits, BBAN). Distinguishes from many sibling validation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'USE THIS to verify an IBAN' and 'Call this whenever a user supplies a bank account'. Provides clear context, though missing explicit exclusions for when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
USE THIS to verify an ISBN-13 book identifier instead of trusting that 13 digits are correct. Checks the 978/979 prefix and the mod-10 weighted check digit, and returns the expected check digit when it fails.
| Name | Required | Description | Default |
|---|---|---|---|
| isbn | Yes | The ISBN-13; hyphens and spaces are ignored. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the verification actions (checking prefix and check digit) and what happens on failure (returns expected check digit). However, it does not specify the return value on success or error handling. Given no annotations, the description adds moderate behavioral context but misses some details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary action, and contains no redundant words. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's core behavior, failure output, and compares to 'trusting digits.' For a simple validation tool with one parameter and no output schema, it is nearly complete. Minor gap: does not state success return type, but this is inferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a parameter description that allows hyphens/spaces. The tool description reinforces that and adds context about validation logic, but does not significantly augment parameter meaning beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool verifies an ISBN-13 identifier, distinguishing it from the sibling tool 'validate_isbn10' by specifying ISBN-13. It mentions specific checks (prefix and check digit), making the purpose explicit and unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use the tool ('USE THIS to verify...') and implies it should be used instead of trusting raw digit strings. While it does not explicitly mention the sibling 'validate_isbn10' for ISBN-10, the context from sibling tools provides clear differentiation. The guidance is adequate but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
USE THIS to verify a vehicle VIN before acting on it — do not assume a 17-character string is a valid VIN. Checks the allowed alphabet (no I/O/Q) and the ISO 3779 transliteration check digit in position 9, and returns the expected check digit when it fails.
| Name | Required | Description | Default |
|---|---|---|---|
| vin | Yes | The 17-character VIN to validate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden of transparency. It discloses that it checks the allowed alphabet (no I/O/Q) and the ISO 3779 check digit in position 9, and returns the expected check digit when validation fails. It does not state whether the operation is read-only or if there are side effects, but the disclosed internal logic is sufficient for understanding tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, no fluff. The first sentence is front-loaded with an imperative action, and every clause provides valuable information. It perfectly balances brevity and informativeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter validation tool with no output schema, the description provides enough context: it explains what the tool does, what checks it performs, and what it returns on failure. It does not specify the return value on success, but that is typically implied (true or valid). Given the sibling context of many validation tools, the description sufficiently equips an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (single parameter with description 'The 17-character VIN to validate'). The description adds context beyond the schema by clarifying that the VIN is for a vehicle and that the tool performs specific checks. This added meaning justifies a score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'verify' and resource 'vehicle VIN', and distinguishes it from other validation tools by specifying that it checks the allowed alphabet (no I/O/Q) and the ISO 3779 check digit. It explicitly instructs to 'USE THIS to verify a vehicle VIN before acting on it', leaving no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance ('before acting on it') and warns against assuming a 17-character string is valid. It does not explicitly name alternatives, but the sibling list of many validate_* tools implies that other identifiers should use the respective tool. A clear 'when not to use' or explicit alternative naming would improve it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0validate_cardvalidate_ibanvalidate_isbnvalidate_vinScored across 4 tools
Each tool validates a completely different type of identifier (card, IBAN, ISBN, VIN) with no overlap in purpose. An agent can clearly distinguish which tool to use based on the entity type.
All tools follow a consistent 'validate_<entity>' pattern using snake_case, making the naming predictable and uniform.
Four tools is an appropriate number for a validation-focused server covering common but distinct identifier types. Each tool serves a clear and necessary purpose without being excessive.
The set covers major identifier validations (payment, banking, book, vehicle). Minor gap: no validation for other common identifiers like email or phone, but the scope is coherent and well-defined.
Checksum validation for AI agents: IBAN, ISBN, EAN/GTIN, UUID, ULID. Deterministic, no auth.
Validates Luhn, IBAN, ISBN, EAN/UPC, SWIFT/BIC, and EU VAT checksums and formats.
IBAN validation, extraction, format specs and BIC/SWIFT lookup tools for AI assistants.
300+ deterministic data utilities for AI agents: validate, normalize, parse, match, redact.
