Catálogos MCP estão se tornando o novo portal interno para desenvolvedores

Docker publicou um post na sexta-feira sobre Catálogos e Perfis MCP Personalizados sendo geralmente disponíveis, e meu primeiro pensamento não foi sobre Docker de forma alguma.

Meu primeiro pensamento foi: isso é Backstage, mas para agentes.

Não literalmente, obviamente. Nenhum catálogo de software, nenhum placar de serviços, nenhum mercado de plugins com a mesma energia de um projeto de código aberto abandonado. Mas estruturalmente? O mesmo padrão arquitetônico está aparecendo.

Portais internos para desenvolvedores deram aos humanos uma visão curada de ferramentas, serviços, permissões e infraestrutura. Os catálogos MCP dão aos agentes a mesma coisa. Uma coleção curada, governada e versionada de capacidades que uma entidade — seja um humano ou um agente — pode descobrir e usar.

E assim como a onda dos portais internos para desenvolvedores, ninguém vai planejar isso até que precise desesperadamente.

o que o docker realmente anunciou

Deixe-me resumir rapidamente o recurso, porque o ângulo é mais interessante do que o próprio recurso.

O Docker agora permite que você crie Catálogos MCP Personalizados — coleções curadas de servidores MCP que sua organização aprova. Você agrupa ferramentas internas ao lado de públicas, envia o catálogo como um artefato OCI para um registro de contêiner e o compartilha com sua equipe.

Então, existem os Perfis — agrupamentos nomeados de servidores MCP que os desenvolvedores podem alternar. Um perfil "de codificação" com servidores Playwright e GitHub. Um perfil "de planejamento" com Notion, Atlassian e Markitdown. Perfis também podem ser compartilhados como artefatos OCI, para que as equipes possam padronizar em configurações que funcionam.

Do ponto de vista do Docker, esses recursos resolvem um problema real: a adoção do MCP está crescendo rapidamente, e as equipes precisam padronizar o que é confiável sem restringir fluxos de trabalho individuais.

Isso é verdade. Mas a parte interessante é para onde esse padrão está indo.

o paralelo do portal interno para desenvolvedores

Se você esteve por aí na engenharia de plataformas por alguns anos, isso deve parecer familiar.

Backstage, Port, Cortex e o restante do espaço de portais internos para desenvolvedores todos resolvem o mesmo problema fundamental: as organizações têm muitas ferramentas, serviços e superfícies de infraestrutura para os humanos descobrirem e navegarem sozinhos. Alguém precisa curar o catálogo, definir os caminhos dourados, definir as permissões e garantir que o desenvolvedor não precise saber tudo para entregar.

Os catálogos MCP resolvem o mesmo problema pela mesma razão, mas o consumidor é diferente.

Em vez de um humano navegando em um catálogo de serviços para descobrir qual equipe possui a API de pagamentos, um agente navega em um catálogo MCP para descobrir quais ferramentas pode usar para investigar um incidente de pagamento. Em vez de um humano verificando um placar para ver se um serviço atende aos padrões de implantação, um agente verifica um perfil para ver quais ferramentas são apropriadas para operações de produção versus experimentação de desenvolvimento.

O consumidor muda. A arquitetura não.

por que isso importa mais do que parece

O detalhe entediante é o que torna isso importante.

O Docker está empacotando catálogos MCP como artefatos OCI. Envie-os para um registro, puxe-os para o tempo de execução do seu agente, versioná-los, assiná-los, controlar o acesso da mesma forma que você controla imagens de contêiner.

Isso é exatamente como as ferramentas de infraestrutura devem funcionar.

Em vez de cada desenvolvedor configurar conexões MCP em arquivos JSON, as equipes de plataforma enviam um catálogo. Em vez de cada agente descobrir independentemente ferramentas na internet aberta, o catálogo define o que está disponível. Em vez de equipes de segurança tentando auditar centenas de configurações individuais de servidores MCP, elas revisam um artefato de catálogo.

O mesmo padrão que fez dos registros de imagens de contêiner o centro da infraestrutura de implantação agora está tornando-os o centro da infraestrutura de ferramentas de agentes.

Nenhuma nova infraestrutura para construir. O mesmo mecanismo de distribuição, conteúdo diferente.

perfis são limites de permissão disfarçados

O conceito de Perfil é a parte que continua me atraindo.

O Docker apresenta Perfis como uma forma de organizar fluxos de trabalho — codificação versus planejamento versus pesquisa. Esse é um ponto de partida perfeitamente aceitável. Mas os Perfis também são limites de permissão.

Se você definir um perfil para trabalho de SRE, ele deve incluir ferramentas de investigação de incidentes. Se você definir um perfil para desenvolvimento de aplicativos, ele deve incluir ferramentas de código e teste. Se você definir um perfil para automação CI, ele deve incluir ferramentas de implantação e monitoramento. Cada perfil define implicitamente o que um agente operando nesse contexto está autorizado a fazer.

O catálogo de ferramentas se torna a superfície de controle de acesso.

Isso não é um exagero. O próprio roteiro do Docker menciona controles de governança e políticas para restringir o uso do MCP a catálogos aprovados, e a Governança de IA do Docker, anunciada na semana passada, adiciona controle centralizado sobre acesso à rede, credenciais e permissões de ferramentas.

A direção é clara: o catálogo é onde a governança acontece.

o trabalho da equipe de plataforma está mudando novamente

Continuo voltando à mesma observação ao longo dos últimos vários posts aqui.

Quando os agentes usam ferramentas, o trabalho da equipe de plataforma não é mais apenas "definir como os humanos implantam em produção." É também "definir o que os agentes podem descobrir, usar e automatizar."

Os catálogos MCP dão às equipes de plataforma um mecanismo concreto para esse segundo trabalho.

• Quais servidores MCP são confiáveis?
• Quais ferramentas em cada servidor são seguras para expor?
• Quais perfis devem existir para diferentes funções?
• Quem pode publicar um catálogo?
• Como os catálogos são versionados e atualizados?
• O que acontece quando uma API interna muda e o servidor MCP quebra?
• Como auditamos quais ferramentas os agentes realmente usaram?

Essas são questões de engenharia de plataforma com um toque de IA.

Se você já executa um portal interno para desenvolvedores, deve estar pensando se ele também deve atender aos agentes. Talvez os agentes autentiquem na mesma API de catálogo. Talvez eles leiam definições de serviço, metadados de implantação, links de runbook e informações de propriedade através do MCP em vez de uma interface humana.

Se você não executa um portal interno para desenvolvedores, os catálogos MCP podem ser a primeira plataforma voltada para agentes que sua empresa constrói. Isso parecerá familiar para qualquer um que tenha gerenciado um registro de pacotes ou um registro de contêiner. As perguntas são as mesmas, a distribuição é familiar. Apenas o consumidor mudou.

o catálogo se torna a superfície de governança

A mudança crítica é esta: uma vez que os agentes descobrem ferramentas através de um catálogo, o catálogo não é mais um recurso de conveniência. É o sistema de controle de acesso.

Se um servidor MCP malicioso for adicionado a um catálogo, todo agente que usa esse catálogo ganha uma nova capacidade que não foi projetada para ter. Se um catálogo contém um servidor mal configurado com permissões amplas, o agente herda essas permissões. Se um catálogo não for atualizado quando uma API interna muda, os agentes começam a falhar silenciosamente.

Esse é o mesmo conjunto de preocupações que fez com que os registros de pacotes exigissem assinatura, varredura, controle de acesso e auditoria.