Conecte seu agente de IA (MCP)

Dê ao Claude Code, Cursor ou qualquer agente compatível com MCP acesso seguro às suas falhas de CI, além de reexecuções de workflow e jobs avulsos em runners novos por opt-in, para que ele possa fazer triagem, corrigir e verificar a partir do seu editor.

Por Daniel Zoghalchali·Latchkey

O Latchkey traz um servidor MCP: seu agente de codificação de IA se conecta a ele com uma chave de API do Latchkey e pode puxar contexto real de falhas de CI (execuções com falha, logs, pacotes de diagnóstico) direto para a sessão do seu editor. Em vez de copiar e colar logs em um chat, seu agente pergunta ao Latchkey diretamente e obtém tudo o que precisa para corrigir a falha.

Esta é a metade de repasse da autocorreção: a autocorreção corrige falhas de ambiente durante a execução e nunca toca no seu código-fonte, então quando o problema real é um bug no seu código, o build falha de forma verdadeira, e essa falha chega aqui como um pacote pronto para correção para o seu agente.

Há dois caminhos de entrada: crie uma chave você mesmo em Settings, API Keys (a configuração abaixo), ou deixe a página AI Insight fazer isso por você. Descobertas que são melhor corrigidas pelo seu próprio agente de codificação oferecem Copy prompt, um prompt pronto para colar no seu agente, e um atalho Set up MCP que cria uma chave chamada coding-agent e mostra o comando exato de conexão. A chave emitida expira em 90 dias e pode executar jobs avulsos em runners cobráveis (o cartão diz isso ao lado do botão), então trate-a como a credencial capaz de gerar gastos que ela é.

O que um agente conectado pode fazer#

O servidor expõe dez capacidades: oito ferramentas que seu agente chama para dados e ações, e dois fluxos de prompt que orquestram uma tarefa inteira:

Você nunca os chama pelo nome. Você faz ao seu agente uma pergunta em linguagem simples, e ele decide qual capacidade a responde. Alguns pareamentos ilustrativos:

Como é uma sessão#

Duas sessões ilustrativas. As palavras exatas, e as respostas exatas do agente, vão variar conforme o agente; o formato da troca é o que importa.

O que há em um pacote de falha#

O pacote de falha entrega ao seu agente o que ele de outra forma reconstruiria manualmente:

• A causa raiz, em linguagem simples.
• O código de saída da etapa que falhou e o arquivo-fonte exato onde o erro surgiu.
• Os logs completos capturados da etapa que falhou, incluindo saída que o GitHub esconde em seu visualizador de logs; logs muito grandes mantêm sua parte final e indicam isso. Segredos são removidos antes de os logs saírem do Latchkey.
• O que a autocorreção já investigou e por que ela recuou, mais a definição do workflow.

Configuração#

$ claude mcp add --transport http latchkey \
    https://latchkey.dev/mcp \
    --header "Authorization: Bearer lk_live_YOUR_KEY"

Reexecutar workflows após uma correção (opt-in)#

Por padrão, uma chave é somente leitura. Se você quer fechar o ciclo (o agente corrige o código, faz push, reexecuta o CI e acompanha até ficar verde), crie uma chave com Allow workflow dispatch marcado. Essa chave carrega adicionalmente o escopo mcp:dispatch, e seu agente pode então disparar execuções workflow_dispatch nos seus repositórios monitorados, acompanhá-las com a ferramenta de status e ler seus logs quando terminarem. Execuções verdes também são legíveis, então o agente pode confirmar a correção, não apenas observar a falha.

• O dispatch funciona apenas em repositórios que seu workspace monitora, e apenas para workflows que declaram o gatilho workflow_dispatch.
• Chaves existentes nunca ganham dispatch retroativamente; crie uma nova chave com a caixa marcada.
• A reexecução roda o que estiver na branch contra a qual você dispara; envie a correção primeiro, depois dispare.

Executar jobs em runners novos (opt-in)#

A segunda escrita por opt-in é executar jobs avulsos. Uma chave criada com Allow running CLI jobs (includes reading) carrega o escopo jobs:run (jobs:read, para status e logs, vem junto com ele), e seu agente pode então usar a ferramenta Executar um job avulso: um comando de shell em um runner novo e isolado do Latchkey, cobrado como minutos de runner comuns do mesmo pool de minutos gratuitos dos seus workflows. O runner começa limpo, sem conteúdo de repositório; jobs que precisam da sua árvore de trabalho passam pela CLI do Latchkey, que a empacota e envia. Allow reading CLI job status and logs é a concessão mais restrita (apenas jobs:read) para uma chave que deve acompanhar jobs, mas nunca iniciá-los.

• Jobs têm por padrão um timeout de 30 minutos, configurável até 2 horas, e o agente escolhe um tamanho de runner (small quando não escolhe).
• Uma chave com jobs habilitados gasta dinheiro: cada job é cobrado pela tarifa padrão por minuto do runner. Nomeie a chave conforme o agente que a detém e dê a ela uma expiração.
• Cancelar um job é uma ação da CLI (latchkey cancel), não uma ferramenta MCP.

Modelo de segurança#

• Somente leitura por padrão. As chaves podem ler dados de falhas e execuções de CI; mudar qualquer coisa no Latchkey ou no GitHub fica desligado por padrão. As escritas em que uma chave pode optar na criação são o dispatch de workflow (mcp:dispatch) e a execução de jobs em runners do Latchkey (jobs:run), e nenhuma delas se estende às configurações do Latchkey nem a ações arbitrárias no GitHub.
• Escopo de workspace. O workspace é derivado da própria chave, então uma chave só pode ver os dados do seu próprio workspace.
• Revogável. Revogue qualquer chave em Settings, API Keys: uma chave com capacidade de escrita (dispatch ou jobs) perde o acesso imediatamente, uma chave somente leitura em cerca de um minuto. Chaves revogadas ficam listadas em uma seção "Revoked (n)" para auditoria.

O que essas três propriedades significam na prática. Somente leitura por padrão limita o raio de impacto de um vazamento: uma chave padrão roubada expõe dados de falha de CI (incluindo trechos de log), razão pela qual você ainda deve protegê-la, mas ela não pode abrir PRs, alterar configurações nem agir no GitHub em seu nome. Uma chave roubada com dispatch habilitado pode, adicionalmente, disparar workflows disparáveis nos seus repositórios monitorados, e uma chave roubada com jobs habilitados pode executar comandos em runners cobráveis no seu workspace, e é exatamente por isso que cada escrita é um opt-in por chave com um aviso na criação, não um padrão. O escopo de workspace significa que não há nada para configurar e nada para errar: a própria chave determina o que ela pode ver, e ela nunca pode ver outro workspace. E como a revogação é rápida e as chaves revogadas continuam listadas para auditoria, a resposta segura a qualquer dúvida é simplesmente revogar e reemitir.

Dois hábitos de baixo esforço que mantêm isso limpo: crie uma chave separada para cada ferramenta ou máquina (o prompt de nomenclatura na criação, como "Cursor on my laptop", existe exatamente para isso), para que revogar uma chave nunca quebre as outras; e escolha a expiração mais curta que se encaixe em como você trabalha, reservando nunca para configurações que você acompanha ativamente. O gerenciamento de chaves fica com proprietários e administradores; veja Equipe e papéis e Segurança e permissões para o modelo mais amplo.

A Latchkey também publica descritores legíveis por máquina para que um agente descubra a superfície sem precisar ser instruído. A Jobs API REST é servida em https://api.latchkey.dev e está totalmente descrita por uma especificação OpenAPI 3.1; o servidor MCP tem seu próprio manifesto listando cada ferramenta e o escopo de que ela precisa.

Cada página de conteúdo do site também tem uma versão em markdown na mesma URL com .md, referenciada no head da página por um link rel="alternate". Ela carrega o mesmo conteúdo sem a marcação da página, o que é muito mais barato para um agente ler.