Contribuindo para a Pilha de Infraestrutura do Agente: 4 PRs em 3 Repositórios em um Final de Semana

A maioria das contribuições de código aberto existe em isolamento. Você corrige um bug aqui, adiciona um recurso ali. Mas ocasionalmente você tem a chance de contribuir em todo um ecossistema de uma maneira em que cada PR reforça os outros. Foi isso que aconteceu quando passei um final de semana contribuindo para três projetos na pilha de infraestrutura do agente MCP -- e, nesse processo, fiz do Bitcoin um cidadão de primeira classe em todos eles.

A Pilha

Três projetos, três camadas:

• agentregistry -- a camada de descoberta onde os desenvolvedores encontram e instalem servidores MCP
• agentgateway -- a camada de proxy que adiciona limitação de taxa, autenticação e observabilidade aos servidores MCP
• kagent -- a camada de orquestração do Kubernetes que implanta agentes de IA com acesso a ferramentas

Cada projeto resolve um problema diferente, mas juntos formam a infraestrutura que torna os servidores MCP úteis em produção. Meu objetivo era simples: contribuir com um trabalho significativo para cada camada, usando bitcoin-mcp (meu próprio servidor MCP com mais de 40 ferramentas da rede Bitcoin) como o fio condutor.

PR 1: Corrigindo uma Falha no CLI em agentregistry

O problema: Executar arctl skill list --page-size -1 travou todo o CLI com um pânico de limites de fatia do Go. A Issue #368 estava aberta, esperando que alguém a pegasse.

A investigação: O valor da flag --page-size estava sendo passado diretamente para operações de fatia sem qualquer validação. No Go, criar uma fatia com limites negativos causa um pânico em tempo de execução -- sem erro gracioso, sem recuperação, apenas um rastreamento de pilha despejado no terminal.

A correção: Adicionei validação de entrada no nível do comando, antes que o valor chegasse às operações de fatia. Se você passar um tamanho de página negativo agora, receberá uma mensagem de erro clara informando que o valor deve ser positivo. Simples, defensivo e exatamente o que você esperaria de uma ferramenta CLI bem comportada.

O que aprendi: O CLI do agentregistry é construído com Cobra, e o padrão de validação que usei segue a mesma abordagem usada em outras partes do código. Ler o código existente antes de escrever novo código sempre compensa.

PR 2: Corrigindo o Alvo de Lint Quebrado em agentregistry

O problema: make lint estava quebrado desde que a PR #253 removeu golangci-lint da lista de ferramentas do Go. O Makefile ainda tentava invocá-lo via go install, o que não funcionava mais. A Issue #377 documentou a falha.

A investigação: A causa raiz foi uma mudança de dependência que não foi totalmente propagada. Quando o golangci-lint foi removido da gestão de ferramentas Go do projeto, o alvo do Makefile que dependia dele não foi atualizado. Este é um problema clássico em projetos com múltiplos pontos de entrada do sistema de construção.

A correção: Atualizei o alvo de lint para usar o binário golangci-lint instalado no sistema diretamente, com uma mensagem de erro clara se estiver faltando. A mensagem de erro inclui o comando de instalação oficial para que os contribuintes possam se desbloquear imediatamente. Isso está alinhado com a própria documentação do golangci-lint, que recomenda evitar go install para binários de lint devido a problemas de gerenciamento de versão.

O que aprendi: Alvos de CI/lint quebrados são uma barreira silenciosa para os contribuintes. As pessoas clonam o repositório, tentam executar make lint antes de enviar um PR, falham, e ou pulam a lintagem ou desistem de contribuir. Corrigir problemas de experiência do desenvolvedor tem um impacto desproporcional em relação ao tamanho da diferença.

PR 3: Bitcoin ToolServer + Agente SRE para kagent

O problema: O kagent tinha ótimos exemplos para ferramentas web e em nuvem, mas nada para infraestrutura de blockchain. Operadores de nós Bitcoin executando Kubernetes não tinham como implantar um agente de IA que pudesse monitorar sua infraestrutura usando dados reais da blockchain.

A solução: Adicionei dois arquivos ao diretório contrib do kagent:

Primeiro, uma definição de ToolServer bitcoin-mcp (contrib/tools/bitcoin-mcp.yaml) seguindo o padrão estabelecido usado por outras ferramentas da comunidade como context7. Isso informa ao kagent como se conectar ao bitcoin-mcp como um provedor de ferramentas.

Segundo, um Agente SRE Bitcoin (contrib/agents/bitcoin-sre.yaml) com um prompt de sistema detalhado que codifica conhecimento operacional real. O agente sabe como:

• Monitorar intervalos de produção de blocos e alertar sobre atrasos
• Analisar a congestão do mempool e recomendar estratégias de taxas
• Triar picos de taxas examinando a composição do mempool
• Detectar e avaliar reorganizações de cadeia
• Correlacionar problemas de rede com mudanças na taxa de hash

Isso não é um "ajudante de Bitcoin" genérico -- é um runbook codificado como um prompt de agente, escrito por alguém que realmente opera infraestrutura Bitcoin.

O que aprendi: A definição de agente baseada em YAML do kagent é notavelmente limpa. A separação entre definições de ferramentas e prompts de agentes significa que você pode iterar sobre o conhecimento operacional independentemente da configuração da infraestrutura. Estruturei a definição da ferramenta bitcoin-mcp para corresponder exatamente ao context7.mcp.yaml, o que facilitou a revisão do PR porque seguiu um padrão estabelecido.

PR 4: Exemplo de Bitcoin com Limitação de Taxa para agentgateway

O problema: O agentgateway tinha exemplos para servidores MCP genéricos, mas nada demonstrando um caso de uso do mundo real com preocupações de produção como limitação de taxa e CORS.

A solução: Adicionei examples/bitcoin/ com uma configuração completa que proxy bitcoin-mcp através do agentgateway. O exemplo demonstra:

• Limitação de taxa (10 requisições por minuto por padrão) para proteger a API upstream
• Configuração de CORS para clientes MCP baseados em navegador
• Zero configuração adicional -- a API Satoshi hospedada gratuitamente do bitcoin-mcp funciona imediatamente, então qualquer um pode executar o exemplo imediatamente

O README orienta sobre configuração, configuração e consultas comuns para que os desenvolvedores possam ver a proposta de valor do agentgateway em ação: adicionar segurança, observabilidade e gerenciamento de tráfego a qualquer servidor MCP sem modificar o servidor em si.

O que aprendi: O modelo de configuração do agentgateway é bem projetado para exatamente esse tipo de preocupação em camadas. Você define ouvintes, alvos e políticas de forma independente, o que significa que você pode trocar o servidor MCP upstream sem alterar sua configuração de segurança. O exemplo do Bitcoin torna isso concreto de uma maneira que um exemplo genérico de "olá mundo" não consegue.

O Tema Conector

Esses quatro PRs não são apenas quatro contribuições independentes -- eles contam uma história sobre o que significa tornar uma implementação de protocolo pronta para produção.

Ter um servidor MCP (bitcoin-mcp) é o primeiro passo. Mas para ser útil em produção, esse servidor precisa ser descoberto (agentregistry), securável (agentgateway) e implantável (kagent). Ao contribuir para todas as três camadas, o Bitcoin se torna uma implementação de referência que demonstra toda a pilha funcionando em conjunto.

As duas correções de bugs no agentregistry também são importantes. Elas diminuem a barreira para outros contribuintes que possam querer adicionar seus próprios servidores MCP ao registro. Um CLI que não trava e um alvo de lint que realmente funciona são pré-requisitos para uma experiência saudável do contribuinte.

O Que Vem a Seguir

Todos os quatro PRs foram enviados e estão em revisão. Independentemente de serem mesclados no cronograma do hackathon, o trabalho demonstra algo que acredito fortemente: a melhor maneira de contribuir para um ecossistema é usá-lo para algo real.