The opf-br-mcp server offers token-efficient access to Open Finance Brasil (OFB) specifications, business rules, and related documentation for AI coding agents. It uses progressive disclosure to minimize context window usage.
Discover domains: Use list_domains to see all available knowledge domains (payment APIs, business rules, security, participants, etc.), their filters, spec versions, and cache status.
Search within a domain: Use search with keywords and domain-specific filters for compact, summarized results across ~19 domains, including OpenAPI specs (Payments, Enrollments, Consents, Accounts, Webhooks, PCM), business rules, security profiles (FAPI, DCR, CIBA), non-functional requirements, API limits, and the participant directory.
Retrieve full details: Use get_item to fetch a complete record (e.g., OpenAPI endpoint, schema, business rule section) only when needed. For OpenAPI specs, referenced component IDs are provided instead of inlining to save tokens.
Refresh data: Use refresh to force re-extraction from public sources, bypassing the 72-hour cache TTL.
Fallback search: If a domain search yields no results, the portal domain provides a live CQL search across the entire developer portal.
Offline access: Cached data enables offline use with a warning when expired.
Version info: Available via list_domains or npx opf-br-mcp --version.
Extracts and searches Open Finance Brazil business rules and technical specifications from public Confluence pages.
Retrieves OpenAPI specifications and related data from OpenBanking-Brasil repositories on GitHub, enabling search and retrieval of API endpoints and schemas.
Fetches OpenAPI specifications from GitHub Pages, specifically the consents API specification, for search and retrieval.
Consumes OpenAPI (Swagger) specifications from various sources, providing token-efficient search and retrieval of API operations and schemas.
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., "@opf-br-mcp search payments-v4 for pix payment endpoint"
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.
MCP server local que dá a agentes de codificação (Claude Code, GitHub Copilot) acesso token-eficiente às regras do Open Finance Brasil.
Domínio | Fonte | Conteúdo |
| Confluence público OFB | Regras de obrigatoriedade do |
| GitHub OpenBanking-Brasil/all-services-repo | Spec OpenAPI 5.0.0 da API de Iniciação de Pagamentos (consentimentos + Pix) |
| Confluence público OFB (Serviços - SV) | Regras de negócio da API de Pagamentos 5.0.0 (Escopo, Máquina de Estados, Diagrama de Sequência, Validação no DICT, Adaptações 4.0.1→5.0.0) — item por seção |
| GitHub OpenBanking-Brasil/all-services-repo | Spec OpenAPI 2.3.0 da API de Vínculo de Dispositivo (Enrollments, FIDO, Pix Automático) |
| Confluence público OFB (Serviços - SV) | Regras de negócio do Vínculo de Dispositivo 2.3.0-rc.1 (Máquina de estados, Edição do vínculo, FAQ - JSR) — item por seção |
| GitHub OpenBanking-Brasil/all-services-repo | Spec OpenAPI 2.2.0 da API de Pagamentos Automáticos (Pix Automático e Transferências Inteligentes) |
| Confluence público OFB (Serviços - SV) | Regras de negócio de Pagamentos Automáticos 2.2.0 (Máquina de Estados, Edição do consentimento, Tentativas Intradia/Extradia, Adaptações 1.0.0→2.2.0) — item por seção |
| Confluence público OFB (Serviços - SV) | Conteúdo comum aos produtos de Iniciação de Pagamentos (atores, Idempotência, Como Assinar o Payload, Convenções de data/fuso, Polling) — item por seção |
| Confluence público OFB (Serviços - SV) | Guias de Implementação (Pix Automático, Agendamento Recorrente, Transferências Inteligentes, Liquidação de QR Codes) — item por seção |
| GitHub Pages openbanking-brasil.github.io | Spec OpenAPI 3.3.1 da API de Consentimentos (Dados Cadastrais e Transacionais) |
| GitHub Pages openbanking-brasil.github.io | Spec OpenAPI 3.1.0 da API de Recursos ( |
| Confluence público OFB (Dados - DC) | Regras de negócio da API de Recursos 3.1.0 (Informações Gerais, Orientações, Campos regulatórios) — item por seção |
| GitHub OpenBanking-Brasil/all-services-repo | Spec OpenAPI 2.5.1 da API de Contas (listagem, saldos, saldos reservados/caixinhas, transações, limites de cheque especial) |
| Confluence público OFB (Dados - DC) | Regras de negócio da API de Contas 2.5.0 (PRD, Orientações — contraparte/IN BCB nº 371) — item por seção |
| GitHub OpenBanking-Brasil/pcm-specs | Spec OpenAPI da PCM (reportes, hybrid-flow, opendata, consents/stock, credit-portabilities, payments/status) |
| Confluence público OFB | Regras de negócio e gestão operacional da PCM (reporte, processamento, divergências, |
| Confluence público OFB | Regras da Jornada Otimizada (Orientações Gerais, Transferências Inteligentes, Jornada sem Redirecionamento) — item por seção |
| Confluence público OFB | Motor de Qualidade de Dados (especificação técnica, arquitetura e fluxos, documentação da API, instalação, endpoints validados, FAQ e troubleshooting) — item por seção |
| GitHub OpenBanking-Brasil/all-services-repo | Spec OpenAPI 1.3.0 da API de Webhook (notificações de mudança de estado: pagamentos, enrollments, pagamentos automáticos) |
| Confluence público OFB | Segurança do Open Finance Brasil (guias do usuário, Perfil de Segurança, FAPI-BR 2.2.1, DCR-BR 2.1.0, referências de CIBA, Padrão de Certificados 2.1, Assinaturas, Casos de Erro, Redirecionamento App-to-App, Glossário, Versionamento) — item por seção |
| Confluence público OFB (Manual de APIs) | Requisitos não funcionais de todas as APIs (Desempenho, Disponibilidade, Timeout, Limites de tráfego, Limites operacionais, Indisponibilidade Programada) — item por seção |
| Confluence público OFB (Manual de APIs) | SLA (p95), timeout, TPM, TPS e limite operacional de cada endpoint de todas as famílias de API — um item por endpoint |
| Diretório OFB (data.directory.openbankingbrasil.org.br) | Organizações participantes, marcas (authorisation servers) e famílias de API suportadas com versões — um item por organização |
| Confluence público OFB (busca ao vivo) | Busca CQL em todo o Portal do Desenvolvedor (espaço OF) — sem cache, |
Related MCP server: ContextualAgentRulesHub
list_domains() — descoberta: domínios, filtros, versão da spec de origem e estado do cache
search(domain, query?, filters?, limit?, offset?) — busca filtrada, retorno compacto
get_item(domain, id) — registro completo
refresh(domain?) — força re-extração das fontes. Prefira passar domain:
sem ele o server atualiza o que couber em 45s (o timeout padrão do cliente MCP
é 60s) e devolve o restante em pendentes, para o agente retomar um a um
Fluxo recomendado para o agente: list_domains → search → get_item.
list_domains devolve server: { name, version } junto do catálogo, então o
agente descobre a versão do server na mesma chamada com que descobre os domínios.
Cada domínio que embrulha uma spec traz também o seu specVersion.
Pela linha de comando:
npx opf-br-mcp --versionDomínios marcados como live (ex.: portal) consultam a fonte a cada chamada:
não têm cache nem refresh, e search exige query. Quando um search em
domínio comum retorna 0 resultados, a resposta inclui um hint sugerindo o
portal.
O problema que este servidor resolve: uma spec Swagger/OpenAPI inteira não cabe bem na janela de contexto de um agente, e despejá-la desperdiça tokens. A solução é revelação progressiva — o agente nunca recebe a spec completa de uma vez, apenas o mínimo necessário em cada etapa do funil:
list_domains — catálogo barato: quais domínios e filtros existem. Os
filtros idênticos a uma família inteira de domínios (os 8 *-openapi, os 12
de seções do Confluence) saem uma única vez em filterSets; cada domínio
traz filterSet e só lista inline o que é próprio dele (em *-openapi,
apenas path, cujo exemplo varia por API). Os filtros aceitos por um domínio
são a união dos dois.
search — índice pesquisável e resumido. Cada resultado traz só os
campos leves (id, type, path, method, summary/name, required,
in); o nó pesado da spec (detail) e a lista refs são removidos do
resumo, e o retorno ainda é compactado (omite null e arrays vazios).
get_item — só aqui o nó integral da spec é entregue, e apenas para o
id que o agente escolheu.
Como o Swagger/OpenAPI vira dados pesquisáveis: o parser "achata" a spec em itens
com id estável — um por endpoint (type: operation, ex.
payments:POST /pix/payments) e um por component reutilizável: type: schema
(payments:schema:PixPayment), type: response (webhook:response:202Webhook),
type: parameter (webhook:parameter:xWebhookInteractionId) e type: header
(payments:header:X-V). O JSON completo de
cada nó fica retido em detail até um get_item explícito. Os ids não são
adivinháveis: sempre vêm de um search. Assim o agente localiza o endpoint/schema
certo pagando poucos tokens e só "paga" o payload integral quando pede um item nomeado.
Os $ref não são expandidos em linha (medimos 3–7x mais tokens por operação):
em vez disso, o get_item de um item traz refs com os ids dos components que
ele referencia — todos resolvíveis por get_item. Resolver
responses.202.$ref: '#/components/responses/202Webhook' é uma chamada a mais,
não uma ida ao YAML da fonte.
Dados: extraídos das fontes públicas na primeira consulta (lazy), cache em
~/.cache/opf-br-mcp/ com TTL de 72h. Sem rede, serve cache expirado com aviso.
Requer Node >= 20. O servidor roda via npx, sem clone nem build.
Claude Code — .mcp.json na raiz do projeto consumidor:
{ "mcpServers": { "opf-br": { "command": "npx", "args": ["-y", "opf-br-mcp"] } } }GitHub Copilot (VS Code) — .vscode/mcp.json:
{ "servers": { "opf-br": { "command": "npx", "args": ["-y", "opf-br-mcp"] } } }Claude Desktop — claude_desktop_config.json (Settings → Developer → Edit Config):
{ "mcpServers": { "opf-br": { "command": "npx", "args": ["-y", "opf-br-mcp"] } } }No Windows, o client não consegue executar npx diretamente (é o shim
npx.cmd) e acaba abrindo um cmd.exe interativo, cujo banner
(Microsoft Windows [Version ...]) vaza para o canal stdio e corrompe o
protocolo JSON-RPC — o servidor falha na conexão com erros de JSON inválido.
Envolva o comando em cmd /c para rodá-lo sem shell interativo:
{ "mcpServers": { "opf-br": { "command": "cmd", "args": ["/c", "npx", "-y", "opf-br-mcp"] } } }Vale para qualquer client no Windows (Claude Desktop, Claude Code, VS Code) —
ajuste apenas a chave externa (mcpServers ou servers).
git clone https://github.com/jrogeriosilva/opf-br-mcp.git && cd opf-br-mcp
npm install && npm run buildE aponte o client para o build local:
{ "mcpServers": { "opf-br": { "command": "node", "args": ["/caminho/para/opf-br-mcp/dist/index.js"] } } }Criar src/domains/<id>/index.ts exportando um objeto Domain
(src/core/types.ts): extract() busca e estrutura os dados;
search/getItem consultam; filters documenta os filtros.
Registrar em src/core/registry.ts.
Adicionar fixture e builder em test/contract.test.ts — a suíte de
conformidade valida o contrato automaticamente.
npm test # vitest (fixtures locais, sem rede)
npm run typecheck # tsc --noEmit
npm run build # tsup → dist/As skills do projeto ficam em .agents/skills:
auditar-dominios — compara os domínios com as fontes oficiais e lista versões, páginas ou cobertura que precisam de atualização, com evidências e sem editar o projeto.
atualizar-dominios — aplica as atualizações solicitadas e verifica extração, fixtures, testes, tipos e build.
Exemplos de pedidos: “Use $auditar-dominios para listar os domínios desatualizados” e “Use $atualizar-dominios para atualizar Automatic Payments dentro do major atual”.
Devolve o registro completo de um item pelo id retornado por search (nos domínios *-openapi e participantes inclui o nó integral da spec em detail; em pcm-additional-info devolve o registro completo, enquanto search devolve apenas um resumo). Nos domínios *-openapi os $ref não vêm expandidos: o campo refs lista os ids dos components referenciados (responses, parameters, schemas) — chame get_item neles para resolver.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Id do item (vindo de search) | |
| domain | Yes | Id do domínio (ver list_domains) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals behavioral details beyond annotations: for *-openapi and participantes domains, the full spec node is included in `detail`; $ref fields are not expanded but listed in `refs`; and pcm-additional-info returns the full record vs search's summary. These details are not present in the annotations, which only cover reading/idempotency.
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 purpose, then provides essential domain-specific nuances. No wasted words; every clause adds necessary information.
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?
Given the complexity of multiple domains and no output schema, the description covers all key variations: full vs summary records, the `detail` field, and the `refs` behavior with instructions to resolve. It is complete enough for an agent to know what to expect and how to proceed.
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 input schema already has 100% coverage with descriptions for both `id` and `domain`. The description adds contextual meaning by specifying that `id` comes from search and that domain-specific behavior affects the response, which is valuable beyond the schema.
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's purpose: 'Devolve o registro completo de um item pelo id retornado por search', which is a specific verb+resource. It also distinguishes from siblings by noting that search returns only a summary in pcm-additional-info, while get_item returns the full record.
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 explicitly instructs to use get_item with an id from search and to call get_item on referenced refs in *-openapi domains to resolve them. This provides clear when-to-use guidance and contrasts with search, which returns summaries in some domains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista os domínios de conhecimento do Open Finance Brasil disponíveis neste server, com os filtros aceitos por cada um e o estado do cache local. Comece por aqui; depois use search(domain, ...) e get_item(domain, id).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive. The description adds meaningful context about the returned content (domains with filters and local cache state), going beyond the annotations.
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?
A single, front-loaded sentence that conveys purpose, content, and usage flow with no redundant words. Every clause adds value.
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?
Given no output schema and no parameters, the description sufficiently explains what the tool returns (domains, filters, cache state) and how it fits into a larger workflow.
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, so the baseline is 4. The schema is empty and the description correctly does not spend space on parameter details.
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 knowledge domains for Open Finance Brasil, including accepted filters and cache state. It explicitly distinguishes it from siblings by saying 'Comece por aqui' and pointing to search and get_item as next steps.
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 explicitly says 'Start here; then use search(...) and get_item(...)', giving a clear when-to-use directive and naming alternatives. This is strong usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Força re-extração das fontes públicas (ignora o TTL de 72h do cache). Sem domain, atualiza todos. Use quando suspeitar de dados desatualizados.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Id do domínio; omita para todos |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate it's a non-read, idempotent operation. The description adds the cache TTL bypass and the 'updates all' default behavior, providing useful context beyond the annotations without contradicting them.
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 the primary action. Every word adds value, and it avoids redundancy with the schema.
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 tool with one optional parameter and no output schema, the description covers the purpose, usage, and key behavioral aspects (TTL, default scope). It could mention outcome details, but given the simplicity, it's sufficiently 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 schema description already explains the 'domain' parameter with 100% coverage, and the tool description reinforces it with the same idea. The description adds little beyond naming the parameter as a domain id and noting that omission updates all, which is already in the schema.
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 forces re-extraction of public sources, bypassing the 72h cache TTL. This is a specific action distinct from sibling tools like get_item or search, and explicitly mentions its scope.
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 clear when-to-use guidance ('Use quando suspeitar de dados desatualizados') and explains behavior with and without the domain parameter. It doesn't explicitly contrast with alternatives, but that's not essential for a refresh operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca filtrada em um domínio. filters aceita as chaves listadas em list_domains para o domínio (combinadas em AND); query busca substring nos campos textuais. Retorno compacto (omite nulls). Cada resultado tem id para usar em get_item. Na primeira consulta o domínio é extraído das fontes públicas (pode levar ~30s).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Máx. de resultados (1-100, default 20) | |
| query | No | Substring em campos textuais | |
| domain | Yes | Id do domínio (ver list_domains) | |
| offset | No | Pula os N primeiros resultados (paginação com limit) | |
| filters | No | Filtros específicos do domínio |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, openWorldHint), the description discloses important behavioral traits: compact return (omits nulls), first-query domain extraction delay (~30s), and the semantic of `filters` and `query`. This adds significant context about performance and response structure that annotations alone do not convey.
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 and well-structured. Each sentence adds value: purpose, filter/query semantics, return format, linkage to get_item, and performance warning. No fluff or unnecessary detail, while remaining highly informative.
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?
Given the tool's complexity (5 parameters, nested filters, no output schema), the description is remarkably complete. It covers return format, use of sibling tools, domain extraction delay, and filter/query behavior. No critical operational aspect is missing for an agent to invoke the tool correctly.
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%, so baseline is 3. The description adds meaningful semantics by explaining that `filters` accepts keys from `list_domains` (AND-combined) and that `query` does substring matching on text fields. This goes beyond the schema's syntax, though other parameters like `limit` and `offset` are already self-explanatory.
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 'Busca filtrada em um domínio' (filtered search in a domain), specifying the verb and resource. It distinguishes from sibling tools by emphasizing search over retrieval (get_item), listing (list_domains), and refresh actions, making the purpose unambiguous.
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 and how it relates to alternatives: `filters` keys come from `list_domains`, and each result has an `id` to use with `get_item`. This effectively tells the agent when to choose search versus retrieval tools, though it doesn't state a 'when not to use' scenario explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.7.0get_itemlist_domainsrefreshsearchEach tool has a clearly distinct role: list_domains for discovery, search for querying, get_item for retrieving full records, and refresh for cache management. There is no overlap in their purposes.
All tool names use lowercase with underscores, but two are single verbs (refresh, search) while two follow verb_noun (get_item, list_domains). This is a slight inconsistency, though the overall style remains coherent.
With only 4 tools, the server is well-scoped for its purpose of exposing Open Finance Brasil data. Each tool addresses a necessary operation and none are redundant.
The tool set covers the full read-only lifecycle: discover domains, search within them, retrieve full items, and refresh data. There are no obvious gaps for the stated purpose, and update/delete operations are not applicable.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jrogeriosilva/opf-br-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
