National ID & Tax ID Validator MCP

Overview Schema Source Related Servers Discussions Admin

validate_ids

Checks and decodes national IDs, tax IDs, company/VAT numbers, passports, and MRZ data to return matching ID types, checksum status, formatted layouts, and encoded fields (birth date, sex, region).

Instructions

Validate and decode ID numbers: national IDs, tax IDs, company and VAT numbers, passport numbers or MRZ.

Every ID type a value fits is returned, checksum-verified ones first, with the number's formatted layout and the fields it encodes (birth date, sex, region...). Without a hint, valid is null: one string can be a valid number in several countries. With country (ISO alpha-3, e.g. "POL") or an exact type (e.g. "pol_pesel", from an earlier result) only those types are tried and valid is true or false (null where the country's IDs have no checksum). Offline validation only: valid means correctly built, not that the document exists.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "values": "<values>"
    },
    "name": "validate_ids"
  }
}

Input Schema

Name	Required	Description	Default
`type`	No
`values`	Yes
`country`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 9, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses that all matching ID types are returned, checksum-verified ones first, along with formatting and encoded fields. It also explains the ambiguity of `valid` without a hint and the null case when no checksum exists. It does not cover error handling or rate limits, but core behavior is clear.

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?

The description is front-loaded with purpose, then moves logically through return behavior, hint behavior, and the offline-validation caveat. The sentences are dense but every clause conveys useful information without filler.

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 three-parameter validation tool with an output schema and no annotations, the description covers the important operational semantics: ambiguity handling, hint narrowing, checksum ordering, and offline scope. Minor gaps around invalid-input errors and full `values` semantics are tolerable given the output schema and simple parameter set.

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 description coverage is 0%, so the description must compensate. It explains that `country` expects ISO alpha-3 codes and `type` expects exact types from earlier results, which is valuable semantic detail. It does not explicitly describe the `values` array, but the surrounding context makes its role clear enough.

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 starts with a specific verb pair (validate and decode) and names the resource precisely: national IDs, tax IDs, company/VAT numbers, passport numbers, and MRZ. It is clear what the tool does without needing the schema.

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?

It explains the key usage distinction: without a hint, multiple matches may occur and `valid` is null; with `country` or exact `type`, validation narrows to those types. It also states the important limitation that validation is offline and does not confirm document existence. It does not name alternatives, but no siblings are provided.

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

Deploy Server

Other Tools

validate_idsA