Skip to main content
Glama

Check Digit Validator

by com.gumballtools

Check Digit Validator

run
Read-only

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
inputYesThe number to check, e.g. "DE89370400440532013000". Spaces and hyphens are stripped automatically; anything else must match the declared format exactly.
formatYesWhich 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.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses concrete behavior: spaces/hyphens are stripped automatically, format is never auto-detected, certain inputs are refused, and ambiguous single-digit repair candidates are reported honestly as a list. This is exactly the kind of behavioral context an agent needs.

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

Conciseness4/5

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

The description is long, but it is front-loaded with purpose and organized into motivation, an important caveat, input semantics, and refusal behavior. Some of the expository reasoning could be tightened, but most sentences earn their place given the tool's complexity.

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?

The description covers all invocation-critical details: supported formats, required parameters, normalization, refusal conditions, and ambiguous failure output. However, with no output schema, it does not specify the exact response shape or fields, leaving a minor gap for an agent trying to consume the result programmatically.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description restates the key parameter constraints (input normalization, required format, no auto-detection) but does not add substantive semantic detail beyond what the input schema already provides.

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 opens with a specific action ('Validate the check digit(s)' on a defined list of formats) and immediately adds the failure-localization behavior. This gives a clear, distinct purpose even without sibling tools to contrast against.

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?

It explicitly tells the agent to 'Use this instead of computing the checksum yourself' and explains why, which is strong usage guidance. It also states what the tool refuses to do and clarifies that a passing checksum is only a syntax check, so agents know its limitations.

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

All Check Digit Validator toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0
Disambiguation5/5

With only one tool, there is no possibility of ambiguity or misselection. The tool's purpose is clearly restricted to check-digit validation and repair.

Naming Consistency4/5

A single tool means there is no set-wide inconsistency to penalize, and 'run' is an acceptable imperative entry-point name. However, it is generic and does not itself indicate the domain, so it falls just short of a perfect score.

Tool Count5/5

The tool count is well-scoped for a single-purpose validator server. One parameterized tool covers the entire validation surface without feeling trivial or artificially expanded.

Completeness5/5

The tool covers all the major check-digit formats, includes error repair logic, and explicitly refuses malformed input. There are no obvious missing operations for the stated domain.

Resources