GovBR-DS MCP
This server is an MCP (Model Context Protocol) server that provides structured, locally synchronized access to the official GovBR Design System documentation for AI agents.
List GovBR-DS components using the
list_componentstool to discover available documented components.Get full component documentation with the
get_componenttool by providing a component name (case-insensitive).Search the official documentation with
search_docs, supporting fuzzy/Portuguese-aware text search, relevance ranking, snippets, accents/case-insensitive matching, stopword removal, aliases, and optional component filtering.Access documentation as MCP Resources:
govbr-ds://catalogfor the component cataloggovbr-ds://components/{slug}for full component docs in Markdowngovbr-ds://components/{slug}/accessibilityfor accessibility guidelines when available
Use reusable MCP Prompts for common workflows:
implement_govbr_componentto implement a component based on official docsreview_govbr_componentto review code against component documentationcheck_govbr_accessibilityto check code against accessibility guidance
Works locally/offline after documentation sync, without external API calls or LLM dependency during normal use.
Click on "Install 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., "@GovBR-DS MCPliste todos os componentes disponíveis no GovBR-DS"
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.
GovBR DS MCP
Open source Model Context Protocol (MCP) server for the Brazilian Federal Government Design System (GovBR-DS).
govbr-ds-mcp provides AI agents with structured access to GovBR-DS documentation, its components, accessibility guidelines, search, Resources, and reusable workflows for development.
The goal is to enable tools such as Codex, Claude Code, Kiro, and other MCP-compatible clients to understand and use the GovBR Design System based on its synchronized official documentation, rather than relying only on the model's prior knowledge.
The package is published on npm as govbr-ds-mcp and can be run directly with:
npx -y govbr-ds-mcpThis is a community and independent project. It is not an official project of the Brazilian Federal Government nor of the team responsible for GovBR-DS.
Why this project?
AI agents can generate frontend code quickly, but they don't always know:
which GovBR-DS component should be used;
how a given component should behave;
which accessibility recommendations apply;
which usage patterns are recommended;
where a specific piece of information is located in the GovBR-DS documentation.
govbr-ds-mcp aims to solve this problem by making GovBR-DS documentation available through the 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-DSThe MCP server does not use an LLM internally and does not make external requests during its normal operation.
Related MCP server: PortOne Global MCP Server
Features
Documentation synchronization
The documentation is fetched from the official GovBR-DS repository and transformed into local structured data.
GitLab GovBR-DS
│
▼
GitLab API
│
▼
Parser Markdown
│
▼
Componentes estruturados
│
▼
components.generated.tsThe generated data is stored locally, allowing the MCP server to work without internet access after synchronization.
Currently, the project synchronizes 37 documented GovBR-DS components.
MCP Tools
list_components
Lists the GovBR-DS components available in the local documentation index.
Example:
{}Response:
[
{
"name": "Button",
"slug": "button",
"description": "..."
},
{
"name": "Input",
"slug": "input",
"description": "..."
}
]get_component
Returns the complete structured documentation of a specific GovBR-DS component.
Example:
{
"name": "button"
}The search is case-insensitive.
The calls below are equivalent:
button
Button
BUTTONsearch_docs
Searches within the locally synchronized GovBR-DS documentation.
Example:
{
"query": "como usar um botão",
"limit": 5
}The search engine supports:
case-insensitive search;
accent-insensitive search;
Portuguese stopword removal;
component aliases;
canonicalization of morphological variations;
prioritization of the identified component;
ranking by section relevance;
generation of relevant snippets;
filtering by component.
Example:
{
"query": "acessibilidade aria",
"component": "button",
"limit": 5
}The search happens entirely in memory.
The following are not used:
embeddings;
vector database;
Elasticsearch;
LLM;
external search services.
MCP Resources
GovBR-DS documentation is also made available through MCP Resources.
Component catalog
govbr-ds://catalogProvides an index of all synchronized components.
Component documentation
govbr-ds://components/{slug}Example:
govbr-ds://components/buttonReturns the complete component documentation in Markdown.
Accessibility documentation
govbr-ds://components/{slug}/accessibilityExample:
govbr-ds://components/button/accessibilityReturns the accessibility guidelines available for the component.
Not all GovBR-DS components have specific accessibility documentation.
The Resources are generated entirely from locally synchronized data.
MCP Prompts
The server provides reusable Prompts for common development workflows with GovBR-DS.
implement_govbr_component
Provides the synchronized official documentation of a component and instructions to assist its implementation.
Example:
{
"component": "button",
"requirements": "Preciso de uma ação principal para confirmar o formulário."
}The Prompt provides the model with the relevant component documentation so that the implementation is grounded in GovBR-DS.
review_govbr_component
Provides the component documentation along with a code snippet that should be reviewed.
Example:
{
"component": "button",
"code": "<button class=\"br-button\">Enviar</button>"
}The review can then compare the provided implementation with the guidelines available in the synchronized documentation.
check_govbr_accessibility
Provides the accessibility guidelines of a component to assist in reviewing an implementation.
Example:
{
"component": "button",
"code": "<button class=\"br-button circle\"><i class=\"fas fa-plus\"></i></button>"
}The MCP server does not execute or interpret the received code.
The code is treated only as text and made available as context for the connected model.
Architecture
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.tsThe main application flow is:
Cliente MCP
│
▼
govbr-ds-mcp
│
┌─────────────┼─────────────┐
│ │ │
Tools Resources Prompts
│ │ │
└─────────────┼─────────────┘
▼
Services locais
│
▼
Dados sincronizados
▲
│
sync:components
▲
│
GovBR-DS oficialQuick start
Node.js 22+
npm
There is no need to clone or install the package globally. MCP clients can start the published server directly via npx:
npx -y govbr-ds-mcpThe server uses the MCP stdio transport and works with the GovBR-DS data included in the package, without HTTP calls during queries.
Configuration in MCP clients
Claude Desktop
Add the server to the Claude Desktop configuration file:
{
"mcpServers": {
"govbr-ds": {
"command": "npx",
"args": ["-y", "govbr-ds-mcp"]
}
}
}After saving the file, restart Claude Desktop.
See also the Claude MCP documentation.
Claude Code
Register the server from the terminal:
claude mcp add govbr-ds -- npx -y govbr-ds-mcpUse claude mcp list to confirm the registration.
Codex
Add to the ~/.codex/config.toml file:
[mcp_servers.govbr-ds]
command = "npx"
args = ["-y", "govbr-ds-mcp"]It is also possible to register from the terminal:
codex mcp add govbr-ds -- npx -y govbr-ds-mcpRestart Codex after manually changing the configuration.
See also the Codex MCP documentation.
Kiro
In Kiro, open or create .kiro/settings/mcp.json in the workspace. To make the server available globally, use ~/.kiro/settings/mcp.json:
{
"mcpServers": {
"govbr-ds": {
"command": "npx",
"args": ["-y", "govbr-ds-mcp"],
"disabled": false,
"autoApprove": []
}
}
}After saving, open the Kiro MCP panel and confirm that govbr-ds is connected.
See also the Kiro MCP documentation.
Local development
Clone the repository and install the dependencies:
git clone https://github.com/FelipeVergaraChico/govbr-ds-mcp.git
cd govbr-ds-mcp
npm installRunning the MCP server
Start the server in development mode:
npm run devThe server uses the MCP stdio transport.
Since stdout is reserved for MCP protocol communication, application logs must be sent to stderr.
Avoid:
console.log("Servidor iniciado");Prefer:
console.error("Servidor iniciado");MCP Inspector
The project can be tested using the MCP Inspector.
Run:
npx @modelcontextprotocol/inspector npx -y govbr-ds-mcpIn the Inspector you can test the available features.
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_accessibilitySynchronizing the GovBR-DS documentation
To update the local index:
npx tsx scripts/sync-components.tsThe synchronization process:
accesses the public GovBR-DS repository through the GitLab API;
identifies the documented components;
downloads the Markdown files of each component;
downloads the accessibility documentation when available;
parses the Markdown files;
normalizes the data;
generates the local dataset used by the MCP.
The generated data is stored in:
src/data/components.generated.tsThe file is generated automatically and should not be edited manually.
During normal operation, the MCP server does not query GitLab.
This allows using the Tools, Resources, Prompts, and search even without an internet connection.
Running the tests
Run:
npm testThe test suite covers areas such as:
Markdown parsing;
component search;
case-insensitive search;
accent normalization;
aliases;
canonicalization;
search ranking;
snippet generation;
MCP Tools;
MCP Resources;
MCP Prompts;
documentation formatting;
handling of non-existent components.
The unit tests do not depend on GitLab availability.
Development
Install the dependencies:
npm installRun the server:
npm run devRun the tests:
npm testUpdate the local documentation:
npx tsx scripts/sync-components.tsOpen the MCP Inspector:
npx @modelcontextprotocol/inspector npx tsx src/index.tsData source
The documentation used by this project is obtained from the official GovBR Design System repository:
The current ingestion process mainly uses:
ds/componentes/Component documentation usually has a structure similar to:
ds/componentes/button/
├── button.md
├── button-access.md
└── imagens/The main file generally contains information such as:
description;
usage;
anatomy;
types;
behavior;
specifications.
When available, the *-access.md file contains the specific accessibility guidelines.
Not all components have exactly the same set of files.
The synchronization process was designed to handle these differences without interrupting dataset generation.
Project principles
Official documentation first
Whenever possible, the information provided by the MCP should be grounded in the synchronized official GovBR-DS documentation.
The goal is to reduce situations where an AI agent invents a rule or behavior that does not exist in the Design System.
LLM-independent
The MCP server does not depend on:
OpenAI;
Anthropic;
Google;
local models;
any other AI provider.
The model is the responsibility of the connected MCP client.
Local runtime
External requests are used during documentation synchronization, not during normal MCP queries.
npx tsx scripts/sync-components.ts
│
└── Internet necessária
npm run dev
│
└── Documentação localSimple search before complex infrastructure
The current search uses deterministic textual ranking.
The project does not depend on:
embeddings;
vector database;
RAG infrastructure;
external search service.
For the current amount of documentation, a well-structured local search keeps the project simpler, more predictable, and lighter.
Small responses
The search_docs Tool returns relevant snippets instead of sending entire documents to the model.
This helps reduce:
context size;
token consumption;
irrelevant information;
excessively large responses.
When the full document is needed, the agent can use get_component or the MCP Resources.
Roadmap
Completed
MCP server with
stdiotransportcomponent listing
individual component query
GovBR-DS documentation synchronization
structured Markdown parser
automatic local dataset generation
local documentation search
relevance ranking
Portuguese query normalization
MCP Resources
accessibility Resources
component catalog
MCP Prompts
component autocomplete in Prompts
Planned
official HTML and CSS implementation examples
integration with
@govbr-ds/coreGovBR Web Components documentation
GovBR React Components documentation
implementation examples per component
GovBR-DS code validation
accessibility validation helpers
npm publication
MCP Registry publication
HTTP transport
Related project
This MCP was developed to complement the govbr-design-system skill.
The two projects have different responsibilities:
govbr-design-system
│
└── Instruções, regras e boas práticas
para orientar agentes de IA
govbr-ds-mcp
│
└── Documentação, busca, Resources,
Tools e PromptsThey can be used together by compatible agents.
Conceptually:
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
ResourcesHow to contribute
Contributions are welcome.
Some interesting areas for contribution:
documentation parser improvement;
search relevance improvement;
creation of new tests;
support for new official GovBR-DS sources;
improved compatibility with MCP clients;
support for the official libraries;
identification of undocumented components;
correction of incorrectly parsed data.
Before submitting a Pull Request:
npm testAlso confirm that the project still passes the typecheck/build used in the repository.
Disclaimer
govbr-ds-mcp is an independent open source project.
It is not maintained, endorsed, or officially supported by the Brazilian Federal Government or by the team responsible for the GovBR Design System.
The documentation and resources of GovBR-DS used by the project remain subject to the licenses and terms of their respective original projects.
License
See the LICENSE file for information about this project's license.
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
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
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.
Provides AI assistants with access to Seltz's powerful Web Search capabilities.
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.9ISC
- 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 AI agents to automate web tasks such as browsing, clicking, typing, and taking screenshots via the Model Context Protocol.1MIT