Routes ValidaLatam document validation, normalization, and formatting requests through RapidAPI when RAPIDAPI_KEY is configured, enabling use of RapidAPI keys and plans.
MCP server for the ValidaLatam API — validate, normalize and format Latin American tax IDs, national IDs and bank accounts: AR CUIT/CUIL/DNI/CBU/CVU, BR CPF/CNPJ, MX RFC/CURP/CLABE, CL RUT, CO NIT, PE RUC, UY CI/RUT, EC Cédula/RUC, PY RUC, IBAN.
This is a thin client: every tool call is an HTTP request to the hosted API. No validation algorithms are included here.
API key / plans on RapidAPI: https://rapidapi.com/MatiasPengue/api/validalatam
uvx --from git+https://github.com/elmatis172/validalatam-mcp validalatam-mcp
# or
pip install git+https://github.com/elmatis172/validalatam-mcp
validalatam-mcp(Once published to PyPI: uvx validalatam-mcp / pip install validalatam-mcp.)
claude_desktop_config.json) / Cursor (~/.cursor/mcp.json){
"mcpServers": {
"validalatam": {
"command": "uvx",
"args": ["--from", "git+https://github.com/elmatis172/validalatam-mcp", "validalatam-mcp"],
"env": { "RAPIDAPI_KEY": "optional-your-key" }
}
}
}validate_document(type, value, country?) — type="AUTO" auto-detects
validate_batch(items) — up to 1000 {type, value, country?}
generate_test_data(type, count, seed) — clearly fake, check-digit-valid values
list_document_types()
Env var | Default | Purpose |
| – | If set, calls go through RapidAPI ( |
|
| Override API base URL |
docker build -t validalatam-mcp . && docker run -i --rm validalatam-mcpZero-dependency clients in sdks/python/validalatam_client.py and sdks/js/index.mjs.
pip install -e ".[test]" && pytestRelated MCP server: LATAM Intelligence MCP
Servidor MCP para la API ValidaLatam: valida, normaliza y formatea CUIT/CUIL, DNI, CBU/CVU, CPF, CNPJ, RFC, CURP, CLABE, RUT, NIT, RUC, CI, cédulas e IBAN. Es un cliente liviano: cada herramienta llama por HTTP a la API alojada; no incluye los algoritmos de validación.
Clave de API y planes en RapidAPI: https://rapidapi.com/MatiasPengue/api/validalatam
uvx --from git+https://github.com/elmatis172/validalatam-mcp validalatam-mcp
# o
pip install git+https://github.com/elmatis172/validalatam-mcpUsá el mismo bloque JSON de arriba en claude_desktop_config.json o ~/.cursor/mcp.json. RAPIDAPI_KEY es opcional.
validate_document, validate_batch, generate_test_data (datos FALSOS de prueba), list_document_types.
MIT
Generate clearly FAKE, check-digit-valid test values for a document type.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | ||
| type | Yes | ||
| count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose two important traits: values are obviously fake (safe for non-production use) and check-digit-valid (they will pass validation). It says nothing about determinism behavior, whether the operation writes or reads, or rate/identity constraints.
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?
A single tight sentence with the most important qualifier ('clearly FAKE') front-loaded. Nothing is wasted, though it is arguably too short given how much parameter explanation is missing.
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?
No output schema, no annotations, and 0% parameter documentation mean the description should do more. It never explains what is returned (a list of 'count' values?), how 'seed' affects reproducibility, or which document types are valid.
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 description coverage is 0%, so the description must compensate and largely does not. 'For a document type' weakly gestures at the required 'type' parameter, but 'seed' and 'count' are entirely unexplained in both schema and description, leaving determinism and result-size semantics opaque.
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?
States a specific verb (Generate) and resource (test values for a document type), and the qualifiers 'clearly FAKE' and 'check-digit-valid' pin down the nature of the output precisely. It is distinguishable from the validate_* and list_document_types siblings, though it never names them.
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?
There is no explicit when-to-use or when-not guidance, and no named alternatives. The agent must infer that this is the counterpart to validate_document when a testing scenario needs synthetic data, which is a reasonable but unstated inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List supported document type codes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, but the description's 'List supported' phrasing makes the read-only, non-destructive nature clear. It omits anything about auth requirements, caching, or the exact shape of the returned codes, so for a no-annotation tool it is adequate rather than rich.
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?
A single front-loaded sentence with no filler. Every word earns its place.
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 trivial zero-param enumeration with no output schema, the description effectively tells the agent what is returned (supported type codes). It does not explain whether codes come with labels or descriptions, a minor gap given the tool's simplicity.
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 tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for 0 params applies.
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?
States a specific verb (List) and resource (supported document type codes), so the agent knows exactly what comes back. It does not explicitly contrast itself with siblings like validate_document, so it falls short of a 5.
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?
No when-to-use guidance is given. It is only implied that an agent would call this to discover valid codes before calling validate_document, but nothing in the text says so or names the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate up to 1000 items, each {type, value, country?}.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, yet it only discloses the 1000-item limit. It says nothing about what validation checks happen, whether partial failures are allowed, error reporting, or idempotency for a batch operation.
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?
A single, front-loaded sentence with no filler, and the 1000-item constraint and item shape are efficiently packed. It is compact rather than wasteful, though sparse.
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 validation tool with no annotations and no output schema, the agent needs to know what a validation result looks like and how failures surface; neither is described. The 1-param schema is thin, so the description should carry more than it does.
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 0% and the items schema is a bare object with additionalProperties:true, so the description's inline item shape {type, value, country?} does add real meaning. But it omits what 'type' values are legal, what 'value' formats are accepted, and the meaning of the optional country, so the compensation is partial.
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?
States a specific verb ('Validate') and a quantified resource ('up to 1000 items'), which is clearer than a bare tautology. However, it never distinguishes itself from the sibling validate_document, leaving the agent to guess whether batch vs document is the deciding factor.
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?
No explicit when-to-use, when-not-to-use, or alternative is given. The 'up to 1000 items' hints at bulk usage, but there is no statement about choosing this over validate_document.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate/normalize/format a LatAm document (AR_CUIT, BR_CPF, BR_CNPJ, MX_RFC, MX_CURP, CL_RUT, CO_NIT, PE_RUC, IBAN...). type='AUTO' auto-detects.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | ||
| value | Yes | ||
| country | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It doesn't state what validation means (e.g., returns boolean, normalized string, error details), whether it's read-only, what happens on invalid input, or if there are rate limits. Minimal behavioral disclosure beyond the operation name.
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 compact sentences: first states purpose and enumerates types, second gives a key parameter hint. Front-loaded and zero waste.
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 3 parameters at 0% schema coverage and no annotations or output schema, the description is insufficient. It doesn't explain 'value' or 'country', lacks behavioral details, and provides no return value information despite no output schema.
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 0%, so parameters are undocumented in both schema and description. The description only hints at 'type' via the AUTO example; 'value' and 'country' are completely unexplained. Does not compensate for the coverage gap.
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?
States clear verb triad (validate/normalize/format) and specific resource (LatAm document), plus enumerates supported document types. Distinguishes from siblings like validate_batch by being single-document focused, though it doesn't explicitly say so.
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?
Mentions type='AUTO' auto-detects, which implies usage guidance for one parameter. However, no explicit when-to-use vs validate_batch or list_document_types, and no exclusions or prerequisites.
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.0generate_test_datalist_document_typesvalidate_batchvalidate_documentScored across 4 tools
Each tool has a clearly distinct purpose: single validation, batch validation, test data generation, and listing supported types. There is no overlap in functionality or ambiguity about when to use each tool.
All tool names follow a consistent verb_noun pattern: validate_document, validate_batch, generate_test_data, list_document_types. The pattern is predictable and easy to understand.
With only 4 tools, the set is well-scoped and each tool serves a clear, non-redundant purpose. The count is appropriate for a focused validation service.
The tools cover the full lifecycle of document validation: discovery of types, single validation with normalization/formatting, batch validation for bulk needs, and generation of test data. No obvious gaps exist for the stated purpose.
LatAm Validate MCP — validate Latin-American banking and tax identifiers.
Validates Luhn, IBAN, ISBN, EAN/UPC, SWIFT/BIC, and EU VAT checksums and formats.
Argentina CUIT/CUIL validation and AFIP fiscal QR generation. Pure, no-auth MCP tools.
Validates Polish PESEL, NIP, and REGON checksums; PESEL also decodes birth date and sex.