mx-fiscal-mcp-server

Overview Schema Source Related Servers Score Discussions Admin

Generate Mexican Test Data

generate_test_data

Read-onlyIdempotent

Generate structurally valid Mexican RFC, CURP, CLABE and NSS test data for fixtures, seeds and demos. Creates coherent people or companies without using real records.

Instructions

Generate structurally valid Mexican identifiers for fixtures, database seeds and demos — generated, not taken from any real record.

For a person each record carries a coherent set: the RFC and the CURP are derived from the same name, sex, birth date and state, the CLABE's bank code is a real Banxico participant, and the NSS satisfies its Luhn digit. For a company, a razón social with a matching persona-moral RFC and a CLABE.

Why generated instead of hand-written: an RFC or CURP typed by hand almost never satisfies its check digit, so it fails the first validation your own code runs, and a seed file full of 'AAAA010101AAA' teaches your tests nothing.

These pass validation but are nobody's on purpose. They are generated from common names, so a CURP or phone number can coincide with a real person's by chance; they are not looked up at the SAT, RENAPO, IMSS or Banxico — do not send them to the SAT's status service or to a PAC.

Args:

kind ('person' | 'company'): what to generate (default 'person').
count (integer 1-100): how many records (default 1).
response_format ('markdown' | 'json'): output format (default 'markdown').

Returns: { kind, count, people[{nombre, apellido_paterno, apellido_materno, sexo, fecha_nacimiento, entidad, entidad_nombre, rfc, curp, clabe, banco, nss, codigo_postal, telefono, email}], companies[{razon_social, rfc, clabe, banco, codigo_postal, fecha_constitucion}], findings[] }.

Example: "Give me 5 fake Mexican customers with valid RFC and CURP" -> generate_test_data(kind="person", count=5).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`kind`	No	'person' for individuals (RFC + CURP + CLABE + NSS), 'company' for personas morales.	person
`count`	No	How many records to generate, 1-100.
`response_format`	No	Output format: 'markdown' for a human-readable summary (default) or 'json' for the full structured payload.	markdown

Output Schema

TableJSON Schema

Name	Required	Description	Default
`kind`	Yes
`count`	Yes
`people`	Yes
`findings`	Yes
`companies`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Sep 11, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Well beyond the readOnly/idempotent/non-destructive annotations, it discloses that records are synthetic, that CURPs or phone numbers can coincide with a real person by chance, and that values are not checked against SAT, RENAPO, IMSS or Banxico. It also guarantees internal coherence (RFC and CURP derived from the same name/sex/date/state, real Banxico bank code, NSS passing Luhn), which materially affects how an agent should trust the output.

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?

Front-loaded with the core purpose, then a rationale paragraph, Args, Returns and an example — a logical structure. The Args list duplicates a fully-covered schema and the Returns block restates an existing output schema, so a few sentences do not earn their place, but the disclaimers and example do.

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?

For a generation tool with an output schema, zero required parameters and simple enums, the description is complete: it covers what is produced, per-kind composition, non-realism caveats and a worked example. Nothing an agent needs to call it correctly is missing.

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 coverage is 100%, so the Args section largely restates what the schema already documents (kind, count bounds, format defaults). The description adds only marginal semantics — e.g. that a person record bundles RFC+CURP+CLABE+NSS — while the enum meanings remain schema-owned, so baseline 3 is appropriate.

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 pairs a specific verb (generate) with a precise resource (structurally valid Mexican identifiers) and immediately scopes it to fixtures, seeds and demos. It distinguishes itself from the validate_* siblings by stressing that output is generated, not looked up or verified against real registries.

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 names the use cases (fixtures, database seeds, demos) and gives a clear negative condition — do not send the results to the SAT status service or a PAC. It does not explicitly route the agent to validate_rfc/validate_curp/validate_clabe for verification, so the alternative-selection guidance is implied rather than stated.

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

Install Server