Conecte seu agente de IA (MCP)

Dê ao Claude Code, Cursor ou qualquer agente compatível com MCP acesso seguro e somente leitura às suas falhas de CI para que ele possa fazer triagem e corrigi-las a partir do seu editor.

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.

O que um agente conectado pode fazer#

O servidor expõe sete capacidades: cinco 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 e não truncados da etapa que falhou, incluindo saída que o GitHub esconde em seu visualizador de logs. Segredos são removidos dos logs antes de 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.

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. A única escrita em que uma chave pode optar na criação é o dispatch de workflow (mcp:dispatch), e ela nunca 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 instantaneamente em Settings, API Keys; chaves revogadas ficam listadas 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 é exatamente por isso que o dispatch é 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 é instantânea 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.