Skip to main content
Glama

{"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-mcp

Este 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-DS

El 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.ts

Los 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
BUTTON

search_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://catalog

Proporciona un índice de todos los componentes sincronizados.


Documentación de componente

govbr-ds://components/{slug}

Ejemplo:

govbr-ds://components/button

Devuelve la documentación completa del componente en Markdown.


Documentación de accesibilidad

govbr-ds://components/{slug}/accessibility

Ejemplo:

govbr-ds://components/button/accessibility

Devuelve 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.ts

El flujo principal de la aplicación es:

                    Cliente MCP
                        │
                        ▼
                  govbr-ds-mcp
                        │
          ┌─────────────┼─────────────┐
          │             │             │
        Tools       Resources       Prompts
          │             │             │
          └─────────────┼─────────────┘
                        ▼
                 Services locais
                        │
                        ▼
              Dados sincronizados
                        ▲
                        │
               sync:components
                        ▲
                        │
               GovBR-DS oficial

Uso 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-mcp

El 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-mcp

Use 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-mcp

Reinicie 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 install

Ejecutando el servidor MCP

Inicie el servidor en modo de desarrollo:

npm run dev

El 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-mcp

En el Inspector es posible probar las funcionalidades disponibles.

Tools

list_components
get_component
search_docs

Resources

govbr-ds://catalog
govbr-ds://components/{slug}
govbr-ds://components/{slug}/accessibility

Prompts

implement_govbr_component
review_govbr_component
check_govbr_accessibility

Sincronizando la documentación de GovBR-DS

Para actualizar el índice local:

npx tsx scripts/sync-components.ts

El proceso de sincronización:

  1. accede al repositorio público de GovBR-DS a través de la API de GitLab;

  2. identifica los componentes documentados;

  3. descarga los archivos Markdown de cada componente;

  4. descarga la documentación de accesibilidad cuando está disponible;

  5. interpreta los archivos Markdown;

  6. normaliza los datos;

  7. genera el dataset local utilizado por el MCP.

Los datos generados se almacenan en:

src/data/components.generated.ts

El 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 test

La 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 install

Ejecute el servidor:

npm run dev

Ejecute las pruebas:

npm test

Actualice la documentación local:

npx tsx scripts/sync-components.ts

Abra el MCP Inspector:

npx @modelcontextprotocol/inspector npx tsx src/index.ts

Fuente de datos

La documentación utilizada por este proyecto se obtiene del repositorio oficial del GovBR Design System:

GovBR-DS

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 local

Bú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 stdio

  • listado 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/core

  • documentació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 Prompts

Pueden 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
                             Resources

Có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 test

Tambié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 tools
get_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.

NameRequiredDescriptionDefault
nameYes

TDQS

A4.4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

NameRequiredDescriptionDefault

No parameters

TDQS

A4.2/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

NameRequiredDescriptionDefault
limitNo
queryYes
componentNo

TDQS

A3.5/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 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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters2/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

  1. 3 tool updatesv0.1.0
    • First observedget_component
    • First observedlist_components
    • First observedsearch_docs

TDQS

A4.2/5.0

Scored across 3 tools

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness5/5

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

ActivitySlowing
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol implementation that enables AI-powered access to documentation resources, featuring URI-based navigation, template matching, and structured documentation management.
    9
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    Enables 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 npm
    ISC
  • A
    license
    A
    quality
    D
    maintenance
    Provides 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.
    2
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    Enables LLMs to query Brazilian public data such as CEP, CNPJ, DDD, exchange rates, banks, and holidays via the Model Context Protocol.
    12
    MIT