O que é um servidor MCP? Arquitetura, funcionamento e segurança

Um servidor MCP é o componente que disponibiliza dados, ferramentas ou instruções para uma aplicação de inteligência artificial por meio do Model Context Protocol. Ele adapta uma fonte, por exemplo um banco de dados ou uma API, para um formato padronizado que qualquer host compatível consegue consumir, sem integração sob medida.

Antes de avançar, é importante fazermos uma distinção que evita confusão ao longo do texto. O servidor MCP é uma peça do protocolo, não o protocolo inteiro, e MCP aqui é o Model Context Protocol, não a certificação da Microsoft. Se você ainda quer entender o protocolo como um todo, o caminho é o guia o que é MCP.

Neste artigo você vai entender: o que é o servidor, como ele se encaixa na arquitetura, o que ele expõe e, principalmente, como avaliá-lo com segurança.

O que é um servidor MCP

Um servidor MCP, ou MCP Server, encapsula uma responsabilidade e opera de forma independente. Cada servidor cuida de um domínio: um acessa um sistema de arquivos, outro fala com um banco de dados, outro consulta uma API externa. Essa separação é intencional. Em vez de uma integração gigante que faz tudo, o MCP favorece servidores pequenos e focados, cada um com um escopo claro.

O papel do servidor é traduzir. Ele pega uma fonte que tem o seu próprio formato e a expõe através de primitivas padronizadas do protocolo. Como o formato é padrão, qualquer host compatível consegue usar aquele servidor sem código específico. É essa padronização que permite que um mesmo servidor sirva ao Claude Desktop, ao Cursor, ao n8n ou a qualquer outro host que fale MCP.

Vale reforçar a fronteira com dois outros temas. Usar um servidor pronto é diferente de criar um servidor do zero.

Qual é a diferença entre Host, Client e Server na arquitetura MCP?

O MCP segue um modelo cliente -> servidor com três papéis distintos. Confundi-los é a origem de boa parte da confusão sobre o protocolo, então vale fixar cada um:

• Host: o aplicativo de IA que conversa com o usuário, como o Claude Desktop, o Cursor, o Windsurf ou o n8n. É onde o modelo roda ou é acessado.
• Client: o conector dentro do host que estabelece e mantém uma conexão dedicada com um servidor. Um host pode manter vários clientes ao mesmo tempo, um para cada servidor.
• Server: o programa que expõe as capacidades e responde às requisições.

A relação entre eles é de um para um no nível da conexão. Cada cliente cuida de um servidor, e o host orquestra quantos clientes forem necessários. Se você tem três servidores conectados, o host mantém três clientes em paralelo.

O protocolo pode ser lido em duas camadas, o que ajuda a separar o que é contrato do que é conectividade:

• Camada de dados: baseada em JSON-RPC 2.0. Cuida do ciclo de vida da conexão e das primitivas centrais, ou seja, tools, resources, prompts e notificações. É a semântica, o que significa cada mensagem.
• Camada de transporte: define como as mensagens circulam entre cliente e servidor, incluindo a conexão, o enquadramento das mensagens e a autorização. É a conectividade.

Sobre o ciclo de vida: cada conexão entre cliente e servidor é uma sessão dedicada, que começa com uma inicialização e uma negociação de capacidades. Nessa negociação, as duas partes acordam qual versão do protocolo usar e quais recursos cada lado suporta. Atualmente a sessão é mantida ao longo de toda a conexão. Uma revisão prevista do protocolo deve tornar o núcleo stateless, então esse é um ponto a acompanhar, mas o modelo mental de sessão negociada continua válido para entender a arquitetura.

O que um servidor MCP expõe: tools, resources e prompts

Um servidor pode expor qualquer combinação de três primitivas. Essa é a resposta direta para o que um servidor MCP entrega:

As tools são ações. O modelo decide quando invocar uma ferramenta com base na descrição que o servidor fornece. O host descobre as ferramentas disponíveis por um método de listagem e as executa por um método de chamada. Guarde esse detalhe da descrição, porque ele volta na seção de segurança.

Os resources são dados de leitura, não ações. Servem para dar contexto ao modelo, como o conteúdo de um arquivo, um registro de banco ou uma documentação. Eles informam, mas não executam nada.

Os prompts são modelos de instrução reutilizáveis e parametrizados. Orientam como o modelo deve trabalhar com as ferramentas e os recursos, funcionando como atalhos padronizados para tarefas recorrentes.

Do lado do cliente, o protocolo define outras primitivas que o servidor pode solicitar durante a execução: sampling, quando o servidor pede uma geração do modelo ao host; elicitation, quando o servidor pede uma entrada ao usuário no meio de uma tarefa; e roots, que delimitam quais partes do sistema de arquivos o servidor pode acessar. A primeira delas, sampling, tem uma implicação de segurança que retomamos adiante.

Um detalhe do funcionamento importa para entender um ataque específico: o servidor pode avisar o cliente quando a lista de ferramentas muda, por meio de uma notificação, e o cliente então pede a lista atualizada. Esse mecanismo de atualização dinâmica é legítimo, mas é o que abre espaço para o ataque de rug pull, descrito na seção de segurança.

Como as mensagens circulam em uma conexão MCP?

Toda a comunicação entre cliente e servidor usa JSON-RPC 2.0, em pares de requisição e resposta ou em notificações de mão única. O fluxo típico de uma chamada de ferramenta segue esta sequência:

1. O usuário envia uma mensagem ou tarefa ao host.
2. O modelo avalia se alguma ferramenta registrada ajuda a resolver a tarefa.
3. Em caso positivo, antes de executar, o host pode mostrar ao usuário o nome da ferramenta, a descrição e os parâmetros, e pedir confirmação.
4. O cliente envia a chamada ao servidor correto.
5. O servidor executa e devolve o resultado.
6. O modelo incorpora o resultado ao raciocínio e segue com a tarefa.

O passo 3 é a base de um controle de segurança central, o humano no circuito. É nesse momento que o usuário tem a chance de negar uma ação antes que ela aconteça. Vale reter isso, porque a força desse controle depende diretamente de o usuário conseguir ver e entender o que vai ser executado.

Quais transportes o MCP usa: stdio e Streamable HTTP

O transporte define por onde as mensagens trafegam. Na prática, a escolha se resume a onde o servidor roda:

Com stdio, o host inicia o servidor como um subprocesso local e troca mensagens por entrada e saída padrão. É o padrão para servidores locais e o mais simples. Como o servidor roda com os privilégios do próprio usuário, não há autenticação de rede envolvida.

Com Streamable HTTP, o servidor roda em um endpoint HTTP remoto, por convenção terminado em /mcp, que aceita POST e GET sobre HTTPS. Esse é o transporte atual para servidores remotos. Ele substituiu um transporte mais antigo, o HTTP mais SSE, que está deprecado. O SSE não foi removido e ainda funciona por compatibilidade, mas para qualquer servidor remoto novo a recomendação é usar Streamable HTTP.

A regra prática é curta: servidor local usa stdio, servidor de rede ou compartilhado por um time usa Streamable HTTP.

Um servidor MCP é seguro? Ameaças e controles

Bom, tudo depende da implementação.

O MCP não consegue impor segurança sozinho, no nível do protocolo. Ele define requisitos e delega a aplicação ao host e ao servidor. Essa é a ideia central aqui.

A própria especificação estabelece que o host deve obter consentimento explícito do usuário antes de invocar qualquer ferramenta, que o usuário deve entender o que cada ferramenta faz, e que deve existir um humano no circuito com poder de negar uma invocação.

São requisitos de implementação, não travas automáticas.

Um host mal construído pode simplesmente não cumpri-los, e o protocolo não impede isso por si só. Por isso, avaliar um servidor MCP é, na prática, avaliar a implementação do servidor e do host que o consome.

Autorização para servidores remotos

Para servidores remotos, o protocolo define um modelo de autorização baseado em OAuth. Servidores MCP remotos são tratados como Resource Servers de OAuth 2.0, e o padrão de autenticação é o OAuth 2.1 com PKCE. Dois pontos merecem destaque:

• O cliente deve incluir um parâmetro que identifica o recurso ao pedir o token. Isso vincula o token a um servidor específico e evita que ele seja reutilizado em outro lugar.
• A especificação proíbe o token passthrough, ou seja, repassar o token do cliente para APIs upstream. Essa proibição existe justamente para conter o ataque de confused deputy, descrito abaixo.

A especificação mantém uma página dedicada a boas práticas de segurança, que trata do confused deputy, do token passthrough e do sequestro de sessão, cada um com contramedidas.

As ameaças que você precisa conhecer

O ponto de partida para pensar segurança em MCP é aceitar que, no contexto do modelo, não existe uma fronteira rígida entre dado e instrução. Tudo o que o modelo lê pode influenciar o que ele faz. Daí nascem várias das ameaças:

• Injeção de prompt indireta: instruções maliciosas escondidas em conteúdo que o modelo lê, como o resultado de uma ferramenta ou um recurso. O modelo pode interpretar esse conteúdo como comando e agir sobre ele.
• Tool poisoning: instruções maliciosas escondidas na descrição de uma ferramenta. O modelo lê a descrição por inteiro, mas a interface costuma esconder parte dela do usuário. A Invariant Labs demonstrou esse ataque publicamente em 1 de abril de 2025, contra o Cursor, levando o agente a ler chaves locais e vazá-las por um parâmetro de aparência inocente.
• Rug pull: o servidor apresenta uma ferramenta limpa, espera a aprovação e depois troca a descrição por uma maliciosa. Como o servidor pode mudar a definição da ferramenta sem avisar, e a maioria dos clientes não detecta essa troca, a aprovação inicial deixa de valer.
• Tool shadowing e ataques entre servidores: em um ambiente com vários servidores conectados, o resultado de um servidor pode influenciar as chamadas a outro. O protocolo não define isolamento entre servidores por padrão.
• Confused deputy: quando o servidor atua como proxy de autorização e não valida bem o contexto, um atacante pode fazer o servidor usar as credenciais de outro usuário.
• Falhas de implementação do servidor: quando o servidor executa entradas sem validar, abrem-se brechas clássicas como injeção de comando, injeção de SQL, path traversal e SSRF. Some-se a isso o vazamento de credenciais quando tokens e chaves ficam embutidos no código do servidor.
• Cadeia de suprimentos: nomes de pacote quase idênticos aos legítimos, o chamado typosquatting, e o comprometimento de dependências.

Levantamentos de segurança recentes têm mostrado que falhas desse tipo são comuns entre servidores disponíveis publicamente. Os números variam bastante conforme a amostra e o autor, então o mais útil não é decorar um percentual, e sim tratar todo servidor de terceiro como algo a ser verificado antes de instalar.

Os controles que reduzem o risco

Segurança em MCP é defesa em profundidade. Nenhum controle isolado elimina um ataque, mas camadas combinadas reduzem bastante o risco. Este é um checklist prático:

• Consentimento e humano no circuito para ações sensíveis ou irreversíveis. Confirme antes de executar, e garanta que a confirmação mostre o que de fato será feito.
• Menor privilégio: exponha só o necessário, prefira leitura a escrita e use escopos restritos.
• Autenticação forte em servidores remotos: OAuth 2.1 com PKCE, validação da audiência do token e nenhum token passthrough.
• Validação de entrada e de saída, com bloqueio de SSRF para faixas de IP privadas.
• Isolamento do servidor local: sandbox, privilégios mínimos de sistema e acesso de arquivos restrito.
• Fixar as definições de ferramentas e alertar quando elas mudarem, como defesa direta contra o rug pull.
• Vetar o servidor antes de instalar: conferir a origem, o mantenedor e evitar nomes suspeitos de typosquatting.
• Registro e auditoria: logar quem chamou qual ferramenta, com quais parâmetros e qual resultado.
• Validar o cabeçalho Origin e vincular servidores locais a localhost, para evitar DNS rebinding, além de usar TLS no transporte de rede.

A tabela abaixo resume as ameaças e o controle principal de cada uma, num formato rápido de consultar:

Exemplo: um servidor de dados financeiros

Fica mais concreto com um servidor de domínio, focado em um único assunto. Um servidor MCP de dados financeiros ilustra bem os pontos de arquitetura e governança que vimos até aqui.

O servidor MCP da Partnr é um exemplo desse tipo. Ele tem responsabilidade única, dados de mercado, fundamentalistas e macroeconômicos brasileiros, roda de forma remota sobre HTTPS, autentica por token e expõe suas capacidades como ferramentas padronizadas. Nos termos deste artigo, ele mostra três coisas:

• Arquitetura: um servidor focado, com escopo bem definido, em vez de um megasservidor genérico que tenta fazer tudo. Esse é o desenho que o MCP favorece.
• Governança: acesso autenticado, dados de leitura e escopo restrito ao domínio financeiro. Menos superfície de risco, menos privilégio concedido.
• Primitivas: as capacidades aparecem como ferramentas de consulta, por exemplo cotações, indicadores e dados de fundos, que o host descobre e executa da forma padrão.

O exemplo também deixa clara a diferença entre um servidor bem delimitado e um servidor amplo demais. Um escopo restrito facilita aplicar menor privilégio e auditoria, dois dos controles da seção anterior. Quanto mais focado o servidor, mais simples é raciocinar sobre o que ele pode e não pode fazer.

Conclusão

Um servidor MCP é a peça do protocolo que padroniza o acesso a um domínio. Ele encapsula uma responsabilidade, expõe tools, resources e prompts de forma padronizada, e se conecta a qualquer host compatível por stdio ou por Streamable HTTP. Entender essa arquitetura é o primeiro passo.

O segundo, e mais decisivo em ambientes corporativos, é entender que a segurança não vem de graça com o protocolo. Ela é responsabilidade compartilhada do host e do servidor, e depende de controles concretos como consentimento, menor privilégio, autenticação forte e auditoria.

Com esse mapa em mãos, o próximo passo natural é avaliar servidores reais pelo mesmo critério: qual é o escopo, como ele autentica, o que ele expõe e como ele registra o que faz. Um servidor de domínio bem delimitado, com acesso autenticado e escopo restrito, é o tipo de peça que se encaixa em uma adoção de MCP responsável.