ViaCEP Brasil MCP Server
Provides address lookup tools accessible from GitHub Copilot to retrieve address information from Brazilian CEPs.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@ViaCEP Brasil MCP Serverwhat is the address for CEP 01001000?"
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.
ViaCEP Brasil MCP Server
O ViaCEP Brasil MCP Server conecta ferramentas de IA diretamente à API ViaCEP, permitindo consultas de endereços brasileiros através do CEP ou busca de CEPs através de endereços. Esta integração permite que agentes de IA, assistentes e chatbots consultem informações de endereços do Brasil por meio de interações em linguagem natural.
Casos de Uso
Consulta de Endereços: Obtenha informações detalhadas de endereços fornecendo um CEP.
Busca de CEPs: Encontre CEPs a partir de informações parciais de endereços (UF, cidade e logradouro).
Validação de Endereços: Verifique se um CEP existe e obtenha os detalhes completos do endereço.
Integração com Sistemas: Facilite a integração de dados de endereço em aplicações que utilizam IA.
Related MCP server: ViaCEP Brasil MCP Server
Ferramentas Disponíveis
O servidor disponibiliza duas ferramentas principais:
getAddressByCEP
Obtém informações de endereço a partir de um CEP.
Parâmetros:
cep(string): O código postal de 8 dígitos, sem hífen ou outros caracteres especiais.
Exemplo de Uso:
{
"cep": "01001000"
}Exemplo de Resposta:
{
"cep": "01001-000",
"logradouro": "Praça da Sé",
"complemento": "lado ímpar",
"bairro": "Sé",
"localidade": "São Paulo",
"uf": "SP",
"ibge": "3550308",
"gia": "1004",
"ddd": "11",
"siafi": "7107"
}getCEPByAddress
Busca CEPs com base em informações de endereço.
Parâmetros:
uf(string): Código de duas letras do estado (ex: "SP").cidade(string): Nome da cidade.logradouro(string): Nome da rua, avenida, praça, etc.
Exemplo de Uso:
{
"uf": "RS",
"cidade": "Porto Alegre",
"logradouro": "Domingos"
}Exemplo de Resposta:
[
{
"cep": "91420-270",
"logradouro": "Rua São Domingos",
"bairro": "Bom Jesus",
"localidade": "Porto Alegre",
"uf": "RS",
...
},
{
"cep": "91040-000",
"logradouro": "Rua Domingos Rubbo",
"bairro": "Cristo Redentor",
"localidade": "Porto Alegre",
"uf": "RS",
...
},
...
]Recursos
README: Acesse esta documentação através do recurso
readme://viacep.
Instalação e Configuração
O ViaCEP Brasil MCP Server pode ser executado de várias formas, dependendo das suas necessidades.
Pré-requisitos
Node.js v18+ (para execução direta)
Docker (para execução via contêiner)
Instalação via NPX
A forma mais simples de usar o servidor:
npx viacep-brasil-mcp-serverInstalação Local
Clone este repositório e execute:
# Instalar dependências
npm install
# Construir o servidor
npm run build
# Iniciar o servidor
node build/index.jsInstalação via Docker
Usando a Imagem Pré-construída
docker run -i --rm ghcr.io/seu-usuario/viacep-brasil-mcp-serverConstruindo sua Própria Imagem
# Clone o repositório
git clone https://github.com/seu-usuario/viacep-brasil-mcp-server.git
cd viacep-brasil-mcp-server
# Construa a imagem Docker
docker build -t viacep-brasil-mcp-server .
# Execute o contêiner
docker run -i --rm viacep-brasil-mcp-serverConfiguração em Aplicações MCP
VS Code com GitHub Copilot
Adicione o seguinte bloco JSON às suas configurações MCP:
{
"servers": {
"viacep": {
"command": "npx",
"args": ["viacep-brasil-mcp-server"]
}
}
}VS Code com Docker
{
"servers": {
"viacep": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"viacep-brasil-mcp-server"
]
}
}
}Claude Desktop / Claude Web / Claude Code
Adicione o servidor ao arquivo de configuração:
No macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
No Windows: %APPDATA%/Claude/claude_desktop_config.json
{
"mcpServers": {
"viacep": {
"command": "/caminho/para/viacep-brasil-mcp-server/build/index.js"
}
}
}Cursor
Adicione o seguinte ao seu arquivo .cursor/mcp.json:
{
"servers": {
"viacep": {
"command": "npx",
"args": ["viacep-brasil-mcp-server"]
}
}
}Desenvolvimento
Instalação de Dependências
npm installConstruir o Servidor
npm run buildDesenvolvimento com Auto-reconstrução
npm run watchDepuração
Como os servidores MCP se comunicam via stdio, a depuração pode ser desafiadora. Recomendamos usar o MCP Inspector, que está disponível como um script de pacote:
npm run inspectorO Inspector fornecerá um URL para acessar ferramentas de depuração em seu navegador.
Licença
Este projeto é licenciado sob os termos da licença MIT de código aberto.
Available Tools
2 toolsgetAddressByCEPA
Fetches a Brazilian address using a postal code (CEP).
| Name | Required | Description | Default |
|---|---|---|---|
| cep | Yes | The 8-digit CEP code. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Fetches' implies a read-only operation, but it does not disclose error handling, input validation, formatting expectations, or response structure. Lacks detail beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the verb and resource. No wasted words; it is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with full schema coverage, the description plus schema are nearly complete. It lacks explicit return format details, but the purpose statement implies the output. Given the simplicity, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the 'cep' parameter described as 'The 8-digit CEP code.' The tool description mentions 'postal code (CEP)' but adds no additional meaning beyond the schema. Baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetches') and names the resource ('Brazilian address') and the input ('postal code (CEP)'). It clearly distinguishes from the sibling tool getCEPByAddress, which performs the reverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a CEP and need an address, but it does not explicitly state when to use this tool over getCEPByAddress or mention any exclusions. No alternative tools are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getCEPByAddressA
Fetches a list of CEPs based on a Brazilian address.
| Name | Required | Description | Default |
|---|---|---|---|
| uf | Yes | The two-letter state code (e.g., SP). | |
| cidade | Yes | The city name. | |
| logradouro | Yes | The street name. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only says 'fetches a list' but does not disclose behavior like result limits, error conditions, or whether multiple CEPs are expected. Minimal behavioral detail is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is clear and front-loaded. Every word serves a purpose, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter lookup tool with no output schema or annotations, the description provides minimal but adequate context. However, it lacks details about result format, potential errors, or differentiation from the sibling tool, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all three parameters have descriptions). The description adds no additional meaning beyond what the schema already provides, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetches') and resource ('list of CEPs based on a Brazilian address'). It distinguishes from the sibling getAddressByCEP, which performs the reverse lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for converting an address to CEPs, but it does not explicitly state when to use it versus getAddressByCEP or any exclusions. Usage is inferred from the name and description.
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.
2 tool updates
v0.1.0- First observed
getAddressByCEP - First observed
getCEPByAddress
TDQS
Scored across 2 tools
The two tools perform reverse operations—one returns an address for a given CEP, the other returns CEPs for a given address. Their purposes are clearly distinct with no overlap.
Both tools follow a consistent 'get<Target>By<Query>' pattern, e.g., 'getAddressByCEP' and 'getCEPByAddress'. The naming is symmetric and predictable.
With exactly two tools, the set is minimal and perfectly scoped for bidirectional CEP-address lookup. Each tool provides a distinct, necessary function without redundancy.
The pair covers both directions of the CEP-address mapping, which is the complete domain for a ViaCEP service. No obvious missing operations.
Maintenance
Related MCP Connectors
Returns the postal code (CEP) and standardized address from the Brazilian Post from a given address.
Correios: Completa CEP (CEP + Área territorial brasileira), official-source lookup. Platform-hosted,
Correios: CEP, official-source lookup. Platform-hosted, pay per query with prepaid credit.
Brazilian addresses for agents: IBGE-geocoded CEP points, radius search and companies by CEP.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceEnables lookup of Brazilian addresses by CEP (postal code) using the ViaCEP API, returning formatted address information including street, neighborhood, city, and state.1-
- FlicenseAqualityDmaintenanceConnects AI tools to the ViaCEP API, allowing natural language queries for Brazilian addresses by CEP or address details.2-
- AlicenseAqualityCmaintenanceExposes the BrasilAPI as MCP tools, enabling AI agents to query Brazilian public data such as CEP, CNPJ, DDD, IBGE, banks, PIX, FIPE, NCM, exchange rates, taxes, weather, CVM information, holidays, ISBN, domains, stock tickers, and TUSS.41Apache 2.0
- AlicenseNot gradedqualityCmaintenanceEnables querying Brazilian CEP (postal code) addresses via the public ViaCEP API, returning formatted HTML with address details.GPL 3.0