GovBR-DS MCP
{"type": "text"}# GovBR DS MCP
Servidor Model Context Protocol (MCP) de código abierto para el Design System del Gobierno Federal Brasileño (GovBR-DS).
El govbr-ds-mcp proporciona a agentes de IA acceso estructurado a la documentación de GovBR-DS, sus componentes, orientaciones de accesibilidad, búsqueda, Resources y flujos de trabajo reutilizables para desarrollo.
El objetivo es permitir que herramientas como Codex, Claude Code, Kiro y otros clientes compatibles con MCP comprendan y utilicen el GovBR Design System basándose en su documentación oficial sincronizada, en lugar de depender únicamente del conocimiento previo del modelo.
El paquete está publicado en npm como govbr-ds-mcp y se puede ejecutar directamente con:
npx -y govbr-ds-mcpEste es un proyecto comunitario e independiente. No es un proyecto oficial del Gobierno Federal Brasileño ni del equipo responsable de GovBR-DS.
¿Por qué este proyecto?
Los agentes de IA pueden generar código frontend rápidamente, pero no siempre saben:
qué componente de GovBR-DS debe utilizarse;
cómo debe comportarse un componente determinado;
qué recomendaciones de accesibilidad se aplican;
qué estándares de uso se recomiendan;
dónde se encuentra una información específica en la documentación de GovBR-DS.
El govbr-ds-mcp busca resolver este problema poniendo a disposición la documentación de GovBR-DS a través del Model Context Protocol.
Agente de IA
│
▼
govbr-ds-mcp
│
├── Tools
├── Resources
├── Prompts
└── Busca
│
▼
Dados estruturados locais
▲
│
Sincronização da documentação
▲
│
Repositório oficial GovBR-DSEl servidor MCP no utiliza un LLM internamente y no realiza solicitudes externas durante su ejecución normal.
Related MCP server: PortOne Global MCP Server
Funcionalidades
Sincronización de la documentación
La documentación se obtiene del repositorio oficial de GovBR-DS y se transforma en datos estructurados locales.
GitLab GovBR-DS
│
▼
GitLab API
│
▼
Parser Markdown
│
▼
Componentes estruturados
│
▼
components.generated.tsLos datos generados se almacenan localmente, lo que permite que el servidor MCP funcione sin acceso a internet después de la sincronización.
Actualmente, el proyecto sincroniza 37 componentes documentados de GovBR-DS.
Tools MCP
list_components
Lista los componentes de GovBR-DS disponibles en el índice local de la documentación.
Ejemplo:
{}Respuesta:
[
{
"name": "Button",
"slug": "button",
"description": "..."
},
{
"name": "Input",
"slug": "input",
"description": "..."
}
]get_component
Devuelve la documentación estructurada completa de un componente específico de GovBR-DS.
Ejemplo:
{
"name": "button"
}La búsqueda no distingue entre mayúsculas y minúsculas.
Las siguientes llamadas son equivalentes:
button
Button
BUTTONsearch_docs
Busca dentro de la documentación de GovBR-DS sincronizada localmente.
Ejemplo:
{
"query": "como usar um botão",
"limit": 5
}El mecanismo de búsqueda tiene soporte para:
búsqueda sin distinción de mayúsculas y minúsculas;
búsqueda sin diferenciación de acentos;
eliminación de stopwords en portugués;
alias de componentes;
canonicalización de variaciones morfológicas;
priorización del componente identificado;
ranking por relevancia de secciones;
generación de snippets relevantes;
filtro por componente.
Ejemplo:
{
"query": "acessibilidade aria",
"component": "button",
"limit": 5
}La búsqueda se realiza completamente en memoria.
No se utilizan:
embeddings;
base vectorial;
Elasticsearch;
LLM;
servicios de búsqueda externos.
Resources MCP
La documentación de GovBR-DS también se pone a disposición a través de MCP Resources.
Catálogo de componentes
govbr-ds://catalogProporciona un índice de todos los componentes sincronizados.
Documentación de componente
govbr-ds://components/{slug}Ejemplo:
govbr-ds://components/buttonDevuelve la documentación completa del componente en Markdown.
Documentación de accesibilidad
govbr-ds://components/{slug}/accessibilityEjemplo:
govbr-ds://components/button/accessibilityDevuelve las orientaciones de accesibilidad disponibles para el componente.
No todos los componentes de GovBR-DS tienen documentación específica de accesibilidad.
Los Resources se generan íntegramente a partir de los datos sincronizados localmente.
Prompts MCP
El servidor pone a disposición Prompts reutilizables para flujos de trabajo comunes de desarrollo con GovBR-DS.
implement_govbr_component
Proporciona la documentación oficial sincronizada de un componente e instrucciones para ayudar en su implementación.
Ejemplo:
{
"component": "button",
"requirements": "Preciso de uma ação principal para confirmar o formulário."
}El Prompt proporciona al modelo la documentación relevante del componente para que la implementación se base en GovBR-DS.
review_govbr_component
Proporciona la documentación del componente junto con un fragmento de código que debe revisarse.
Ejemplo:
{
"component": "button",
"code": "<button class=\"br-button\">Enviar</button>"
}La revisión puede entonces comparar la implementación proporcionada con las orientaciones disponibles en la documentación sincronizada.
check_govbr_accessibility
Proporciona las orientaciones de accesibilidad de un componente para ayudar en la revisión de una implementación.
Ejemplo:
{
"component": "button",
"code": "<button class=\"br-button circle\"><i class=\"fas fa-plus\"></i></button>"
}El servidor MCP no ejecuta ni interpreta el código recibido.
El código se trata solo como texto y se pone a disposición como contexto para el modelo conectado.
Arquitectura
src/
├── data/
│ ├── components.ts
│ └── components.generated.ts
│
├── ingestion/
│ ├── gitlab-client.ts
│ ├── component-parser.ts
│ └── component-sync.ts
│
├── services/
│ ├── component.service.ts
│ └── search.service.ts
│
├── tools/
│ ├── list-components.ts
│ ├── get-component.ts
│ └── search-docs.ts
│
├── resources/
│ ├── register-resources.ts
│ ├── component.resource.ts
│ └── accessibility.resource.ts
│
├── prompts/
│ ├── register-prompts.ts
│ ├── implement-component.prompt.ts
│ ├── review-component.prompt.ts
│ └── accessibility-review.prompt.ts
│
├── formatters/
│ └── component-markdown.ts
│
├── types/
│
└── index.ts
scripts/
└── sync-components.tsEl flujo principal de la aplicación es:
Cliente MCP
│
▼
govbr-ds-mcp
│
┌─────────────┼─────────────┐
│ │ │
Tools Resources Prompts
│ │ │
└─────────────┼─────────────┘
▼
Services locais
│
▼
Dados sincronizados
▲
│
sync:components
▲
│
GovBR-DS oficialUso rápido
Node.js 22+
npm
No es necesario clonar ni instalar el paquete globalmente. Los clientes MCP pueden iniciar el servidor publicado directamente vía npx:
npx -y govbr-ds-mcpEl servidor utiliza el transporte MCP stdio y funciona con los datos de GovBR-DS incluidos en el paquete, sin llamadas HTTP durante las consultas.
Configuración en los clientes MCP
Claude Desktop
Agregue el servidor al archivo de configuración de Claude Desktop:
{
"mcpServers": {
"govbr-ds": {
"command": "npx",
"args": ["-y", "govbr-ds-mcp"]
}
}
}Después de guardar el archivo, reinicie Claude Desktop.
Consulte también la documentación MCP de Claude.
Claude Code
Registre el servidor desde la terminal:
claude mcp add govbr-ds -- npx -y govbr-ds-mcpUse claude mcp list para confirmar el registro.
Codex
Agregue al archivo ~/.codex/config.toml:
[mcp_servers.govbr-ds]
command = "npx"
args = ["-y", "govbr-ds-mcp"]También es posible registrarlo desde la terminal:
codex mcp add govbr-ds -- npx -y govbr-ds-mcpReinicie Codex después de modificar manualmente la configuración.
Consulte también la documentación MCP de Codex.
Kiro
En Kiro, abra o cree .kiro/settings/mcp.json en el workspace. Para poner el servidor a disposición globalmente, use ~/.kiro/settings/mcp.json:
{
"mcpServers": {
"govbr-ds": {
"command": "npx",
"args": ["-y", "govbr-ds-mcp"],
"disabled": false,
"autoApprove": []
}
}
}Después de guardar, abra el panel MCP de Kiro y confirme que govbr-ds está conectado.
Consulte también la documentación MCP de Kiro.
Desarrollo local
Clone el repositorio e instale las dependencias:
git clone https://github.com/FelipeVergaraChico/govbr-ds-mcp.git
cd govbr-ds-mcp
npm installEjecutando el servidor MCP
Inicie el servidor en modo de desarrollo:
npm run devEl servidor utiliza el transporte MCP stdio.
Como el stdout está reservado para la comunicación del protocolo MCP, los registros de la aplicación deben enviarse a stderr.
Evite:
console.log("Servidor iniciado");Prefiera:
console.error("Servidor iniciado");MCP Inspector
El proyecto se puede probar utilizando el MCP Inspector.
Ejecute:
npx @modelcontextprotocol/inspector npx -y govbr-ds-mcpEn el Inspector es posible probar las funcionalidades disponibles.
Tools
list_components
get_component
search_docsResources
govbr-ds://catalog
govbr-ds://components/{slug}
govbr-ds://components/{slug}/accessibilityPrompts
implement_govbr_component
review_govbr_component
check_govbr_accessibilitySincronizando la documentación de GovBR-DS
Para actualizar el índice local:
npx tsx scripts/sync-components.tsEl proceso de sincronización:
accede al repositorio público de GovBR-DS a través de la API de GitLab;
identifica los componentes documentados;
descarga los archivos Markdown de cada componente;
descarga la documentación de accesibilidad cuando está disponible;
interpreta los archivos Markdown;
normaliza los datos;
genera el dataset local utilizado por el MCP.
Los datos generados se almacenan en:
src/data/components.generated.tsEl archivo se genera automáticamente y no debe editarse manualmente.
Durante la ejecución normal, el servidor MCP no consulta GitLab.
Esto permite utilizar las Tools, Resources, Prompts y la búsqueda incluso sin conexión a internet.
Ejecutando las pruebas
Ejecute:
npm testLa suite de pruebas cubre áreas como:
análisis de Markdown;
búsqueda de componentes;
búsqueda sin distinción de mayúsculas y minúsculas;
normalización de acentos;
alias;
canonicalización;
ranking de búsqueda;
generación de snippets;
MCP Tools;
MCP Resources;
MCP Prompts;
formato de la documentación;
manejo de componentes inexistentes.
Las pruebas unitarias no dependen de la disponibilidad de GitLab.
Desarrollo
Instale las dependencias:
npm installEjecute el servidor:
npm run devEjecute las pruebas:
npm testActualice la documentación local:
npx tsx scripts/sync-components.tsAbra el MCP Inspector:
npx @modelcontextprotocol/inspector npx tsx src/index.tsFuente de datos
La documentación utilizada por este proyecto se obtiene del repositorio oficial del GovBR Design System:
El proceso actual de ingesta utiliza principalmente:
ds/componentes/La documentación de los componentes normalmente tiene una estructura similar a:
ds/componentes/button/
├── button.md
├── button-access.md
└── imagens/El archivo principal generalmente contiene información como:
descripción;
uso;
anatomía;
tipos;
comportamiento;
especificaciones.
Cuando está disponible, el archivo *-access.md contiene las orientaciones específicas de accesibilidad.
No todos los componentes tienen exactamente el mismo conjunto de archivos.
El proceso de sincronización se desarrolló para manejar estas diferencias sin interrumpir la generación del dataset.
Principios del proyecto
Documentación oficial primero
Siempre que sea posible, la información proporcionada por el MCP debe basarse en la documentación oficial sincronizada de GovBR-DS.
El objetivo es reducir situaciones en las que un agente de IA inventa una regla o comportamiento que no existe en el Design System.
Independiente de LLM
El servidor MCP no depende de:
OpenAI;
Anthropic;
Google;
modelos locales;
cualquier otro proveedor de IA.
El modelo es responsabilidad del cliente MCP conectado.
Runtime local
Las solicitudes externas se utilizan durante la sincronización de la documentación, y no durante las consultas normales al MCP.
npx tsx scripts/sync-components.ts
│
└── Internet necessária
npm run dev
│
└── Documentação localBúsqueda simple antes que infraestructura compleja
La búsqueda actual utiliza ranking textual determinista.
El proyecto no depende de:
embeddings;
base vectorial;
infraestructura RAG;
servicio de búsqueda externo.
Para la cantidad actual de documentación, una búsqueda local bien estructurada mantiene el proyecto más simple, predecible y ligero.
Respuestas pequeñas
La Tool search_docs devuelve snippets relevantes en lugar de enviar documentos completos al modelo.
Esto ayuda a reducir:
cantidad de contexto;
consumo de tokens;
información irrelevante;
respuestas excesivamente grandes.
Cuando se necesita el documento completo, el agente puede utilizar get_component o los MCP Resources.
Roadmap
Completado
servidor MCP con transporte
stdiolistado de componentes
consulta individual de componentes
sincronización de la documentación de GovBR-DS
parser estructurado de Markdown
generación automática del dataset local
búsqueda local en la documentación
ranking de relevancia
normalización de consultas en portugués
MCP Resources
Resources de accesibilidad
catálogo de componentes
MCP Prompts
autocompletado de componentes en los Prompts
Planificado
ejemplos oficiales de implementación HTML y CSS
integración con
@govbr-ds/coredocumentación de los GovBR Web Components
documentación de los GovBR React Components
ejemplos de implementación por componente
validación de código GovBR-DS
helpers para validación de accesibilidad
publicación en npm
publicación en el MCP Registry
transporte HTTP
Proyecto relacionado
Este MCP se desarrolló para complementar la skill govbr-design-system.
Los dos proyectos tienen responsabilidades diferentes:
govbr-design-system
│
└── Instruções, regras e boas práticas
para orientar agentes de IA
govbr-ds-mcp
│
└── Documentação, busca, Resources,
Tools e PromptsPueden utilizarse juntos por agentes compatibles.
Conceptualmente:
Agente de IA
│
┌───────────┴───────────┐
│ │
Skill MCP
│ │
Como se comportar O que a documentação diz
Boas práticas Componentes
Regras de uso Acessibilidade
Orientações Busca
ResourcesCómo contribuir
Las contribuciones son bienvenidas.
Algunas áreas interesantes para contribuir:
mejora del parser de documentación;
mejora de la relevancia de la búsqueda;
creación de nuevas pruebas;
soporte para nuevas fuentes oficiales de GovBR-DS;
mejora de la compatibilidad con clientes MCP;
soporte para las bibliotecas oficiales;
identificación de componentes no documentados;
corrección de datos interpretados incorrectamente.
Antes de enviar un Pull Request:
npm testTambién confirme que el proyecto continúa pasando el typecheck/build utilizado en el repositorio.
Aviso
El govbr-ds-mcp es un proyecto de código abierto independiente.
No está mantenido, respaldado ni soportado oficialmente por el Gobierno Federal Brasileño ni por el equipo responsable del GovBR Design System.
La documentación y los recursos de GovBR-DS utilizados por el proyecto siguen sujetos a las licencias y términos de sus respectivos proyectos originales.
Licencia
Consulte el archivo LICENSE para obtener información sobre la licencia de este proyecto.
Available Tools
3 toolsget_componentA
Obtém a documentação oficial sincronizada completa de um componente do GovBR Design System. Use quando já souber qual componente GovBR-DS precisa consultar.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The tool name and description imply a read-only operation without side effects, but it does not explicitly state that the operation is safe or what the response format will be. Since no annotations are provided, the description carries the burden but remains reasonably transparent.
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 concise, consisting of one functional sentence and a usage note. It is well-structured and directly addresses the tool's purpose without unnecessary verbosity.
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?
The description provides sufficient context for a simple retrieval tool, indicating the source (GovBR Design System) and the condition for use (knowing the component). It does not detail the output structure, but given the lack of an output schema and the straightforward nature of the operation, 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?
The only parameter 'name' is defined in the schema with type and minLength but no description. The tool description implies that 'name' should be the component name, but does not provide explicit format or examples. The parameter semantics are only partially conveyed.
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 tool retrieves complete official documentation for a specific GovBR Design System component, and explicitly notes it should be used when the component name is already known, distinguishing it from the sibling tools list_components and search_docs.
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 provides explicit guidance on when to use the tool: 'Use quando já souber qual componente GovBR-DS precisa consultar.' This clearly indicates it is for direct retrieval by name, contrasting with listing or searching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_componentsA
Lista os componentes documentados do GovBR Design System disponíveis neste servidor. Use para descobrir quais componentes GovBR-DS podem ser consultados.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses an important scope constraint (components 'available on this server'), but does not describe output format, ordering, pagination, or confirm the read-only nature beyond the verb 'list'. Adequate for a simple operation, but lacks richer behavioral context.
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 two sentences, front-loaded with the primary action and resource, and every sentence adds value. No fluff or redundancy.
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 parameterless listing tool with no output schema, the description is sufficiently complete: it states what is listed, the scope (this server), and the intended use case. While it doesn't specify the return shape, the simplicity of a list tool makes this an acceptable gap.
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?
The tool has zero parameters and the schema covers 100% (empty schema). Baseline for 0 params is 4. The description adds no parameter-specific meaning, but none is needed.
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 tool 'Lists the documented components of GovBR Design System available on this server' with a specific verb and resource. It also distinguishes itself from siblings by framing this as the discovery gateway for which GovBR-DS components can be queried, contrasting with get_component and search_docs.
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 provides explicit usage context: 'Use to discover which GovBR-DS components can be consulted.' This tells the agent when to invoke the tool, though it does not explicitly name alternatives or exclusionary conditions. A clear, non-exhaustive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_docsA
Pesquisa na documentação oficial sincronizada do GovBR Design System (GovBR-DS). Use esta ferramenta sempre que precisar responder perguntas sobre componentes, uso, comportamento, acessibilidade, padrões ou recomendações do GovBR-DS. Prefira esta fonte em vez de pesquisa web para dúvidas sobre GovBR-DS.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| component | No |
TDQS
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 does not mention side effects, read-only nature, authentication, rate limits, or any behavioral traits beyond the obvious 'search' action. The description adds no insight into what happens during the search or what the response contains.
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 two concise sentences, front-loaded with purpose, and goes straight to the point. No fluff or redundancy.
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?
The tool is moderately simple but has no output schema, no annotations, and no parameter documentation. The description covers the what and when but omits return format, query construction, component filter usage, and potential limitations. Given the available structured data, it remains incomplete.
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 0% and the description does not reference any parameters (query, limit, component). It only implies searching for components but does not explain how to use parameters or their semantics. The description fails to compensate for the low schema coverage.
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 explicitly states 'Pesquisa na documentação oficial sincronizada do GovBR Design System' (searches the official synchronized documentation), which clearly identifies the action (search) and resource (GovBR-DS docs). It distinguishes from siblings like list_components and get_component by focusing on searching across documentation rather than retrieving specific component details.
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?
It provides explicit guidance on when to use the tool ('sempre que precisar responder perguntas sobre componentes, uso, comportamento, acessibilidade, padrões ou recomendações do GovBR-DS') and even recommends it over web search for GovBR-DS questions. It lacks an explicit 'when not to use' relative to sibling tools, but the context is clear.
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.
3 tool updates
v0.1.0- First observed
get_component - First observed
list_components - First observed
search_docs
TDQS
Scored across 3 tools
Each tool has a clearly distinct purpose: list_components is for discovery, get_component is for retrieving full docs of a known component, and search_docs is for answering arbitrary questions across the documentation. Their usage guidance avoids ambiguity.
All tools follow a consistent verb_noun pattern: list_components, get_component, and search_docs. The naming clearly signals the operation being performed, and any plural/singular variation follows conventional API naming.
With three tools, the server is lean but well-scoped for its purpose of querying GovBR-DS documentation. Each tool earns its place by covering a distinct access mode: browsing, direct retrieval, and searching.
For a read-only documentation server, the surface is complete: users can discover available components, fetch complete documentation for a known component, and search for behavioral or accessibility guidance. No obvious dead ends or missing operations exist for the stated domain.
Maintenance
Related MCP Connectors
Access and search Branch's official API documentation directly within any AI agent or client.
Serves your design system and coding standards to coding agents, so they stop guessing.
Access and maintain design system docs, tokens, components, skills, and contexts across any project.
Connect AI agents to ProductNow's context engine to search, create, review, and act.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol implementation that enables AI-powered access to documentation resources, featuring URI-based navigation, template matching, and structured documentation management.9MIT
- AlicenseNot gradedqualityDmaintenanceEnables searching and reading of PortOne documentation, including OpenAPI schemas and product guides, through the Model Context Protocol. It allows AI agents to easily access and integrate payment-related technical specifications into their workflows.8 npmISC
- AlicenseAqualityDmaintenanceProvides AI assistants with direct access to the complete Godot Engine documentation, including classes, tutorials, and features. It enables developers to retrieve and analyze official documentation through natural language interfaces using the Model Context Protocol.2MIT
- AlicenseNot gradedqualityDmaintenanceEnables LLMs to query Brazilian public data such as CEP, CNPJ, DDD, exchange rates, banks, and holidays via the Model Context Protocol.12MIT