Catch a mistyped barcode, ISBN, VIN, NPI or LEI before a bad identifier corrupts a record.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.7/5 across 3 of 3 tools scored.
Each tool serves a distinct, non-overlapping purpose: compute_luhn_digit constructs a missing check digit, validate_identifier checks a known format, and identify_format determines an unknown format. No ambiguity exists between them.
All tool names follow a consistent verb_noun pattern with lowercase and underscores: compute_, identify_, validate_. This is perfectly predictable.
Three tools is well-scoped for a focused check-digit utility. Each tool is necessary and distinct, covering the core operations without bloat.
The set covers validation, identification, and Luhn check-digit computation. A minor gap is that computation is only offered for Luhn, not for other formats like ISBN or GTIN, but the validation and identification tools cover those formats adequately.
compute_luhn_digitComplete a number that is missing its check digitAGiven digits with the final check digit omitted, return the one that completes them. US healthcare NPIs and securities ISINs use the Luhn formula.
Use it to build valid test fixtures, to recover a last digit that was lost or illegible, or to check an implementation against a reference. To test a number you already have in full, use validate_identifier instead. Input must reduce to digits only once spaces and dashes are stripped; anything else is an error. Payment cards also use Luhn, and are deliberately out of scope here: do not pass card digits, partial or complete. This constructs a well-formed number and nothing more: it does not create, reserve or verify a real provider or security.
| Name | Required | Description | Default |
|---|---|---|---|
| partial | Yes | Digits excluding the final check digit. |
| Name | Required | Description |
|---|---|---|
| partial | Yes | The input digits, echoed back. |
| checkDigit | Yes | The single digit that completes a Luhn-valid string. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), the description discloses input normalization rules (spaces/dashes stripped), error conditions, and that it constructs but does not create/reserve/verify. This adds significant behavioral clarity.
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 front-loaded with the core functionality and every sentence adds value—use cases, alternatives, input constraints, exclusions, and non-behaviors. Well-structured and appropriately sized.
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?
Given the simple single-parameter schema and output schema presence, the description covers input, output intent, error handling, exclusions, and sibling alternatives. It is complete for an AI agent to select and invoke 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?
The schema already covers 'partial' as 'Digits excluding the final check digit' (100% coverage). The description adds value by detailing acceptable input formatting (spaces/dashes stripping) and context (NPI/ISIN uses), but does not drastically expand beyond 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 states a specific verb ('return') and resource ('the one that completes them'), clearly distinguishing it from validate_identifier. It also clarifies the Luhn formula use cases (NPI, ISIN) and what it does not do.
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 provides when to use (build test fixtures, recover lost digit, check implementation) and directs to validate_identifier for full-number testing. Also excludes payment cards, giving clear boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
identify_formatWork out what an unlabeled number isAIdentify a bare number whose type was never recorded. Tests it against every supported format and reports which ones its check digit satisfies. Use it for an unlabeled spreadsheet column, a value pulled out of a log line or a scanned document, or any number handed over without being named.
Reports every format that matches rather than choosing between them. Several matches is normal and does not mean the answer is unclear: some formats are subsets of others, so every ISBN-13 is also a valid EAN-13, and a short value can satisfy two unrelated formats by chance. Read one match as strong evidence and several as a set to narrow from context. As with validation, a match means the arithmetic is consistent, not that the identifier is registered or real.
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | The identifier to classify. |
| Name | Required | Description |
|---|---|---|
| input | Yes | The normalized input that was tested. |
| matched | Yes | Whether any supported format matched. |
| matches | Yes | Every format whose check digit the input satisfies, in registry order. Each entry carries `kind` plus the same format-specific fields validate_identifier returns for that format, such as `country` for an ISIN or `width` for a GTIN. Only satisfied formats are listed, so no entry carries `code` or `reason`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint and openWorldHint. The description goes beyond these by explaining that the tool reports every matching format, that multiple matches are normal and due to format subsets or chance, and that a match only means arithmetic consistency, not real-world registration. This is valuable behavioral context not present in the 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?
The description is well-structured and concise, around 150 words. It front-loads purpose, then provides usage examples, then clarifies behavioral nuances. Every sentence earns its place—no fluff or repetition of schema fields.
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?
Given the tool's moderate complexity, the presence of an output schema (so return values are covered), and annotations, the description is complete: it explains what it does, when to use it, how to interpret results, and the limitations of matches. It leaves no critical gaps for an agent to select and invoke the tool.
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% (one parameter with a clear description). The description does not add extra parameter semantics beyond calling it an 'unlabeled number' and an 'identifier', which aligns with the schema. Baseline 3 is appropriate because the schema already fully covers the parameter.
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 identifies a bare/unlabeled number by testing it against every supported format and reporting which check digit validates. This specific verb-resource pairing distinguishes it from siblings like validate_identifier (which presumably validates a known format) and compute_luhn_digit (which computes a digit).
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?
Provides explicit use cases: 'unlabeled spreadsheet column, a value pulled out of a log line or a scanned document, or any number handed over without being named.' This clearly indicates when to use the tool. It does not explicitly mention alternatives or when not to use it, but the 'unlabeled' framing plus sibling tool names imply validate_identifier is for known formats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_identifierCheck whether an identifier is mistypedAVerify a number when you already know what it is supposed to be. Use this whenever someone gives you a product barcode (GTIN, UPC or EAN), a book number (ISBN-10 or ISBN-13), a vehicle VIN, a US healthcare provider NPI, a security ISIN, or a legal entity LEI, and acting on a wrong one would cost something: a bounced claim, a rejected listing, a record that quietly corrupts a dataset.
Every supported format is a public identifier. Bank accounts, IBANs, routing numbers and payment cards are not supported and must not be sent.
Returns whether the checksum passes and, when it fails, the specific reason. If you do not already know the format, call identify_format first rather than guessing a kind, since a valid identifier checked against the wrong format comes back invalid. A passing checksum proves only that the digits are internally consistent: it does not mean the book, product, vehicle or provider exists, is active, or belongs to any particular person.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | Which identifier format to validate against. | |
| value | Yes | The identifier to check. Spaces and dashes are ignored. |
| Name | Required | Description |
|---|---|---|
| code | No | Bounded reason the check failed. Absent when valid. |
| valid | Yes | Whether the check digit is arithmetically consistent. |
| width | No | The resolved width of a GTIN. GTIN input only. |
| reason | No | Human-readable detail on the failure. Absent when valid. |
| country | No | ISO country code parsed from the identifier. ISIN only. |
| normalized | No | The input with spaces and dashes removed, upper-cased. |
| actualCheckDigit | No | The digit the VIN actually carries at position 9. VIN only. |
| expectedCheckDigit | No | The digit a VIN should carry at position 9. VIN only. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint and openWorldHint. The description adds substantial context: it returns a specific failure reason, clarifies that a passing checksum proves only internal consistency (not existence/activity/ownership), and notes the risk of validating against the wrong format. This goes well beyond the 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?
The description is three paragraphs, but every sentence carries meaningful information: purpose, exclusions, return behavior, and caveats. It is well-organized and front-loaded with the core action, though slightly longer than strictly necessary.
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?
Given the tool's complexity (validation across many formats), the description covers all critical aspects: supported formats, excluded formats, when to use an alternative tool, return value semantics, and limitations. The presence of an output schema further reduces the need to describe return structure, making this fully complete for an agent.
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% for both value and kind, so the baseline is 3. The description adds value beyond the schema by warning against guessing 'kind' and pointing to identify_format for unknown formats, which clarifies correct use of the parameter. It doesn't add much about 'value' beyond what the schema mentions (spaces/dashes ignored), but the kind guidance elevates it.
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 opens with a specific action ('Verify a number when you already know what it is supposed to be') and enumerates the exact identifier formats (GTIN, UPC, EAN, ISBN, VIN, NPI, ISIN, LEI). This clearly distinguishes it from the sibling identify_format, which is for unknown formats.
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 gives explicit when-to-use guidance (when a wrong identifier would be costly), lists unsupported formats that must not be sent (bank accounts, IBANs, etc.), and instructs to call identify_format first when the format is unknown. This is model behavior for usage differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
