O que é um servidor MCP? Como funcionam o MCP e o MCP UI em 2026

Em 1º de abril de 2025, a Invariant Labs publicou uma ferramenta chamada add. Ela recebia dois números e devolvia a soma. A descrição dela também carregava um bloco marcado como IMPORTANT, invisível na interface do cliente, que mandava o modelo ler ~/.cursor/mcp.json e ~/.ssh/id_rsa e enviar os dois arquivos para fora por um parâmetro sobrando. O modelo obedeceu. O usuário viu uma conta de somar.

Essa demonstração é a introdução mais útil aos servidores MCP que eu conheço, porque mostra as duas metades de uma vez. O protocolo funcionou exatamente como foi projetado: um cliente de IA descobriu uma ferramenta, leu a descrição e a chamou. O modelo de confiança era a parte que ninguém tinha construído ainda.

O que é um servidor MCP

Um servidor MCP é um programa que expõe ferramentas, dados e prompts a aplicações de IA por meio do Model Context Protocol (MCP). A documentação oficial define o MCP como “um padrão de código aberto para conectar aplicações de IA a sistemas externos”. Um cliente de IA como Claude, ChatGPT, Visual Studio Code ou Cursor se conecta ao servidor, pergunta o que ele oferece e usa esses recursos em nome do usuário.

A Anthropic anunciou o MCP em 25 de novembro de 2024 com seis servidores prontos: Google Drive, Slack, GitHub, Git, Postgres e Puppeteer. A OpenAI adotou o protocolo em março de 2025. O Google DeepMind veio em seguida, em abril. Em dezembro de 2025, a Anthropic doou o protocolo para a Agentic AI Foundation, um fundo direcionado sob o guarda-chuva da Linux Foundation, cofundado por Anthropic, Block e OpenAI.

O problema que ele resolve é a multiplicação. Antes do MCP, cada aplicativo de IA que queria acessar o GitHub escrevia seu próprio conector, e cada fornecedor criava uma conexão por aplicativo de IA. Dez modelos e dez ferramentas poderiam exigir cem integrações. O MCP reduz esse número para vinte: cada cliente implementa o protocolo uma vez e cada sistema expõe um servidor.

Pense nele como o contêiner de navio das integrações de IA. Antes dos contêineres, cada porto carregava cada mercadoria à mão, com seus próprios guindastes e sua própria equipe. O contêiner padronizou a caixa, e assim qualquer navio, guindaste ou caminhão podia mover qualquer carga. Ele não padronizou o que ia dentro da caixa, e nunca inspecionou o conteúdo. O MCP faz o mesmo acordo. Guarde a segunda metade, porque ela volta na seção de segurança.

Como funciona um servidor MCP

A especificação atual, versão 2026-07-28, usa mensagens JSON-RPC 2.0 entre três papéis. A descrição que ela mesma dá cabe em três linhas: hosts são “aplicações de LLM que iniciam conexões”, clientes são “conectores dentro da aplicação host” e servidores são “serviços que fornecem contexto e recursos”.

Host, cliente, servidor

O host é a aplicação em que você digita: Claude Desktop, uma IDE, o seu próprio agente. Dentro dele roda um cliente para cada conexão com um servidor. O servidor fica do outro lado e conversa com o sistema real, seja um banco de dados Postgres, a API do GitHub ou uma pasta no seu disco. O host decide o que o modelo vê e o que o usuário precisa aprovar. O servidor decide o que o sistema subjacente vai fazer.

1. Host Claude Desktop · uma IDE · o seu próprio agente

   mostra as ferramentas ao modelo e pede o consentimento do usuário

2. Cliente um por conexão com servidor

   fala JSON-RPC via stdio ou Streamable HTTP

3. Servidor MCP ferramentas · recursos · prompts

   descreve o que oferece e executa as chamadas

4. Sistema subjacente banco de dados · API SaaS · arquivos locais

   faz o trabalho

Ferramentas, recursos e prompts

Um servidor pode oferecer três tipos de coisa:

• Ferramentas (tools) são funções que o modelo pode executar: create_issue, query_orders, send_email. Cada uma tem um nome, uma descrição e um JSON Schema para as entradas.
• Recursos são contexto e dados para o usuário ou o modelo lerem: um arquivo, o esquema de um banco de dados, um registro.
• Prompts são mensagens e fluxos de trabalho prontos que o usuário pode escolher, como “resuma este pull request”.

As ferramentas ficam com quase toda a atenção porque agem. É também por isso que carregam quase todo o risco.

Uma chamada de ferramenta, passo a passo

A revisão 2026-07-28 tornou o MCP stateless, ou seja, sem estado. Não existe mais o handshake initialize: cada requisição leva a versão do protocolo e os recursos do cliente em um campo _meta, e os servidores precisam implementar um método server/discover para que um cliente possa perguntar de antemão o que eles suportam. Uma única chamada de ferramenta agora funciona assim:

1. O usuário pede: abra um ticket para este bug

2. Passo 1

   Descoberta

   • O cliente pode chamar server/discover para saber versões e recursos
3. Passo 2

   Listar ferramentas

   • tools/list devolve nomes, descrições e esquemas de entrada
4. Passo 3

   O modelo escolhe uma ferramenta

   • O host repassa as definições das ferramentas ao modelo
5. Passo 4

   Consentimento do usuário

   • A especificação diz que os hosts devem obter consentimento explícito antes de invocar qualquer ferramenta
6. Passo 5

   Chamada

   • tools/call com os argumentos, versão do protocolo em _meta

7. Falta alguma entrada? O servidor devolve input_required; o cliente tenta de novo com as respostas

   Passo 6

   Resultado

8. O resultado volta para o modelo como contexto

O passo 6 é novo nesta revisão. Um servidor que precisa de mais informações não envia mais uma requisição própria de volta ao cliente. Ele devolve um resultado marcado como input_required, o cliente coleta a resposta e repete a chamada original. A especificação chama isso de padrão Multi Round-Trip Request.

Transportes: stdio e Streamable HTTP

A especificação define dois transportes padrão:

• stdio: o cliente inicia o servidor como subprocesso e troca JSON-RPC delimitado por quebras de linha pela entrada e saída padrão. É assim que roda a maioria dos servidores locais, e isso significa que o servidor roda na sua máquina com os seus privilégios.
• Streamable HTTP: cada mensagem é um HTTP POST para um único endpoint, e as respostas voltam como um objeto JSON ou como um fluxo de eventos restrito àquela requisição. É assim que rodam os servidores remotos hospedados.

O antigo transporte HTTP+SSE está formalmente obsoleto. A revisão 2026-07-28 também removeu as sessões no nível do protocolo e o cabeçalho Mcp-Session-Id. Um servidor que precisa manter estado entre chamadas agora gera o próprio identificador e o recebe de volta como um argumento comum da ferramenta.

Autorização

A autorização no MCP é opcional e só se aplica ao HTTP. No stdio, a especificação diz que os servidores devem buscar as credenciais no ambiente. No HTTP, um servidor MCP protegido atua como servidor de recursos OAuth 2.1. Ele precisa publicar OAuth Protected Resource Metadata (RFC 9728) para que os clientes encontrem seu servidor de autorização. Os clientes precisam indicar exatamente o servidor a que um token se destina (indicadores de recurso da RFC 8707). Os servidores precisam rejeitar qualquer token que não tenha sido emitido para eles, e as orientações de segurança declaram explicitamente proibido o “token passthrough”, ou seja, repassar sem alterações o token de um cliente para uma API a jusante.

Essa última regra importa mais do que parece. Um servidor que repassa qualquer token que recebe vira um proxy para quem tiver um.

O que o MCP UI acrescenta: servidores que devolvem uma interface

Respostas em texto deixam de funcionar no momento em que alguém precisa comparar quarenta linhas, ajustar um formulário com doze campos ou aprovar um lote de mudanças uma a uma. “MCP UI” é o nome com que as pessoas buscam a solução: um servidor devolve uma interface interativa que aparece dentro do cliente de IA, ao lado da conversa.

Vale definir o estágio do projeto com precisão. A ideia começou com o MCP-UI, um projeto da comunidade. A OpenAI criou um mecanismo semelhante em seu Apps SDK. O projeto MCP propôs um padrão compartilhado com ambas as iniciativas em 21 de novembro de 2025 e publicou o MCP Apps em 26 de janeiro de 2026 como sua primeira extensão oficial. Os pacotes MCP-UI agora implementam esse padrão e continuam sendo um espaço de experimentação para melhorias futuras.

Então, hoje, MCP UI quer dizer MCP Apps. É oficial, e é uma extensão, não o núcleo do protocolo. Extensões são opcionais: cliente e servidor precisam suportá-las, e a documentação diz com todas as letras que “o suporte dos hosts varia conforme o cliente”. A documentação do MCP Apps lista Claude, Claude Desktop, VS Code GitHub Copilot, Microsoft 365 Copilot, Goose, Postman, MCPJam e Archestra.AI como hosts compatíveis. Um servidor cujas ferramentas devolvem interface ainda precisa funcionar para um cliente que só mostra texto.

Na mecânica, ele reaproveita as próprias peças do MCP:

1. A descrição de uma ferramenta inclui um _meta.ui.resourceUri que aponta para um recurso ui://.
2. O host busca esse recurso, uma página HTML com seus scripts, e pode pré-carregá-lo antes de a ferramenta ser chamada.
3. O host o renderiza em um iframe isolado (sandbox) que não consegue ler a página principal, os cookies dela nem o armazenamento.
4. O app e o host conversam via postMessage em um dialeto JSON-RPC do MCP. O app pode pedir chamadas de ferramentas, e o host decide quais permite.

O custo é real. Agora você está entregando um front-end web dentro da aplicação de outra pessoa, com uma política de segurança de conteúdo que precisa declarar, regras de renderização que não controla e uma alternativa em texto para cada host que a ignorar. O ganho é que o trabalho de aprovação deixa de ser uma transcrição de chat. A lista de bons usos da documentação termina com “aprovar relatórios de despesas, revisar mudanças de código ou fazer a triagem de issues”, e esse é o centro honesto da questão: o MCP UI é melhor em decisões, não em decoração.

Um exemplo da Tajo somente para leitura

A interface Alto MCP da Tajo inclui query_contacts, que pesquisa contatos armazenados no espaço conectado. Busque um contato existente pelo e-mail e confira o ID retornado, o estado do consentimento por e-mail e a data da última observação. A ferramenta separada get_contact_topic_status lê as assinaturas desse contato por assunto.

Essas chamadas leem dados do espaço. Não buscam uma cópia atualizada no fornecedor, não iniciam sincronização nem enviam mensagens. Também não demonstram que todos os conectores estão ativos. Investigue na origem os dados ausentes ou desatualizados. Um resultado vazio não prova que a pessoa não existe na Brevo.

Use a documentação MCP da Tajo para conectar um cliente compatível e conferir as ferramentas realmente expostas ao seu espaço autorizado. Um painel interativo pode facilitar a revisão quando o aplicativo hospedeiro oferece MCP Apps; o resultado em texto também precisa explicar o que aconteceu.

Uma chamada de ferramenta não é uma sincronização persistente

Uma sincronização recorrente também precisa de agendamento, identidade estável dos registros, progresso salvo, regras de novas tentativas e registro das gravações concluídas. Essas responsabilidades pertencem ao aplicativo que executa o trabalho. O MCP padroniza o acesso às ferramentas; a presença delas em uma lista não fornece essas regras de negócio.

Após um tempo limite, geralmente é possível repetir uma leitura. Um envio ou pagamento pode já ter ocorrido. Preserve o registro da execução e reconcilie o resultado antes de tentar novamente. A confiança do modelo não autoriza a ação nem torna segura sua repetição.

Para a gravação no destino de um caminho concreto de contatos, veja o guia da API da Brevo. Para decidir quando campos calculados merecem uma sincronização própria e mantida, veja ETL reverso.

A conta da segurança vem junto com o protocolo

A objeção merece ser dita por inteiro: “O MCP entrega a um modelo probabilístico uma lista de funções que podem apagar dados e enviar e-mails, e depois confia em textos escritos por estranhos para descrevê-las. Isso não é um padrão de integração. É um ataque à cadeia de suprimentos com especificação.” Quase tudo isso está correto. A especificação concorda com a premissa. A seção de segurança diz que as ferramentas “representam execução arbitrária de código e devem ser tratadas com a devida cautela”, que as descrições das ferramentas “devem ser consideradas não confiáveis, a menos que venham de um servidor confiável”, e que o MCP “não consegue impor esses princípios de segurança no nível do protocolo”.

Este é o histórico até agora:

• Envenenamento de ferramentas (tool poisoning). A divulgação da Invariant Labs de abril de 2025, a ferramenta add lá de cima. O mesmo texto descrevia os rug pulls (puxar o tapete), em que um servidor muda a descrição de uma ferramenta depois que você a aprovou, e o shadowing (sombreamento), em que um servidor malicioso reescreve o comportamento do modelo em relação a um servidor confiável.
• Comprometimento de servidores locais. Em julho de 2025, a JFrog divulgou a CVE-2025-6514 no mcp-remote, versões 0.0.5 a 0.1.15, que permitia a um servidor malicioso executar comandos na máquina do usuário. No mesmo período, a CVE-2025-49596 atingiu o próprio MCP Inspector da Anthropic, distribuído sem autenticação por padrão.
• Inflação de scopes. As boas práticas de segurança oficiais dão nome ao padrão: tokens que recebem files:* ou admin:* logo de cara porque um servidor listou todos os scopes e o cliente pediu todos.
• Preocupação oficial. Em maio de 2026, a National Security Agency dos EUA afirmou que a “rápida proliferação” do MCP “ultrapassou o desenvolvimento do seu modelo de segurança”.

Onde a objeção erra é na conclusão. A solução nunca foi parar de conectar modelos a sistemas; as equipes já faziam isso com chaves de API cruas coladas em prompts e scripts, sem nenhuma trilha de auditoria. A solução é tratar um servidor MCP como qualquer outra dependência privilegiada:

• Instale servidores apenas de fontes a quem você confiaria as mesmas credenciais fora do MCP.
• Prefira servidores remotos com OAuth e scopes estreitos a binários locais que guardam chaves de longa duração.
• Exija aprovação humana para toda escrita e registre quem aprovou o quê.
• Fixe as versões dos servidores e revise de novo quando a descrição de uma ferramenta mudar.
• Exponha ferramentas moldadas à tarefa, não uma API inteira. Um modelo não consegue abusar de um endpoint de exclusão que nunca foi exposto.

O protocolo padronizou a caixa. Inspecionar a carga continua sendo trabalho seu.

Criar um servidor MCP ou usar um existente

Diretórios públicos como o mcp.so catalogam servidores criados pela comunidade, e muitos fornecedores de SaaS publicam os seus. A Brevo, por exemplo, oferece um servidor MCP que também é dividido em servidores individuais, de modo que um agente pode receber acesso aos contatos sem receber as campanhas. A decisão tem menos a ver com esforço e mais com quem deve ser dono do formato das ferramentas.

Qual servidor MCP o seu agente deve usar?

1. O fornecedor publica um servidor que cobre a tarefa

   Use o servidor do fornecedor

   Ele acompanha a API e o fornecedor faz a manutenção.

2. Um único sistema, mas você precisa de menos ações ou de ações mais seguras

   Use, com escopo reduzido

   Conceda scopes mínimos e exponha só os grupos de ferramentas de que o agente precisa.

3. Dados internos ou um sistema sem servidor

   Crie um servidor pequeno

   Poucas ferramentas moldadas à tarefa sobre a sua própria API, com a sua própria autenticação.

4. A tarefa envolve dois ou mais sistemas

   Crie ou adote uma camada governada

   Um único conjunto de ferramentas, regras de consentimento e histórico de auditoria para todos eles.

Criar um servidor básico é a parte fácil. Com um SDK oficial, um servidor stdio funcional com uma ferramenta é trabalho de uma tarde. O custo chega depois: OAuth para a versão HTTP, as descontinuações (a revisão 2026-07-28 tornou obsoletos Roots, Sampling e Logging, além do Dynamic Client Registration) e o trabalho contínuo de escrever descrições de ferramentas que um modelo leia corretamente. Encapsular uma API com uma ferramenta por endpoint é o erro mais comum. Cada descrição de ferramenta é um texto que o modelo precisa ler e pesar, então uma lista curta de ferramentas moldadas à tarefa ganha de toda a superfície da API.

MCP, APIs, integrações e iPaaS

O MCP não substitui APIs. Quase todo servidor MCP é um invólucro em volta de uma. A API continua sendo onde o trabalho acontece, com seus próprios limites de taxa, modelo de dados e manias. O MCP muda quem pode chamá-la: um modelo, em tempo de execução, escolhendo a chamada a partir de uma descrição, em vez de um desenvolvedor deixá-la fixa no código de antemão.

Essa distinção traça uma linha clara em relação às outras duas coisas com que ele é confundido:

• Integrações e iPaaS (as principais plataformas são comparadas aqui) movem dados por agendamento ou gatilho, de forma determinística, haja ou não alguém em um chat. Uma sincronização noturna de 40.000 pedidos para um CRM não deveria depender de um modelo decidir fazer 40.000 chamadas de ferramenta.
• O reverse ETL leva dados modelados de um data warehouse de volta para as ferramentas operacionais. O que é reverse ETL e quando ele se encaixa é um assunto à parte, e é um pipeline, não uma conversa.
• O MCP serve para os momentos em que uma pessoa ou um agente precisa perguntar, inspecionar ou agir nesses sistemas, sob demanda.

O erro acontece nas duas direções. Algumas equipes criam servidores MCP para fazer sincronização em massa e acabam com pipelines lentos, caros e impossíveis de repetir. Outras constroem integrações cuidadosas e depois entregam ao assistente de IA uma chave de API crua para consultá-las, e acabam com uma porta dos fundos sem governança.

Em uma integração compatível, o trabalho persistente e as ferramentas usadas para inspecioná-lo devem compartilhar um limite explícito de permissões. Confira o conector, as ações permitidas e os resultados registrados para esse fluxo. A documentação de integrações distingue instruções de configuração de caminhos ainda sem comprovação em produção. O MCP pode expor ferramentas aprovadas separadas; listá-las não prova que uma sincronização recorrente ou todos os controles necessários estão ativos.

Em 22 meses, o MCP saiu de seis servidores de referência para um projeto da Linux Foundation que Claude, ChatGPT, VS Code e Cursor falam. Conectar um modelo a um sistema agora é a parte barata. Decidir o que ele pode fazer lá é o trabalho.