Servidor MCP: o que é, como funciona e quem decide o que o agente pode fazer

Até pouco tempo atrás, ligar um assistente de IA a um sistema da empresa era um projeto de integração: alguém escrevia o código que buscava o dado no CRM, formatava e entregava ao modelo. Cada sistema novo, um projeto novo. O MCP mudou essa conta, e por isso o termo começou a aparecer em proposta de fornecedor, em tutorial e no autocompletar do Google ao lado de "WhatsApp", "Power BI" e "Meta Ads".

Este guia é para o gestor que vai autorizar essa ligação. Ele explica o que é um servidor MCP sem jargão desnecessário, mostra o que a especificação oficial garante e, principalmente, o que ela diz com todas as letras que não garante. No fim, há um roteiro de liberação em etapas, do agente que só lê ao agente que age sozinho.

O que é um servidor MCP?

Um servidor MCP é a peça que fica do lado do sistema e traduz o que esse sistema sabe fazer para uma linguagem que qualquer agente compatível entende. Ele anuncia uma lista de ferramentas (ações, como "criar contato" ou "buscar pedidos"), de recursos (dados para consulta) e de prompts (modelos de instrução prontos). O agente lê essa lista e decide o que chamar.

A especificação divide o arranjo em três papéis. O host é o aplicativo de IA que a pessoa usa. O cliente é o conector que roda dentro do host, um para cada servidor. O servidor é o serviço que oferece contexto e capacidades. Quando alguém diz que "ligou o agente ao CRM por MCP", quer dizer que instalou ou apontou para um servidor MCP daquele CRM.

Uma comparação útil: o servidor MCP está para o agente como uma tomada padronizada está para um eletrodoméstico. Qualquer aparelho com o plugue certo funciona. Isso é ótimo para a conveniência e exige atenção redobrada sobre o que está do outro lado do fio.

De onde veio o MCP e quem mantém o padrão?

A Anthropic abriu o Model Context Protocol em 25 de novembro de 2024, apresentando-o como um padrão aberto para conexões seguras e bidirecionais entre fontes de dados e ferramentas de IA. No anúncio, vieram junto a especificação, kits de desenvolvimento e um repositório aberto de servidores prontos para Google Drive, Slack, GitHub, Git, Postgres e Puppeteer.

A própria especificação registra a inspiração: o Language Server Protocol, que padronizou o suporte a linguagens de programação em editores de código. A ideia é a mesma, levada para a IA: em vez de cada aplicativo construir um conector para cada sistema, todos falam o mesmo protocolo.

O padrão evolui por versões datadas. A vigente quando este texto foi escrito é a especificação 2026-07-28, marcada como a mais recente no site oficial, que também mantém as versões de 2024 e 2025. Para quem vai contratar, a lição prática é simples: pergunte ao fornecedor qual versão o servidor dele implementa.

Qual a diferença entre servidor MCP, API e integração tradicional?

A confusão mais frequente é achar que o MCP substitui a API do sistema. Não substitui: na maioria dos casos, o servidor MCP é uma camada por cima da API que já existe. Ele não cria acesso novo ao dado; ele torna o acesso que já existe utilizável por um agente.

Comparativo elaborado pela Alliance Comunicação a partir da especificação do MCP e da prática de integração.

A linha que mais importa é a terceira. Numa integração tradicional, um programador decidiu antes quais ações acontecem e em que ordem. Com MCP, quem escolhe a ação é o modelo, no meio da conversa, com base no que leu. É por isso que a pergunta de segurança muda de "o código está certo?" para "o que esse agente tem permissão de fazer, e quem confere antes?". O tema dos limites de plano e de chamada na API continua valendo, e está detalhado no guia de integração via API e o limite que o plano do CRM impõe.

Como funciona um servidor MCP por dentro?

A conversa entre cliente e servidor usa mensagens JSON-RPC 2.0, um formato simples de pergunta e resposta. O cliente pede a lista de ferramentas, o servidor responde com nome, descrição e os parâmetros aceitos, e a partir daí o agente pode chamar qualquer uma delas. O que muda de um servidor para outro é o meio por onde essas mensagens passam.

Servidor local, pelo stdio

No modo local, o próprio aplicativo de IA inicia o servidor como um programa no computador e conversa com ele pela entrada e saída padrão (stdio). Nesse caso, a especificação orienta que as credenciais venham do ambiente da máquina, e não do fluxo de autorização. Na prática: a chave do sistema fica num arquivo de configuração local, e o servidor roda com os mesmos privilégios de quem o instalou.

Servidor remoto, pelo HTTP

No modo remoto, o servidor fica hospedado na internet e recebe cada mensagem como uma requisição HTTP para um único endereço. É esse endereço que aparece quando se fala em "URL do servidor MCP remoto": é o que se cola no aplicativo de IA para conectá-lo. Quando há login, a especificação define um fluxo baseado em OAuth 2.1, o mesmo tipo de autorização do "entrar com a conta Google".

Ferramentas, recursos e prompts

Das três ofertas do servidor, as ferramentas são as que pedem mais cuidado, porque executam ações. A especificação descreve ferramentas como execução arbitrária de código e pede que sejam tratadas com a devida cautela. Recursos e prompts expõem dados e instruções; ferramentas mexem no sistema.

O que a especificação garante, e o que ela admite não garantir?

Este é o ponto que os guias mais lidos sobre o tema deixam de fora. A seção de segurança da especificação lista princípios claros: o usuário precisa consentir de forma explícita com todo acesso a dado e toda operação; o host precisa obter consentimento explícito antes de expor dados ao servidor e antes de invocar qualquer ferramenta; e as descrições de comportamento das ferramentas devem ser tratadas como não confiáveis, a menos que venham de um servidor confiável.

Há mais dois detalhes que mudam a leitura. O primeiro: a autorização é opcional no MCP. Um servidor pode simplesmente não ter login, e continua sendo um servidor MCP válido. O segundo: na página de ferramentas, a especificação recomenda que sempre haja uma pessoa no circuito com poder de negar a chamada, e que o aplicativo mostre quais ferramentas estão expostas e peça confirmação nas operações. Recomenda; não obriga.

O padrão define a porta. A fechadura é de quem instala.

Nada disso é defeito escondido. É uma escolha de projeto declarada: um protocolo que conecta qualquer coisa a qualquer agente não tem como saber se uma ação é perigosa no contexto da sua empresa. Quem sabe é você. O problema começa quando a empresa liga o servidor achando que a segurança veio no pacote.

Por que isso importa para quem vai ligar o agente ao CRM ou ao WhatsApp?

Porque, em sistema de negócio, a ação errada tem nome e sobrenome. Um agente com permissão de escrita no CRM pode mudar a etapa de uma oportunidade, apagar um contato ou disparar uma sequência de e-mails. No WhatsApp, pode mandar mensagem a um cliente. Numa conta de anúncios, pode alterar orçamento. Nenhuma dessas ações é exótica: são justamente as ferramentas que um servidor desses costuma oferecer.

Some a isso o fato de que o agente decide com base no que lê. Se um e-mail, um documento ou uma página carregar uma instrução escondida, o agente pode obedecer, problema tratado no artigo sobre prompt injection, a ordem escondida no que o agente lê. O MCP não cria esse risco, mas amplia o estrago possível: quanto mais ferramentas de escrita o agente tiver, maior o dano de uma instrução maliciosa obedecida.

A consequência para o gestor é direta: a decisão de quais ferramentas ligar, com qual escopo e com qual aprovação é uma decisão de negócio, não um detalhe técnico que se delega ao fornecedor sem perguntar.

Servidor oficial ou de comunidade: como escolher?

Existe um MCP Registry oficial, mantido pelo projeto e descrito como repositório centralizado de metadados de servidores públicos. Ele verifica o nome: o servidor publicado sob um domínio precisa provar que é dono daquele domínio ou da conta no GitHub. O que ele não faz é auditar o código. A própria documentação diz que a varredura de segurança fica com os repositórios de pacotes e com os catálogos que consomem o registro.

Para ver o que isso significa na prática, consultamos o registro em 22/10/2026 buscando por "whatsapp". Vieram mais de 30 servidores, todos publicados por empresas e desenvolvedores terceiros, nenhum sob o domínio da Meta. Um deles se descreve como funcionando pelo seu próprio número via QR code, sem a API da Meta. Estar listado, portanto, não diz nada sobre se o caminho usado respeita as regras da plataforma.

Os critérios que usamos para decidir:

• Quem publica: o servidor é do próprio fabricante do sistema, de um parceiro dele ou de um desenvolvedor independente?
• Por onde ele fala com o sistema: pela API oficial, com credencial que você controla, ou por automação de tela e sessões não oficiais?
• Onde roda: local, na sua máquina, ou remoto, na infraestrutura de alguém, e nesse caso por onde passam os seus dados?
• Que ferramentas expõe: dá para desligar as de escrita e ficar só com as de leitura?
• Que escopo pede: acesso mínimo para a tarefa ou acesso total à conta?

Servidor local merece um cuidado à parte. O guia de boas práticas de segurança do MCP descreve o caso de comandos de instalação maliciosos e lembra que servidores locais rodam com os mesmos privilégios do aplicativo que os inicia. Instalar um servidor desconhecido é, na prática, executar um programa desconhecido no computador.

Como liberar um servidor MCP na empresa, passo a passo

O roteiro abaixo é o que a Alliance usa ao conectar agentes a sistemas de clientes. A lógica é ampliar o acesso em degraus, só depois de o degrau anterior se provar.

1. Liste as ferramentas antes de ligar

Peça ao fornecedor, ou extraia com uma ferramenta de teste, a lista completa de ferramentas do servidor. Separe em duas colunas: as que leem e as que escrevem, alteram ou enviam algo. Se o fornecedor não souber dizer, isso já é uma resposta.

2. Crie uma credencial só para o agente

Nunca use a conta de um diretor ou a chave de administrador. Crie um usuário ou um token próprio para o agente, com o menor perfil que permita a tarefa. Assim, o que ele fizer fica registrado em nome dele e o acesso pode ser revogado sem afetar ninguém.

3. Comece só com leitura

Na primeira etapa, o agente consulta e responde, mas não altera nada. É aqui que se descobre se ele entende os dados: se lê a etapa do funil certa, se confunde campos, se a resposta bate com o que está no sistema.

4. Libere escrita com aprovação humana

Quando a leitura estiver confiável, libere as ações de escrita com confirmação: o agente prepara, mostra o que vai fazer e uma pessoa aprova. O desenho de quando desviar para revisão está no artigo sobre automação com IA e o desvio para revisão humana.

5. Automatize só o que for de baixo risco

Por último, deixe rodar sozinhas as ações reversíveis e de pouco impacto, como registrar uma nota ou marcar uma tarefa. Envio para cliente, mudança de valor e exclusão continuam passando por uma pessoa. E revise os registros e os escopos de tempos em tempos, porque servidores ganham ferramentas novas em atualizações.

Quais os erros mais comuns ao conectar um agente por MCP?

• Conceder todos os escopos de uma vez para evitar novos pedidos de permissão. O guia oficial de segurança cita exatamente isso, e o uso de escopos curinga como "acesso total", entre os erros comuns.
• Usar a credencial pessoal de alguém, o que mistura o que o agente fez com o que a pessoa fez e impede revogar só o agente.
• Confiar na descrição da ferramenta. A especificação manda tratá-la como não confiável quando o servidor não é de confiança: o nome "consultar_pedido" não garante que ela só consulta.
• Instalar servidor local de origem desconhecida a partir de um tutorial, copiando um comando sem ler.
• Deixar a aprovação ligada no começo e desligar por cansaço, sem antes separar o que é de baixo risco.
• Não registrar as chamadas. Sem log, não há como reconstruir o que o agente fez quando algo der errado.

Repare que nenhum desses erros é do protocolo. Todos estão do lado de quem implementa, que é exatamente onde a especificação disse que estariam.

Como testar um servidor MCP e medir se a conexão está segura?

O projeto mantém uma ferramenta de referência para isso, o MCP Inspector, que roda pelo navegador, pela linha de comando ou pelo terminal. Com ele, um técnico conecta no servidor, lista as ferramentas, vê os parâmetros e chama cada uma isoladamente, sem passar por um modelo de IA. É o jeito mais rápido de saber o que o servidor realmente faz.

Para acompanhar depois de ligado, estes são os indicadores que fazem sentido:

1. Número de ferramentas de escrita habilitadas, que deve cair ou se manter, nunca crescer sem decisão.
2. Taxa de recusa nas aprovações humanas, que mostra se o agente está propondo ações sensatas.
3. Chamadas fora do horário ou do padrão esperado, que são o primeiro sinal de uso indevido.
4. Escopos efetivamente concedidos ao token, comparados com os que a tarefa exige.
5. Tempo para revogar o acesso do agente, testado de verdade ao menos uma vez.

O que muda conforme o sistema que o agente vai acessar?

O mesmo protocolo serve para sistemas com riscos muito diferentes. A tabela resume como a Alliance calibra a liberação em cada caso, partindo do que costuma dar errado em cada um.

Recomendação da Alliance Comunicação; não substitui a análise do caso concreto.

Há um ponto que vale para todos: dado pessoal de cliente passando por servidor de terceiro tem implicação de LGPD, porque o fornecedor desse servidor pode passar a tratar dados em nome da sua empresa. Vale entender o contrato antes de entender o código.

Por onde começar hoje

Comece pelo inventário: quais agentes a equipe já usa, quais servidores estão ligados e com que credencial. Depois escolha um único caso de uso de leitura, de preferência com dado que já é consultado manualmente toda semana, e rode o roteiro de liberação nele. Um caso pequeno bem controlado ensina mais do que dez conexões abertas ao mesmo tempo.

Se a dúvida for anterior, sobre onde um agente faria diferença na operação, o diagnóstico de marketing gratuito aponta onde estão os gargalos de dados e de processo. E, quando for a hora de construir, o serviço de agentes de IA da Alliance desenha a conexão com escopo, aprovação e registro desde o primeiro dia.