Skip to main content
Glama

validar_documento

Validate Brazilian CPF or CNPJ numbers offline by checking verifier digits, auto-detecting type, and returning the formatted document before registration.

Instructions

Valida um CPF ou CNPJ brasileiro (dígitos verificadores) e retorna o documento formatado. Detecta automaticamente o tipo pelo número de dígitos. Funciona totalmente offline, sem consultar APIs externas. Use quando precisar checar se um número de documento informado pelo usuário é válido antes de prosseguir com um cadastro.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
documentoYesNúmero de CPF ou CNPJ, com ou sem máscara (pontos, traço, barra).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/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 the validation algorithm (check digits), automatic type detection by digit count, and that it is fully offline with no external API calls. The main gap is that it never states what happens on an invalid input (error vs. flag), which matters for a validator.

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?

Four short sentences, front-loaded with what the tool does, then behavior, then the usage trigger. No filler or restatement of the tool name.

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 one-parameter validator with no annotations and no output schema, the description covers purpose, mechanism, input flexibility, and return shape ('retorna o documento formatado'). The only missing piece is failure/invalid-input behavior, which an agent would likely need when gating a registration flow.

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 description coverage is 100% for the single 'documento' parameter, so the schema already documents mask tolerance. The description adds indirect value by explaining that type (CPF vs CNPJ) is auto-detected from digit count, meaning no type parameter is needed, but this is a baseline-level contribution.

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 states a precise verb and resource ('Valida um CPF ou CNPJ brasileiro'), names the exact mechanism (dígitos verificadores) and adds that it returns the formatted document. An agent can immediately tell this is an offline identifier validator rather than a lookup or formatter.

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 gives an explicit trigger condition: 'Use quando precisar checar se um número de documento informado pelo usuário é válido antes de prosseguir com um cadastro.' That is clear when-to-use guidance, though it offers no exclusions or alternative tools (none exist as siblings).

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