10 servidores MCP para operação de TI: o que cada um expõe e o que checar antes de conectar

Autor: Pedro Tebaldi PM do KeepGreen

Publicado set/2026

Sobre TI em geral, o assistente de IA que sua equipe já usa responde bem. Pergunte qual host está em alerta agora, quantos chamados de rede entraram nesta semana ou qual pod reiniciou três vezes desde ontem: ele não sabe. O que falta não é raciocínio, é acesso.

Servidores MCP resolvem esse acesso. Eles publicam as funções de uma ferramenta em um formato que o agente consegue listar e chamar sozinho, ou seja, sem exportação manual. A oferta explodiu: em consulta de 18 de agosto de 2026, o registro oficial do protocolo trazia 22.651 servidores publicados, sendo 22.401 ativos.

Encontrar opção deixou de ser o problema. Escolher virou o problema, porque quase toda lista disponível hoje foi escrita para quem programa, não para quem opera. O recorte aqui é de operação: dez servidores que um analista de NOC, de monitoramento ou de service desk conecta e usa no mesmo dia. Vem primeiro o critério de escolha, depois o risco de permissão.

O que muda quando o agente alcança as ferramentas da operação

Três papéis organizam o protocolo. Ao lado da ferramenta fica o servidor MCP, que expõe as funções dela como tools. O cliente é o assistente que você já usa. Já o agente descobre as tools disponíveis, escolhe qual chamar e recebe o resultado estruturado de volta.

Na rotina é que a diferença aparece. Antes, você exportava CSV do Zabbix, colava no chat e pedia interpretação. Agora o agente consulta a API sozinho, cruza o alerta com o chamado aberto e devolve a resposta com os dados do momento. Ou seja, o dado deixa de passar pela sua mão. O passo a passo dessa integração com o Zabbix mostra, além disso, a arquitetura em detalhe.

Basta um servidor para mudar o dia. Vários ao mesmo tempo, porém, mudam o desenho da operação. Aí entra outra disciplina, a de coordenar mais de um agente sem que eles se atropelem. Antes de chegar lá, vale entender onde termina o bot e onde começa o agente de verdade.

Como escolher um servidor MCP antes de conectar

Cinco perguntas objetivas bastam para avaliar um servidor MCP. Quem mantém o projeto, quais tools ele expõe, como autentica, se roda em modo somente leitura e se continua recebendo commit. Nessa ordem.

Abandonado e com escrita liberada, um servidor faz mais estrago que a planilha manual que ele veio substituir. Por isso o checklist vem antes da instalação, nunca depois do primeiro susto.

• Veja quem mantém: fabricante ou projeto de comunidade.
• Conte as tools e separe as de leitura das de escrita.
• Exija token de serviço dedicado, nunca sua conta pessoal.
• Comece somente leitura quando existir a flag.
• Cheque o último commit antes de levar para produção.

Servidor oficial do fabricante costuma acompanhar a API quando ela muda. Tem ainda canal de suporte declarado e sobrevive à troca de mantenedor. Servidor de comunidade, por outro lado, cobre o que o fabricante ainda não cobriu, o que hoje inclui boa parte do ferramental de operação.

Ainda assim, nenhum dos dois é descartável por origem. A diferença entra na análise de risco, junto com uma decisão que quase toda lista ignora: o transporte. Servidor local, no modo stdio, só conversa com o cliente da própria máquina. Servidor remoto, em contrapartida, abre porta de rede. Exige, portanto, autenticação, criptografia e revisão de exposição. Comece pelo local.

10 servidores MCP úteis para operação de TI

Três frentes de trabalho organizam a lista: monitoramento e observabilidade, chamado e plantão, infraestrutura e nuvem. Todos foram conferidos no registro oficial em 18 de agosto de 2026, com nome de repositório e mantenedor.

1. Grafana: o mais amplo dos oficiais de observabilidade

Mantido pela própria Grafana Labs, o grafana/mcp-grafana é oficial. Expõe busca e edição de dashboards, consulta a Prometheus com percentis de histograma e consulta a Loki com detecção de padrões em log. Cobre ainda regras de alerta, escalas do OnCall e incidentes do Grafana Incident.

Autentica por token de conta de serviço. Além disso, ele traz a flag --disable-write, que desliga toda operação de escrita. É, por isso, o melhor primeiro servidor para quem quer testar sem colocar produção em risco.

2. Zabbix: cobertura de API sem versão oficial

Aqui a comunidade chegou antes. O mhajder/zabbix-mcp expõe a API do Zabbix ao agente: hosts, templates, triggers, problemas, eventos e janelas de manutenção. A Zabbix SIA, no entanto, ainda não publicou servidor próprio no registro oficial.

Trate a manutenção do repositório como critério de decisão, portanto. Para quem já tem chamado aberto automaticamente a partir da trigger, o ganho é imediato. O agente passa a ler, dessa forma, os dois lados da mesma ocorrência.

3. Sentry: erro de aplicação em produção

Issues, releases e eventos de erro chegam ao agente pelo getsentry/sentry-mcp, oficial da Sentry. Isso muda a conversa de plantão.

Em vez de abrir o painel e filtrar à mão, você pergunta qual release introduziu a exceção que começou às 3h. Serve, sobretudo, à fronteira entre infraestrutura e desenvolvimento, onde a operação costuma perder tempo provando de que lado está a causa.

4. Elasticsearch: busca em log sem escrever a query

De comunidade, o cr7258/elasticsearch-mcp-server expõe índices, mapeamentos, saúde do cluster e busca. Na triagem é que o valor prático aparece: o analista descreve o sintoma em português e o agente monta a consulta.

É a porta de entrada mais barata para leitura de log assistida por modelo. Assim, você não troca a stack que já está em produção nem treina a equipe inteira na DSL de consulta.

5. Atlassian: chamado, documentação e catálogo no mesmo lugar

Jira, Confluence e Compass entram pelo mesmo servidor oficial, o atlassian/atlassian-mcp-server. O agente busca, cria e atualiza itens de trabalho. Lê ainda a página de documentação.

Para quem atende chamado no Jira, isso resolve a pergunta mais repetida do service desk: se já existe incidente aberto para este sintoma. A resposta vem, inclusive, com o que a base de conhecimento registrou sobre ele, antes da triagem manual.

6. PagerDuty: quem está de plantão agora

Oficial da PagerDuty, o PagerDuty/pagerduty-mcp-server expõe incidentes, escalas de plantão, políticas de escalação e notificações. Responde, portanto, o que ninguém quer procurar às 2h da manhã.

Quem está na escala? Qual o próximo nível? Quantos incidentes desta severidade abriram no mês? Ele combina bem com o servidor de observabilidade, isto é, um traz o sintoma e o outro traz o responsável.

7. Kubernetes: estado do cluster em linguagem natural

Mantido pela comunidade do projeto containers, o containers/kubernetes-mcp-server atende Kubernetes e OpenShift. Deixa o agente listar recursos, ler evento e puxar log de pod sem passar pelo kubectl.

Cuidado com o escopo: o mesmo caminho que lê também aplica mudança. Comece, por isso, com um ServiceAccount de leitura, restrito ao namespace que interessa. Compare, em seguida, o resultado com o seu monitoramento de Kubernetes antes de liberar escrita.

8. Terraform: infraestrutura declarada com menos tentativa e erro

Gerar Terraform mais preciso é o que o hashicorp/terraform-mcp-server, oficial, entrega ao agente. Automatiza ainda fluxos do HCP Terraform e do Terraform Enterprise.

Na consulta a provider e a módulo é que está o ganho. O agente busca a documentação da versão certa, em vez de inventar argumento que não existe. Para equipe que revisa plano antes de aplicar, portanto, o risco fica contido pelo processo que já roda.

9. Azure: catálogo amplo, ainda em beta

Publicado no registro em versão beta, o microsoft/mcp reúne as tools de Azure em um servidor oficial da Microsoft. Ele conecta o agente aos serviços da nuvem, inclusive consulta a recurso e a configuração.

Beta significa contrato instável. Use para leitura e diagnóstico, portanto. Evite embutir em rotina da qual a operação depende. Reavalie a cada atualização, porque tool nova pode chegar com permissão que você não pediu.

10. AWS: servidores remotos por serviço

Outro caminho foi o da AWS. Em vez de um servidor único, ela publicou servidores remotos por serviço. Dois exemplos: o de EKS (gestão e troubleshooting de cluster) e o de ECS (gestão de workload).

Esse modelo tem vantagem de escopo: você conecta só o serviço que interessa, sem abrir a conta inteira ao agente. Em contrapartida, cada frente nova exige uma decisão de acesso separada, o que é trabalho a mais na governança.

Três ausências são propositais. GitHub, Playwright e Notion aparecem em quase toda lista de servidores MCP. Contudo, servem melhor a quem escreve código do que a quem sustenta o ambiente. Se a sua rotina passa por repositório de IaC, adicione o de GitHub posteriormente. Comece, em resumo, pelos que respondem à pergunta do plantão.

O risco que ninguém coloca na lista

Por trás da conveniência, um servidor MCP é componente de infraestrutura, com porta, credencial e superfície de ataque. Tratá-lo como plugin de produtividade é o erro caro.

Não é risco hipotético. O levantamento mais recente da Trend Micro encontrou 1.467 servidores expostos na internet, sem autenticação de cliente nem criptografia de tráfego. São quase o triplo dos 492 da varredura inicial.

Quanto à credencial, a regra do protocolo é explícita. A especificação de segurança determina que o servidor não pode aceitar token emitido para outro destino.

Ela desaconselha, além disso, escopo coringa e recomenda sandbox para servidor local, que roda com os mesmos privilégios do cliente. Na prática, três decisões resolvem a maior parte do risco.

Crie, antes de tudo, uma credencial de serviço por servidor, com o menor escopo que responda à pergunta. Mantenha, em seguida, o transporte local no primeiro mês, sem publicar nada na internet. Registre, por fim, o que o agente chamou, porque auditoria depois do incidente exige rastro.

Some a isso a revisão humana no que tem consequência. O modelo erra com convicção. A operação convive, portanto, com respostas inventadas que soam plausíveis. A diferença entre leitura e escrita é, nesse sentido, onde essa convivência fica administrável. Leitura pode ir direto ao analista. Escrita, por outro lado, passa por confirmação, sempre.

Onde ainda não existe servidor MCP para quem opera TI

Essa lacuna é medível. Na mesma consulta ao registro oficial, em 18 de agosto de 2026, as buscas por glpi, wazuh, netbox e ansible voltaram sem nenhum resultado. Quatro ferramentas comuns na operação brasileira, zero servidor publicado.

Isso tem consequência direta principalmente para quem roda service desk em GLPI. Enquanto não houver servidor pronto, o caminho é expor as funções que interessam sobre a API REST do próprio GLPI. Comece com escopo de leitura.

Dá trabalho, porém o inventário e a fila de chamados são justamente onde a pergunta do agente rende mais. Equipes que preferem não construir isso sozinhas costumam apoiar-se em serviço especializado de GLPI para desenhar o escopo.

Para o resto da lacuna vale o mesmo raciocínio. Antes de escrever um servidor do zero, confira se a ferramenta já tem API estável e documentada. Se tiver, o esforço vira embrulho, não integração nova.

Por onde começar na segunda-feira

Escolha um servidor, não cinco. Se você já tem Grafana, comece por ele com a flag de somente leitura ligada. É, assim, o caminho mais curto entre conectar e ter resposta útil. Se o centro da sua operação é o Zabbix, por outro lado, o servidor de comunidade cobre o suficiente para a primeira semana.

Defina antes qual pergunta você quer responder. Vale escolher, por exemplo, uma que hoje custa quinze minutos de garimpo em painel, porque é nela que o ganho aparece medido, não sentido. Depois disso, compare: tempo até a resposta antes, tempo até a resposta agora.

Só então adicione o segundo servidor, de preferência de outra frente. Monitoramento mais chamado devolve contexto que nenhum dos dois entrega sozinho. Mantenha tudo em leitura enquanto a equipe aprende o comportamento do agente. Por fim, escreva o registro de quem autorizou cada escopo.

Quer discutir qual frente conectar primeiro no seu ambiente e como manter o escopo sob controle? Fale com um especialista da OpServices.