Loading ToolBench
MCP Server for 4Devs Brazilian document generation API - Generate valid CPF, RG, CNH, PIS, birth certificates, and voter registration numbers
The server defines 6 tools for Brazilian document generation with reasonable schemas and descriptions. All tools have explicit Zod schema definitions (visible in tool-schemas.ts) and descriptions in the test-tools.js. However, naming conventions are inconsistent (Portuguese/English mix, inconsistent verb usage), descriptions are somewhat generic and lack actionable context, and there is no documented output schema for any tool. Parameter descriptions are adequate but could be more specific about format and constraints. No error handling guidance is visible. The tool set is narrow and domain-specific, which is appropriate for a specialized generator, but composition and chaining considerations are absent.
Load list of cities for a Brazilian state (UF). Returns city codes that can be used with gerar_pessoa tool.
Generate valid Brazilian certificate numbers (birth, marriage, death). Returns a formatted certificate number.
Generate a valid Brazilian CNH (driver's license) number. No parameters required.
Generate random Brazilian person data with valid documents (CPF, RG), address, and contact information. Can generate 1-30 people per request.
Generate a valid Brazilian PIS/NIS/PASEP number (social security). Can include punctuation formatting.
Generate a valid Brazilian voter registration number (Título de Eleitor). Can specify state (UF) for state-specific registration.
Inconsistent naming: Mix of Portuguese (gerar_pessoa, carregar_cidades, gerador_certidao, gerar_cnh, gerar_pis, gerar_titulo_eleitor) and English conventions. Tool names do not follow the verb_noun pattern consistently (e.g., 'gerador_certidao' is noun_noun, not verb_noun). This forces LLMs to context-switch between language conventions and makes tool discovery harder.
No documented output schema for any tool. While the tools clearly generate Brazilian documents, the exact structure of returned data is not visible in the schema definitions. LLMs cannot plan downstream calls or know what fields to expect (e.g., does gerar_pessoa return an array of person objects, or a single object, or a string?). This violates the requirement that 'Document the output schema.'
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Missing error handling guidance. No visible error recovery patterns, retry instructions, or actionable error messages. If a tool fails (e.g., invalid state code, network timeout), the response does not guide the LLM on what to do next. This leaves agents stranded on failures.
Weak description for gerar_cnh (40 chars: 'Generate a valid Brazilian CNH (driver\'s license) number. No parameters required.'). This is the bare minimum and does not explain WHEN to use it (vs other doc generators), WHAT it returns, or any context about the CNH itself.
Parameter constraints are expressed as enums but lack explanatory text for non-obvious values. For example, sexo enum ['H', 'M', 'I'] is documented but 'I' for 'random' is not intuitive to all LLMs. The pontuacao enum ['S', 'N'] uses Portuguese abbreviations (Sim/Não) which are not self-documenting.
No composition or chaining support documented. While carregar_cidades returns city codes for use with gerar_pessoa, this relationship is not made explicit in either tool's description. LLMs must infer the connection, increasing reasoning overhead and error likelihood.
Unclear parameter naming: 'txt_qtde' (abbreviated/Portuguese) is unclear compared to 'quantity' or 'count'. Parameter name should be self-documenting; 'txt_' prefix suggests text encoding rather than quantity.