Which integrations are available for this server?

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.

veridigit

by qinisolabs

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Remote

veridigit

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.

Why

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

Use as an MCP server

// in your MCP client config
{
  "mcpServers": {
    "veridigit": { "command": "npx", "args": ["-y", "veridigit"] }
  }
}

Tools exposed: validate_iban, validate_card, validate_isbn, validate_vin.

Use as a library

npm install veridigit

import { 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.

Scope

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.

Development

npm install
npm run build   # tsc -> dist/
npm test        # parity/known-answer tests via tsx

The curated reference data (IBAN country specs, card BIN ranges) lives in data/.

License

Apache-2.0

Available Tools

4 tools

validate_cardA

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.

ParametersJSON Schema

Name	Required	Description	Default
`number`	Yes	The card number; spaces and dashes are ignored.

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description fully discloses behavioral traits: it performs Luhn checksum, brand detection, and length verification, but explicitly states it does not check card existence, activity, or funds. No contradictions.

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?

Description is two sentences: the first commands usage and sets context, the second specifies what it does and does not. Extremely concise and front-loaded with no redundant information.

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 no output schema and one parameter with full schema coverage, the description is remarkably complete. It covers purpose, actions, exclusions, and parameter behavior adequately for an AI agent.

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 schema covers the single parameter 'number' at 100% with description of ignoring spaces/dashes. The description adds value by explaining the validation operations performed on that number, which goes beyond the schema's parameter description.

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 it validates a payment card number's structure, Luhn checksum, brand detection, and length. It distinguishes from siblings like validate_iban, validate_isbn, and validate_vin by targeting payment cards specifically.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to use this tool before using a card number, advises against assuming validity or guessing brand, and clarifies what it does NOT check (real, active, funds). However, it does not mention when to use alternatives or when not to use this tool.

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

validate_ibanA

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.

ParametersJSON Schema

Name	Required	Description	Default
`iban`	Yes	The IBAN to validate; spaces are ignored.

TDQS

A4.6/5.0

Behavior4/5

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

Describes validation logic (country, length, checksum) and return values (country, check digits, BBAN). No annotations provided, so description carries full burden; it is thorough but does not mention external dependencies or permissions.

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?

Two sentences, no wasted words, front-loaded with directive 'USE THIS'. Every sentence contributes meaning.

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?

With no output schema, the description adequately explains what is returned. Single parameter case; no gaps. Complete for this simple tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema already describes the 'iban' parameter; the description adds that spaces are ignored, providing additional clarity beyond the schema. With 100% schema coverage, this extra detail is valuable.

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?

Description clearly states it validates IBANs, specifies what is checked (country, length, checksum), and explicitly distinguishes from sibling tools that validate cards, ISBNs, and VINs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs when to call ('whenever a user supplies a bank account for a payment, payout or invoice'). Does not mention when not to use or alternatives, but siblings are clearly different domains.

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

validate_isbnA

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.

ParametersJSON Schema

Name	Required	Description	Default
`isbn`	Yes	The ISBN-13; hyphens and spaces are ignored.

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations provided, the description carries the burden. It discloses that it checks the 978/979 prefix and mod-10 check digit, and returns the expected check digit on failure. This conveys the tool's behavior adequately.

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?

Two sentences, front-loaded with 'USE THIS'. Every word is functional; no fluff.

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?

No output schema exists, but the description explains the return behavior (returns expected check digit on failure). Could mention success return, but sufficient for a validation tool.

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 covers the isbn parameter with description. The description adds 'hyphens and spaces are ignored,' which provides input handling detail 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 'verify an ISBN-13 book identifier' and explains the checks performed (prefix and check digit). It distinguishes from siblings like validate_card, validate_iban, validate_vin which target different identifiers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'USE THIS to verify an ISBN-13 book identifier instead of trusting that 13 digits are correct.' Provides clear context for when to use. Does not explicitly state when not to use, but sibling tools indicate distinct use cases.

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

validate_vinA

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.

ParametersJSON Schema

Name	Required	Description	Default
`vin`	Yes	The 17-character VIN to validate.

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description fully discloses behavior: checks allowed alphabet (no I/O/Q) and ISO 3779 check digit in position 9, and returns expected check digit on failure. No hidden traits.

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?

Two sentences, no wasted words. First sentence gives purpose and usage context, second explains checks and output. Front-loaded with critical guidance.

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?

For a simple validation tool with one parameter and no output schema, the description is largely complete. It explains what it checks and output on failure, though success output (presumably boolean) is implied but not stated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, but the description adds significant meaning beyond 'The 17-character VIN to validate' by explaining validation rules and output behavior.

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 vehicle VIN before acting on it, with a specific verb ('verify') and resource ('VIN'). It distinguishes from sibling tools (validate_card, validate_iban, validate_isbn) by focusing on VINs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises to use before acting, warns against assuming a 17-character string is valid, and describes what checks are performed. Provides clear context but does not explicitly mention when not to use or alternatives.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

4 tool updatesv0.1.0Jun 17, 2026
- First observedvalidate_card
- First observedvalidate_iban
- First observedvalidate_isbn
- First observedvalidate_vin

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.6/5.0

Disambiguation5/5

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.

Naming Consistency5/5

All tools follow a consistent 'validate_<entity>' pattern using snake_case, making the naming predictable and uniform.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

ident-mcp A
io.github.nexus-api-lab
Checksum validation for AI agents: IBAN, ISBN, EAN/GTIN, UUID, ULID. Deterministic, no auth.
Developer Tools
2
Checksum Validator A
com.apished
Validates Luhn, IBAN, ISBN, EAN/UPC, SWIFT/BIC, and EU VAT checksums and formats.
Finance E-commerce & Retail Payments & Billing
61
ibanchecker-mcp A
io.github.koraykoylu
IBAN validation, extraction, format specs and BIC/SWIFT lookup tools for AI assistants.
Finance Payments & Billing
52
SnipgetOAuth
ai.snipget
300+ deterministic data utilities for AI agents: validate, normalize, parse, match, redact.
Developer Tools Data Platforms
1

Related MCP Servers

ibanforge
Databases Finance Legal & Compliance
cammac-creator
A
license
A
quality
A
maintenance
IBAN validation, BIC/SWIFT lookup, SEPA compliance, issuer classification and risk indicators for AI agents. 39K+ bank entries from GLEIF. Supports 75+ countries.
Updated 15 hours ago (2026-09-08 07:59 UTC)
11
477
3
MIT
mcp-europe-business
Legal & Compliance Finance
josemvelez78
F
license
A
quality
D
maintenance
European business compliance suite for AI agents — 28 tools covering tax ID validation (PT, ES, FR, DE, IT, UK, NL), IBAN verification, EU VAT rates, invoice requirements, e-invoicing rules, payment terms, labor calendar helpers, VAT breakdown calculations and invoice schema validation for 18+ European countries.
Updated 4 months ago (2026-05-09 18:28 UTC)
28
-
Qinisoofficial
Security AI & Machine Learning Autonomous Agents
qinisolabs
A
license
A
quality
B
maintenance
The deterministic fact-verification layer for AI agents. Validates the structured facts an agent emits — IBANs, payment cards, VAT and national tax IDs, crypto and bank addresses, domains, emails, phone numbers, securities and academic identifiers, plus dates, currencies and holidays — against checksums and curated authoritative data, not guesses.
Updated 3 months ago (2026-06-22 13:15 UTC)
56
1
Apache 2.0
ibanchecker-mcp
Finance
koraykoylu
A
license
A
quality
B
maintenance
IBAN validation, extraction, format specs, and BIC/SWIFT lookup tools for AI assistants, backed by ibanchecker.cash. Covers 90 countries; no IBAN data is stored.
Updated 19 days ago (2026-08-20 20:44 UTC)
5
79
MIT

Appeared in Searches

EU-Verify Identity or Document Verification Service

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/qinisolabs/veridigit'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

veridigit

Why

Use as an MCP server

Use as a library

Scope

Development

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Qinisoofficial

Appeared in Searches

Latest Blog Posts

MCP directory API