Skip to main content
Glama
OrtaMarco

mx-fiscal-mcp-server

by OrtaMarco

Validate CURP

validate_curp
Read-onlyIdempotent

Validate an 18-character Mexican CURP and decode its birth date, sex, birth state, and century marker while checking the RENAPO check digit.

Instructions

Validate a Mexican CURP (Clave Única de Registro de Población) — the 18-character population ID issued by RENAPO — and decode everything it encodes: birth date, sex, state of birth and the century marker.

The 18th character is a base-37 modulus-10 check digit over the first 17, and this checks it. Two details it gets right that a regex does not:

  • The state keys are RENAPO's own. 'DF' is Ciudad de México, 'MC' is Estado de México, 'NE' means born abroad. They do not match the INEGI or ISO 3166-2:MX codes, so a lookup against those tables silently mislabels people.

  • The homoclave character carries the century. A digit (position 17) means born before 2000; a letter means from 2000 onwards. Without it, positions 5-10 ('99' as a year) are ambiguous.

Names that would spell one of RENAPO's inconvenient words are flagged: a real CURP carries an X in the second position instead.

Structural validity is not registration. Only RENAPO can confirm a CURP belongs to a real person, and this server never asks it.

Args:

  • value (string): the CURP. Spaces, dashes and lower case are normalised away.

  • response_format ('markdown' | 'json'): output format (default 'markdown').

Returns: { input, normalized, valid, parts{...}, birth_date, sex, sex_label, state_key, state_name, century_marker, expected_check_digit, errors[{code, message}], findings[] }.

Example: "Decode BOXW310820HNERXN09" -> validate_curp(value="BOXW310820HNERXN09").

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
valueYesThe CURP to validate, e.g. 'BOXW310820HNERXN09'.
response_formatNoOutput format: 'markdown' for a human-readable summary (default) or 'json' for the full structured payload.markdown

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
sexYes
inputYes
partsYes
validYes
errorsYes
findingsYes
sex_labelYes
state_keyYes
birth_dateYes
normalizedYes
state_nameYes
century_markerYes
expected_check_digitYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare a safe, idempotent, closed-world read, so the description correctly focuses on behavior beyond that: input normalization (spaces, dashes, lowercase stripped), the base-37 modulus-10 check-digit algorithm, and the explicit limitation that it never contacts RENAPO to confirm registration.

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 structured with bullets and an example. It is on the long side and the RENAPO-table trivia is dense, but every element (state keys, century marker, exclusion word X rule) aids correct interpretation, so little is wasted.

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?

An output schema exists so return values need not be explained, yet the description still gives the decoded shape and an end-to-end example call. Nothing an agent needs to select or invoke this validator correctly is missing.

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 coverage is 100%, so the baseline is 3, but the description adds real semantics the schema lacks — that the CURP value is normalised (spaces, dashes, case-insensitivity) before validation — plus a worked example input.

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?

States a specific verb (validate) and resource (Mexican CURP, defined as the 18-character RENAPO population ID) plus the secondary decode behavior. An agent can distinguish this from validate_clabe, validate_nss and validate_rfc purely from the resource named.

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?

Explains the context clearly, including the crucial 'structural validity is not registration' caveat and the cases (state keys, century marker) where a naive regex approach fails. It does not explicitly name a sibling or state when-not-to-use, so it falls short of a 5.

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