Skip to main content
Glama
afialho

MCP Dev Tools

by afialho

cpf_utils

Generate, validate, and format Brazilian CPF numbers for testing, data prep, or document verification.

Instructions

Utilitários para CPF: gerar, validar e formatar CPFs brasileiros

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cpfsNoLista de CPFs para validar/formatar (não usado em gerar)
formatoNoFormato de saída: com máscara (000.000.000-00) ou semcom_mascara
operacaoYesOperação a realizar: gerar, validar ou formatar CPFs
quantidadeNoQuantidade de CPFs para gerar (apenas para operação gerar)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.8.0

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It names the operations but says nothing about permissions, rate limits, reversibility, return values, or error behavior for validation.

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?

Single front-loaded sentence with no filler, and every word earns its place. It is arguably too terse for a multi-operation utility, but the conciseness dimension rewards brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With four parameters, no annotations, and no output schema, the one-line description is not complete. It does not explain what gerar/validar/formatar return or how to interpret results, leaving significant gaps for an agent.

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 schema already documents all four parameters including enums and defaults. The description adds no parameter details beyond restating the operations, matching the baseline for full schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States the resource (CPF) and three concrete operations (gerar, validar, formatar), so the agent knows what the tool does. It does not explicitly differentiate from sibling cnpj_utils, but the CPF resource is clear enough.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Only lists operations; no guidance on when to choose each operation, no prerequisites, and no alternatives to this tool. The agent must infer usage from the schema enum alone.

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