How do I use br-docs-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@br-docs-mcp Validate CPF 529.982.247-25" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

br-docs-mcp

by Mouraovicente

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

br-docs-mcp

Servidor MCP (Model Context Protocol) para validação e geração de documentos brasileiros: CPF, CNPJ e boleto bancário.

O que é

Uma implementação de servidor MCP que expõe 6 ferramentas para validar e gerar documentos brasileiros. Implementa os algoritmos de validação (módulo 11 para CPF e CNPJ, módulo 10 e 11 para boleto) e permite que clientes MCP (Claude, Cursor, etc.) utilizem essas funcionalidades via chamadas de ferramentas.

Related MCP server: mcp-server-brasil

Funcionalidades e Tecnologias

Funcionalidade	Descrição	Tecnologia
Validação de CPF	Valida CPF com algoritmo mod11, aceita formatado e bruto	TypeScript
Geração de CPF	Gera CPF válido e aleatório	Pure logic
Validação de CNPJ	Valida CNPJ com pesos mod11 específicos	TypeScript
Geração de CNPJ	Gera CNPJ válido e aleatório	Pure logic
Validação de Boleto	Valida linha digitável (47 dígitos, layout FEBRABAN): mod10 nos 3 campos + DV geral mod11 na posição 33	TypeScript
Parse de Boleto	Extrai banco, valor e vencimento via fator de vencimento (com rollover de 22/02/2025)	Pure logic
MCP Tools	Expõe 6 ferramentas via Model Context Protocol	@modelcontextprotocol/sdk
MCP Resource	`docs://validation-rules` com a documentação dos algoritmos	Markdown
MCP Prompt	`audit_customer_record` para auditar cadastros usando as tools	Template
Testes	40 testes, incluindo E2E MCP real (Client ↔ Server via InMemoryTransport)	Vitest
Clean Architecture	Lógica pura separada da camada MCP	src/domain

Arquitetura

graph TB
    subgraph Client["Cliente MCP (Claude, Cursor)"]
        A["Chamada de Tool<br/>ou Leitura de Resource"]
    end
    
    subgraph Transport["Transporte"]
        B["Stdio Transport<br/>JSON-RPC 2.0"]
    end
    
    subgraph Server["br-docs-mcp Server"]
        C1["Tool: validate_cpf"]
        C2["Tool: generate_cpf"]
        C3["Tool: validate_cnpj"]
        C4["Tool: generate_cnpj"]
        C5["Tool: validate_boleto"]
        C6["Tool: parse_boleto"]
        C7["Resource: docs://validation-rules"]
        C8["Prompt: audit_customer_record"]
    end
    
    subgraph Domain["Lógica Pura"]
        D1["src/domain/cpf.ts"]
        D2["src/domain/cnpj.ts"]
        D3["src/domain/boleto.ts"]
    end
    
    A --> B --> C1
    C1 --> D1
    C2 --> D1
    C3 --> D2
    C4 --> D2
    C5 --> D3
    C6 --> D3
    
    style Domain fill:#e1f5ff
    style Server fill:#f3e5f5
    style Transport fill:#fff3e0

Como rodar

Pré-requisitos

Node.js >= 20

Instalação

npm install

Desenvolvimento

npm run dev

Build

npm run build

Saída em dist/index.js com shebang, pronto para uso via npx br-docs-mcp.

Como testar

Rodar testes

npm test

Modo watch

npm run test:watch

Type check

npm run type-check

Todos os 40 testes rodam 100% offline e cobrem:

Validação de CPF/CNPJ formatado e bruto
Rejeição de dígito verificador errado, comprimento inválido, dígitos repetidos
Roundtrip gerar → validar (20 iterações para CPF e CNPJ)
Boleto: linha válida construída nos testes (com mod10/mod11 independentes), campos corrompidos, DV geral errado
Parse de boleto: banco, valor e vencimento — incluindo o rollover do fator (1000 = 22/02/2025) e fator 0000 (sem vencimento)
E2E MCP real: Client e McpServer conectados por InMemoryTransport.createLinkedPair(), listando as 6 tools, chamando validate_cpf, lendo o resource e obtendo o prompt

Uso com clientes MCP

Configuração no Claude Desktop / Cursor

Adicione a entrada no mcp.json:

{
  "mcpServers": {
    "br-docs-mcp": {
      "command": "npx",
      "args": ["br-docs-mcp"]
    }
  }
}

Exemplo de chamada

{
  "name": "validate_cpf",
  "arguments": {
    "cpf": "529.982.247-25"
  }
}

Resposta:

{
  "valid": true
}

Ferramentas disponíveis

validate_cpf - Valida CPF → { "valid": true } ou { "valid": false, "reason": "check digit mismatch" }
generate_cpf - Gera CPF válido → { "cpf": "..." }
validate_cnpj - Valida CNPJ
generate_cnpj - Gera CNPJ válido
validate_boleto - Valida linha digitável de boleto
parse_boleto - Extrai dados do boleto → { "bankCode": "001", "amount": 1500, "dueDate": "2025-02-22" }

Resource disponível

docs://validation-rules - Documentação dos algoritmos

Prompt disponível

audit_customer_record - Audita registros de clientes usando as tools

Estrutura do projeto

.
├── src/
│   ├── domain/
│   │   ├── cpf.ts          # Lógica pura de CPF
│   │   ├── cnpj.ts         # Lógica pura de CNPJ
│   │   └── boleto.ts       # Lógica pura de boleto (layout FEBRABAN)
│   ├── server.ts           # Servidor MCP (tools, resource, prompt)
│   ├── validation-rules.ts # Markdown servido pelo resource
│   └── index.ts            # Entrypoint stdio (#!/usr/bin/env node)
├── tests/
│   ├── domain/
│   │   ├── cpf.test.ts
│   │   ├── cnpj.test.ts
│   │   └── boleto.test.ts
│   └── e2e/
│       └── server.test.ts
├── package.json            # bin: br-docs-mcp → dist/index.js
├── tsconfig.json
├── vitest.config.ts
├── README.md               # Este arquivo
├── LICENSE                 # MIT
└── .gitignore

Publicação no npm

Build e teste

npm run type-check
npm test
npm run build

Publicar

npm publish

O script prepublishOnly garante que testes e build passam antes de publicar.

Origem

Inspirado em conceitos do curso de pós-graduação em Engenharia de Software com IA Aplicada — implementação própria do zero, usando TypeScript e clean architecture para demonstrar:

Design domain-driven
Separação de responsabilidades (domain vs. transport)
Algoritmos de validação (mod11, mod10)
Model Context Protocol (MCP)
Test-driven development com Vitest
Empacotamento npm com tipos

Licença

Available Tools

6 tools

generate_cnpjA

Gera um CNPJ válido aleatório. Use formatted=true para "XX.XXX.XXX/XXXX-XX".

ParametersJSON Schema

Name	Required	Description	Default
`formatted`	No	Retornar com pontuação (padrão: false)

TDQS

A4.5/5.0

Behavior4/5

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

No annotations are provided, so the description carries the burden. It discloses the core behavior (generates a random valid CNPJ) and the formatting option. For a simple generator, this is adequate, though it could explicitly state return type or absence of side effects.

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?

The description is a single, front-loaded sentence with no fluff. It states the purpose first, then the optional formatting detail. Every word earns its place.

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 tool with one optional parameter and no output schema, the description fully covers what it does and how to use the parameter. It doesn't need to explain return values because the output is implied by 'gera um CNPJ'. The sibling context further clarifies its role.

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?

The schema already describes the 'formatted' parameter with 100% coverage, but the description adds the exact mask 'XX.XXX.XXX/XXXX-XX', which is more specific than the schema's 'Retornar com pontuação'. This adds valuable meaning beyond the schema.

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 clearly states it generates a valid random CNPJ, using the specific verb 'Gera' (generates) and the resource 'CNPJ'. It also includes the optional formatted output format, distinguishing it from sibling validation tools.

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?

The intent is clear: use when you need a random valid CNPJ, as opposed to validation tools like validate_cnpj. It doesn't explicitly mention alternatives, but the context is unambiguous for an agent.

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

generate_cpfA

Gera um CPF válido aleatório. Use formatted=true para "XXX.XXX.XXX-XX".

ParametersJSON Schema

Name	Required	Description	Default
`formatted`	No	Retornar com pontuação (padrão: false)

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description bears the burden of disclosing behavior. It mentions the generation of a valid random CPF and the formatting option, which covers the core behavior. However, it does not mention the return type or any potential edge cases, leaving some transparency gaps.

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?

The description is a single, concise sentence that delivers purpose and a parameter hint without any fluff. It is well-structured and front-loaded, making it easy to parse.

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?

Given the tool's low complexity (one optional parameter, no output schema), the description provides sufficient context for basic usage. It explains the main function and the parameter's effect. The lack of an explicit return format is minor since the tool's purpose implies the return is a CPF string.

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?

The input schema fully describes the 'formatted' parameter (100% coverage), but the tool description adds a concrete example ('XXX.XXX.XXX-XX') that clarifies the visual output beyond the schema's generic 'Retornar com pontuação'. This extra context enhances parameter understanding.

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 clearly states a specific action ('Gera') and resource ('CPF válido aleatório'), distinguishing it from siblings like validate_cpf and generate_cnpj. The purpose is unambiguous.

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?

The description does not provide any guidance on when to use this tool versus alternatives. The only usage hint ('Use formatted=true') is about parameter formatting, not about tool selection.

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

parse_boletoA

Extrai código do banco, valor (R$) e data de vencimento da linha digitável de um boleto. Falha com mensagem clara se a linha for inválida.

ParametersJSON Schema

Name	Required	Description	Default
`linha_digitavel`	Yes	Linha digitável com 47 dígitos, com ou sem pontuação

TDQS

A4/5.0

Behavior4/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 of behavioral disclosure. It explicitly states the failure behavior for invalid lines and lists the extracted fields, which is useful transparency. It could add more detail about input normalization or output format, but for a simple parse, this is adequate.

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?

The description is a single sentence that front-loads the core action and ends with error handling. Every phrase earns its place with no wasted words, making it highly concise and structured.

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?

Given the tool has only one parameter and no output schema, the description covers the essential fields (bank code, amount, due date) and error behavior. It could be more explicit about the return structure (e.g., object keys), but the clarity of extracted fields makes it complete enough for a simple parse tool.

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 only parameter 'linha_digitavel', which is documented as a 47-digit line with or without punctuation. The description does not add extra meaning beyond the schema, 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 clearly states the tool extracts bank code, amount (R$), and due date from the digitizable line of a boleto. This specific verb+resource+output set distinguishes it from sibling validate_boleto, which presumably only validates.

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

Usage Guidelines3/5

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

The description implies usage for extracting boleto fields via 'Extrai', but does not explicitly mention alternatives like validate_boleto or explain when to prefer this tool over validation. The error behavior ('Falha com mensagem clara se a linha for inválida') hints that validation might be separate, but no clear when/when-not guidance is given.

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

validate_boletoA

Valida a linha digitável de um boleto bancário (47 dígitos, aceita pontuação). Confere o mod 10 dos 3 campos e o DV geral mod 11. Retorna { valid } e { reason } quando inválido.

ParametersJSON Schema

Name	Required	Description	Default
`linha_digitavel`	Yes	Linha digitável com 47 dígitos, com ou sem pontuação

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations provided, the description discloses the validation algorithm (mod 10 for fields, mod 11 for DV) and the return structure ({ valid } and { reason } on invalid). It doesn't mention side effects, but this is a read-only validation tool, and the behavior is clearly described.

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?

The description is two concise sentences: the first states the main purpose and input format, the second details the validation logic and return. Every sentence adds value with no redundancy.

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?

Despite having no output schema, the description clearly explains the return format ({ valid } and { reason } when invalid) and the validation approach. After reading, an agent knows exactly when to use it and what to expect, making it complete for its complexity.

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 parameter, already specifying the 47-digit length and optional punctuation. The description adds no additional parameter semantics beyond what the schema provides, matching the baseline score.

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 clearly states the tool validates the readable line of a bank boleto, specifying the 47-digit format and punctuation acceptance. It also details the validation logic (mod 10 and mod 11), distinguishing it from sibling CPF/CNPJ validators and parse_boleto.

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?

The description specifies this tool is for validating a boleto line, with explicit checks and return behavior. While it doesn't name alternative tools, the context of siblings makes it clear this is for boleto validation, not CPF/CNPJ, and parse_boleto handles parsing rather than validation.

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

validate_cnpjA

Valida um CNPJ brasileiro (aceita formatado "11.222.333/0001-81" ou cru). Retorna { valid } e, quando inválido, { reason }.

ParametersJSON Schema

Name	Required	Description	Default
`cnpj`	Yes	CNPJ formatado ou apenas dígitos

TDQS

A4.3/5.0

Behavior4/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 discloses the return object with `valid` and `reason` for invalid cases, and the accepted input formats. It does not detail edge-case behavior, but for a pure validation function this is adequate.

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?

Two short sentences, front-loaded with the verb and resource. No unnecessary detail.

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?

The tool is simple with one parameter and no output schema. The description adequately explains its purpose, input format, and return value, making it complete for an agent to select and invoke correctly.

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?

The input schema already covers the `cnpj` parameter with a description of 'formatado ou apenas dígitos'. The description adds a concrete example ('11.222.333/0001-81') which reinforces the accepted format, but does not add substantial new semantics beyond the schema.

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 clearly states the tool validates a Brazilian CNPJ, specifying accepted input formats (formatted or raw digits) and the return structure. This distinguishes it from sibling tools like validate_cpf (CPF validation) and generate_cnpj (CNPJ generation).

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?

The description implies usage for CNPJ validation, which is clear from the purpose. It does not explicitly mention alternatives or when not to use, but the sibling tool names provide context. Effective for a straightforward validation tool.

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

validate_cpfA

Valida um CPF brasileiro (aceita formatado "529.982.247-25" ou cru "52998224725"). Retorna { valid } e, quando inválido, { reason }.

ParametersJSON Schema

Name	Required	Description	Default
`cpf`	Yes	CPF formatado ou apenas dígitos

TDQS

A4.2/5.0

Behavior3/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 of behavioral disclosure. It discloses the return shape ({ valid } and { reason } when invalid) and input format flexibility, but does not mention whether the tool is side-effect-free, whether it only validates check digits or also checks existence, or what specific reason values are possible. This is adequate but not thorough.

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?

The description is a single sentence that is front-loaded with the action ('Valida um CPF brasileiro') and includes examples and return information without any unnecessary words. Every element earns its place, making it highly efficient.

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 tool with only one parameter, no output schema, and no nested objects, the description is fairly complete. It covers the input format, the validation purpose, and the output structure. The only minor gap is not enumerating possible reason values, but this is not essential for correctly invoking the tool.

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?

The schema already describes the parameter at 100% coverage, but the description adds concrete examples ('529.982.247-25' or '52998224725') and clarifies the two acceptable input formats, which goes beyond the schema's minimal 'CPF formatado ou apenas dígitos' description and adds practical guidance.

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 clearly states the tool 'Valida um CPF brasileiro' (validates a Brazilian CPF), which is a specific verb+resource combination. It also distinguishes itself from sibling tools like generate_cpf and validate_cnpj by specifying validation of CPF specifically, and includes accepted formats to remove ambiguity.

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?

The description provides clear context that this tool is for validating CPFs, making the intended use obvious. However, it does not explicitly mention alternatives or exclusions (e.g., 'for generating CPFs use generate_cpf'), so it lacks explicit when-to-use vs. when-not-to-use guidance, but the context is clear enough.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesv0.1.0Aug 2, 2026
- First observedgenerate_cnpj
- First observedgenerate_cpf
- First observedparse_boleto
- First observedvalidate_boleto
- First observedvalidate_cnpj
- First observedvalidate_cpf

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.3/5.0

Scored 2026-08-02 17:15 across 6 tools

Disambiguation5/5

Each tool targets a distinct document type and action. CPF, CNPJ, and boleto are clearly different domains, and validate vs. generate vs. parse have well-defined boundaries. Even the two boleto tools are unambiguous: one checks validity, the other extracts data.

Naming Consistency5/5

All tool names follow a strict verb_noun pattern in lowercase snake_case: validate_cpf, generate_cpf, validate_cnpj, generate_cnpj, validate_boleto, parse_boleto. The verb (validate/generate/parse) and noun (cpf/cnpj/boleto) are consistent and predictable.

Tool Count5/5

Six tools is well within the ideal 3-15 range and each tool provides a distinct function for Brazilian documents. The count feels neither sparse nor bloated, covering validation, generation, and parsing for three common document types.

Completeness5/5

The surface covers the core lifecycle for each document type: CPF and CNPJ have both generation and validation (with formatted output options), and boleto has validation and parsing. There are no obvious dead ends or missing operations for the stated purpose.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

cristianoaredes-mcp-dadosbrOAuth
ai.smithery
# MCP DadosBR Servidor MCP focado em dados públicos do Brasil. Oferece duas ferramentas simples e…
Government Data Open Data Search
28
Mercado PagoOAuth
com.mercadopago.mcp
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
Finance E-commerce & Retail App Automation
2
Certifier MCP BOAuth
io.certifier
Official MCP server for Certifier to issue, manage, and track certificates and badges.
Education & Learning Tools
2
Bcb Br A
io.github.pipeworx-io
Banco Central do Brasil (Brazil's central bank) MCP.
Finance Government Data Open Data
362

Related MCP Servers

brasil-mcp-essentialsofficial
Developer Tools Payments & Billing
brasil-mcp
A
license
A
quality
C
maintenance
A privacy-first MCP server providing 14 offline Brazilian utilities including document validation, boleto parsing, PIX BR Code generation/parsing, and calendar tools.
Updated 4 months ago (2026-05-22 07:25 UTC)
22
1
MIT
mcp-server-brasil
Finance Government Data Location Services
davi713albano-coder
A
license
A
quality
C
maintenance
Provides tools to query Brazilian CNPJ (company registration), CEP (postal codes), and currency exchange rates (USD and EUR) through an MCP server.
Updated 3 months ago (2026-06-27 14:38 UTC)
3
MIT
Brazilian Dev MCP
Developer Tools
dan94k
A
license
A
quality
D
maintenance
MCP server with tools for Brazilian data like CPF, CNPJ, CEP validation and generation, and currency quotes.
Updated 4 months ago (2026-05-27 02:09 UTC)
7
32 npm
MIT
DevTools-BR MCP Server
Developer Tools
joao-baza
F
license
Not graded
quality
C
maintenance
MCP server for generating and validating Brazilian documents (CPF, CNPJ, CNH, RG, PIS/PASEP, RENAVAM), encoding/decoding data (Base64, MD5, SHA1, URL), and performing text utilities like removing accents, reversing, and analyzing text.
Updated a month ago (2026-08-03 09:42 UTC)
-

br-docs-mcp

O que é

Funcionalidades e Tecnologias

Arquitetura

Como rodar

Pré-requisitos

Instalação

Desenvolvimento

Build

Como testar

Rodar testes

Modo watch

Type check

Uso com clientes MCP

Configuração no Claude Desktop / Cursor

Exemplo de chamada

Ferramentas disponíveis

Resource disponível

Prompt disponível

Estrutura do projeto

Publicação no npm

Build e teste

Publicar

Origem

Licença

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

brasil-mcp-essentialsofficial