TL;DR: O Azure SRE Agent foi projetado com três interfaces (CLI interativo, agent mode e MCP server) para atender quatro tipos de chamadores: humanos em incidentes, coding agents, agentes remotos de outros ecossistemas e outras instâncias do agente. A principal conclusão: o MCP server é lançado primeiro porque se integra aos ambientes onde os chamadores já estão, sem exigir intenção explícita, enquanto o CLI requer uma ação deliberada. O design unificado de output e descrições de ferramentas é crucial para o modelo tomar decisões corretas.
Quando começamos a construir o tooling para o Azure SRE Agent, tivemos que responder uma pergunta que parece simples: quem está realmente chamando isso? A resposta se revelou ser quatro tipos de chamadores com quatro necessidades diferentes. Este artigo é sobre por que isso nos levou a construir tanto um CLI quanto um servidor MCP, e o que aprendemos ao projetá-los simultaneamente.
Estamos construindo três interfaces para o Azure SRE Agent: um CLI interativo para humanos em um terminal, um agent mode para coding agents que o spawnam como subprocesso, e um servidor MCP para humanos dentro de coding agents e para agentes remotos em outros ecossistemas. O CLI e o agent mode estão por vir. O servidor MCP é o que está sendo lançado primeiro. Essa ordem não era óbvia no início, e este artigo explica por que chegamos a essa decisão.
Três interfaces, uma pergunta: quem está realmente chamando isso?
Quando começamos a projetar o CLI do Azure SRE Agent, a pergunta que surgia repetidamente era enganosamente simples: quem é o chamador? Um humano às 2 AM durante um incidente? Sim. Mas também um coding agent no meio de uma sessão que quer capacidades do SRE Agent sem sair do VS Code. E um agente SRE da PagerDuty executando um loop de triagem automatizado sem nenhum humano na jogada. E outra instância do Azure SRE Agent que quer delegar uma subtarefa. Quatro chamadores. Mesmo backend. Nenhum deles quer a mesma coisa.
As três interfaces mapeiam para esses chamadores:
- Interactive CLI: humanos em um terminal, conciso e otimizado para incidentes.
- Agent Mode: coding agents como o Copilot CLI que o spawnam como subprocesso.
- MCP Server: humanos dentro de coding agents, e agentes remotos em outros ecossistemas.
O servidor MCP é o que está sendo lançado agora. Eis o porquê.
O CLI requer que alguém vá buscá-lo
O CLI interativo e o agent mode têm algo em comum: o chamador precisa saber que o Azure SRE Agent existe e decidir invocá-lo. Um humano digita um comando. Um coding agent spawna um subprocesso. De qualquer forma, é uma chamada deliberada.
O servidor MCP funciona de forma diferente. Ele se apresenta como ferramentas dentro do ambiente em que o chamador já está. O modelo decide quando usá-las. Um SRE trabalhando no Copilot CLI não abre um terminal separado e digita um comando. Ele faz uma pergunta e a ferramenta certa é acionada. Um agente remoto em um loop da PagerDuty não spawna um subprocesso. Ele fala um protocolo e recebe uma resposta. Essa é a diferença. O CLI requer intenção. O servidor MCP encontra os chamadores onde eles já estão.
Dois chamadores, um protocolo
A superfície MCP tem dois públicos. Eles falam o mesmo protocolo, mas vêm de contextos completamente diferentes.
Humanos dentro de coding agents. Um SRE no VS Code Copilot, Claude Desktop, GitHub Copilot CLI ou Cursor já está em uma sessão: escrevendo um script de deployment, revisando um runbook, depurando um serviço com falha. Eles não querem uma mudança de contexto. Eles querem as capacidades do SRE Agent junto com o trabalho que já estão fazendo. Conecte o servidor MCP uma vez e ele simplesmente está lá.
Agentes remotos em outros ecossistemas. Um agente DevOps da AWS lidando com um incidente cross-cloud pode precisar verificar a saúde de recursos do Azure sem transferir a chamada para um humano. Um agente SRE da PagerDuty pode puxar um resumo de incidente como parte de seu loop de triagem. Uma instância do Azure SRE Agent pode delegar trabalho para outra. O MCP é o que torna tudo isso possível sem integrações personalizadas de ambos os lados. Ambos os lados concordam com o protocolo. Nenhum lado precisa conhecer os internals do outro.
| Chamador | Contexto | O que precisam |
|---|---|---|
| Humano no Copilot CLI / VS Code Copilot | Meio do workflow, sessão de codificação | Resumo legível, overhead mínimo |
| Humano no Claude Desktop / Cursor | Sessão agentic | Ferramentas SRE disponíveis na conversa |
| Agente DevOps AWS | Loop automatizado de incidente | Schema definido, campos estáveis |
| Agente SRE PagerDuty | Pipeline de triagem | Parseável, esparso, sem narrativa |
| Outra instância do Azure SRE Agent | Subtarefa delegada | Contrato agente-a-agente |
Descrições de ferramentas são decisões de produto
Cada ferramenta MCP mapeia para uma capacidade específica do SRE Agent. As ferramentas têm nomes, descrições em linguagem natural e schemas JSON de input. As descrições fazem mais trabalho do que parecem. Quando alguém no Copilot CLI pergunta "o que há de errado com meu API gateway", o modelo lê as descrições das ferramentas para decidir qual chamar. Uma descrição que diz "Retorna status de saúde para um recurso Azure" é invocada de forma menos confiável do que uma que diz "Verifique se um recurso Azure (VM, gateway, database, container) está saudável, degradado ou inacessível. Use isto ao diagnosticar uma interrupção ativa ou validar estado após um deployment." A segunda versão informa ao modelo quando usar a ferramenta, não apenas o que ela faz. PM, engenharia e content design revisaram as descrições juntos. Quando uma invocação falhava nos testes, a correção era quase sempre a descrição, não o schema. Iteramos nas descrições das ferramentas da mesma forma que você iteraria em um system prompt, porque é isso que elas são.
Um formato de output, dois chamadores
O humano dentro de um coding agent e o agente remoto em um loop automatizado querem coisas diferentes da mesma resposta da ferramenta. Um humano quer algo legível. Um agente remoto quer algo parseável. A resposta óbvia é retornar formatos diferentes com base em quem está chamando. Nós não fizemos isso. Cada resposta de ferramenta segue o mesmo contrato: campos definidos, semântica estável, sem preâmbulo, sem reasoning interno, mais um campo summary com uma frase em linguagem simples. Um humano lê o summary. Um agente remoto o ignora e parseia os campos estruturados. O overhead é insignificante em ambas as direções. Consideramos brevemente ramificar com base em uma dica de tipo de chamador no cabeçalho da requisição. O problema: adicionava superfície de manutenção e criava modos de falha sutis quando a dica estava errada ou ausente. Um formato, sempre.
O que é mais difícil do que parece
Statelessness é uma feature para agentes remotos e atrito para humanos. Ferramentas MCP são stateless por design. Cada invocação é independente. Agentes remotos adoram isso; eles não querem gerenciar estado de sessão entre chamadas. Humanos trabalhando interativamente querem que o contexto seja levado adiante. Lidamos com isso tornando cada resposta autossuficiente: a ferramenta retorna contexto suficiente para que o modelo possa construir uma chamada de acompanhamento coerente sem reexplicar a situação. A ferramenta não se lembra. Ela retorna o suficiente para que a memória seja barata para quem a detém.
Você não pode testar o caso de uso do agente remoto da mesma forma que testa o caso de uso humano. Inicie o Copilot CLI, conecte o servidor, faça uma pergunta e você pode observar o que acontece. Você não pode simular facilmente um agente AWS chamando você frio, sem contexto prévio sobre o que o Azure SRE Agent faz. Projetar para esse chamador significou escrever descrições e schemas que funcionam para um modelo encontrando suas ferramentas pela primeira vez, sem vocabulário assumido e sem workflow assumido.
O que vem a seguir
O CLI interativo e o agent mode seguem a mesma arquitetura de três nós. O CLI interativo é para humanos no terminal: conciso, otimizado para incidentes, com divulgação progressiva. O Agent Mode é para coding agents que spawnam o CLI como subprocesso e querem acesso direto às capacidades do SRE Agent sem uma camada de protocolo entre eles. Ambos estão em andamento. Enquanto isso, conecte o SRE Agent ao seu cliente MCP e ele aparecerá onde você já está trabalhando.
Parte de uma série sobre as decisões de design por trás do Azure SRE Agent. Postagens complementares sobre o CLI e agent mode serão publicadas quando forem lançados.
Perguntas Frequentes
-
Por que o MCP server foi priorizado em vez do CLI interativo?
O MCP server se integra ao ambiente onde o chamador já está — como Copilot CLI ou VS Code — sem exigir que ele saiba que o Azure SRE Agent existe e decida invocá-lo. O CLI requer uma ação deliberada (digitar um comando), o que reduz a adoção espontânea. -
Como as descrições das ferramentas MCP afetam o comportamento do modelo?
Elas funcionam como system prompts. Uma descrição genérica como "Retorna status de saúde de um recurso Azure" é menos eficaz do que uma que diz "Use isto ao diagnosticar uma interrupção ativa ou validar estado após um deployment". A descrição informa quando usar a ferramenta, não apenas o que ela faz. -
Por que escolheram um único formato de resposta para humanos e agentes remotos?
Em vez de retornar formatos diferentes dependendo do chamador, optaram por um contrato único com campos estruturados e um campo summary em linguagem natural. Humanos leem o summary; agentes ignoram e parseiam os campos estruturados. Isso reduz complexidade de manutenção e evita falhas quando o tipo de chamador é desconhecido. -
Como lidam com a statelessness dos MCP tools para humanos?
MCP tools são stateless por design. Remote agents adoram, mas humanos querem continuidade. A solução foi tornar cada resposta auto-suficiente: a ferramenta retorna contexto suficiente para que o modelo construa uma chamada de acompanhamento coerente sem reexplicar a situação. O custo de memória é baixo para quem a detém. -
Como testam o uso por agentes remotos que não conhecem o Azure SRE Agent?
Não é possível simular facilmente um agente AWS chamando o serviço pela primeira vez sem contexto. Por isso, as descrições e schemas são escritos para funcionar com um modelo que encontra as ferramentas sem vocabulário ou workflow assumido. O foco é em descrições e schemas autoexplicativos.
Artigo originalmente publicado por dbandaru (Microsoft) em Azure Updates - Latest from Azure Charts.
