Oi, eu sou a Lena. Algo parecia um pouco estranho na primeira vez que tentei explicar MCP para alguém.
Eu ficava dizendo "ele conecta sua IA às ferramentas" — e isso é tecnicamente verdade, mas não capturava o que realmente estava acontecendo por baixo. A pessoa com quem eu falava assentiu, depois perguntou: "então é tipo um plugin?" E eu parei. Porque também não é exatamente isso.
Essa lacuna — entre "eu sei que funciona" e "eu entendo como funciona" — é com isso que quero me sentar aqui. Não como uma análise técnica formal, mas como um passeio lento pelo que observei sobre como os servidores MCP realmente se comportam.
O problema que o MCP foi criado para resolver
Por que toda integração modelo-ferramenta costumava ser personalizada
Antes da existência do MCP, conectar um modelo de linguagem a uma ferramenta externa significava escrever uma integração personalizada toda vez. [O GitHub tinha seu próprio formato.] (https://github.com/modelcontextprotocol/modelcontextprotocol) Bancos de dados tinham o seu. Cada API era um projeto separado.
Não era que qualquer integração fosse difícil. Era a acumulação — o fato de que nenhum deles podia se comunicar, e o modelo não tinha uma forma padrão de perguntar "o que posso fazer aqui?" Cada conexão era costurada à mão.
Model Context Protocol é a resposta da Anthropic para isso. Disponibilizada de código aberto em novembro de 2024, introduziu uma linguagem compartilhada — um protocolo padronizado cliente-servidor para que qualquer aplicação de IA pudesse se conectar a qualquer provedor de ferramenta sem fiação personalizada. Em meados de 2025, a OpenAI e o Google DeepMind o adotaram. Desde então, passou a ser administrado pela Agentic AI Foundation, um projeto da Linux Foundation.
Essa mudança importa um pouco. Deixou de ser o padrão de uma empresa e passou a ser algo mais compartilhado. Ainda não tenho certeza do que isso muda na prática, mas continuo notando.
! [imagem] (https://cdn.z-image.ai/1774504615312-1.png)
Arquitetura MCP: As Três Partes Móveis
Quando as pessoas perguntam como funcionam os servidores MCP, acho que o ponto de partida mais claro é a estrutura em três partes. Cada peça tem um papel distinto, e a confusão geralmente vem de juntá-los.
MCP Host (o app de IA)
O host é o aplicativo que você realmente está usando — Cursor, Claude Desktop, VS Code com uma extensão de IA. É o que o usuário vê e com o qual interage.
O host é um corretor de segurança. Ele gerencia a janela de contexto do modelo, decide quais ferramentas estão disponíveis e controla o que é repassado de volta para o LLM. Ele não executa chamadas de ferramenta — apenas governa o acesso. A maioria dos desenvolvedores nunca escreve lógica de host a menos que esteja construindo uma plataforma de agente personalizado, mas entendê-la importa porque é o host que decide o que o modelo pode ou não alcançar.
Cliente MCP (integrado ao host)
O cliente é criado pelo host. Ele fica entre o host e cada servidor MCP, gerenciando a conexão. Normalmente há um cliente MCP por servidor MCP — cada um mantém sua própria sessão dedicada.
O cliente lida com a negociação de capacidades, roteia mensagens de um lado para o outro e abstrai os detalhes do transporte. O host não precisa saber se um servidor roda por stdio ou HTTP. Esse é o trabalho do cliente.
MCP Server (o fornecedor de ferramentas)
O servidor é onde as capacidades reais residem. Ele expõe ferramentas, recursos e prompts — seja lá o que foi construído para fornecer. Um servidor MCP do GitHub expõe operações de repositório. Um servidor Postgres expõe funções de consulta. Cada servidor normalmente foca em um domínio de integração.
O que me surpreendeu quando olhei mais de perto: um servidor é apenas um programa. Ele pode rodar localmente na mesma máquina do host, ou remotamente em algum lugar da internet. O protocolo não muda — só o transporte muda.
! [imagem] (https://cdn.z-image.ai/1774504617124-2.png)
Como uma chamada de ferramenta realmente acontece
Essa é a parte que eu ficava errando um pouco na cabeça até que fui mapeando passo a passo.
Passo 1: Servidor anuncia ferramentas disponíveis
Quando o cliente se conecta primeiro a um servidor, há um aperto de mão. O cliente envia uma solicitação initialize. O servidor responde com sua versão do protocolo e uma lista de suas capacidades — quais ferramentas oferece, seus nomes, esquemas de entrada e descrições. Isso é chamado de negociação de capacidades.
O cliente então incorpora essas definições de ferramentas no prompt do sistema do modelo. É assim que o LLM sabe o que está disponível. Não é mágica — é apenas contexto estruturado.
Passo 2: Modelo decide usar uma ferramenta
Quando o modelo está processando uma solicitação e determina que uma chamada de ferramenta é apropriada, ele emite uma chamada estruturada: o nome da ferramenta e os argumentos que deseja passar. O modelo não chama a ferramenta diretamente. Ele gera uma instrução estruturada, e o host a interpreta.
Passo 3: O cliente envia a chamada para o servidor
O cliente pega essa chamada estruturada e a encaminha para o servidor correto como uma solicitação tools/call via JSON-RPC 2.0. Este é o formato de transmissão — um dicionário com o nome do método, parâmetros e um ID único para correlação.
Passo 4: Servidor executa e retorna o resultado
O servidor executa a função real — uma consulta ao banco de dados, uma chamada de API, uma leitura de arquivo, seja para o que foi construído. Ele retorna uma resposta estruturada. Se algo der errado, ele retorna um erro tipado, não uma exceção bruta. Servidores bem construídos retornam mensagens de erro que realmente ajudam o modelo a entender o que falhou e por quê — o que é importante para a recuperação.
Passo 5: Modelo incorpora o resultado
O resultado retorna através do cliente e do host para o contexto do modelo. O modelo o lê como parte da conversa e continua a partir daí.
…ok, acho que entendi o que ele está fazendo. Cada passo é deliberadamente separado. O modelo nunca toca na ferramenta diretamente. Sempre há uma camada intermediária.
Camada de Transporte: Como Servidores e Clientes se Comunicam
stdio (local) vs. HTTP/SSE (remoto)
Transporte stdio usa fluxos de entrada e saída padrão. Quando o host inicia um servidor MCP local como um subprocesso — como executar npx my-mcp-server — o cliente e o servidor se comunicam escrevendo e lendo desses fluxos. Nenhuma rede está envolvida. Sem sobrecarga de latência. É rápido porque é apenas comunicação de processo para processo na mesma máquina.
Transporte HTTP transmissível (o padrão atual para servidores remotos, especificado na atualização do protocolo de março de 2025) usa HTTP POST para mensagens do cliente para o servidor, com eventos enviados pelo servidor opcionais para respostas contínuas. É isso que os servidores remotos usam — hospedados em plataformas como Cloudflare ou Vercel, atendendo muitos clientes simultaneamente.
Existe um formato HTTP+SSE mais antigo (da especificação de novembro de 2024) que exigia dois endpoints separados. A especificação Streamable HTTP mais recente consolidou isso em um único endpoint. Vale a pena saber se você estiver lendo documentação antiga — os padrões mudaram.
O que isso significa para latência e segurança
Servidores locais stdio são mais rápidos e têm uma superfície de ataque menor. O único processo que pode se comunicar com eles é o host. Servidores remotos introduzem latência de rede e exigem autenticação. Pesquisas em julho de 2025 descobriram que quase 2.000 servidores MCP expostos à internet não tinham autenticação — qualquer pessoa podia acessar suas listas de ferramentas. A atualização da especificação de junho de 2025 tratou de parte disso classificando servidores MCP como Servidores de Recursos OAuth, mas a implementação continua inconsistente.
Esse detalhe ficou comigo. O protocolo pode definir padrões de segurança, mas não pode aplicá-los. A documentação oficial de segurança do MCP cobre as práticas recomendadas — vale a pena ler antes de implantar qualquer coisa que lide com dados sensíveis.
A Camada que a Maioria dos Desenvolvedores Perde
O que acontece com uma chamada de ferramenta bem-sucedida
Aqui está a parte que me confundiu por um tempo: uma chamada de ferramenta bem-sucedida não persiste nada por si só.
O resultado volta para o contexto do modelo naquela sessão. O modelo o utiliza, gera uma resposta, e segue em frente. Mas o fato de a ferramenta ter sido chamada — o caminho específico que o modelo tomou, os inputs que escolheu, o resultado que obteve — isso vive apenas na janela da conversa. Quando a sessão termina, isso desaparece.
O servidor MCP não acumula conhecimento. Ele não melhora em responder com base em sessões passadas. Cada nova conexão começa do mesmo estado inicial — o handshake, a lista de capacidades, quadro limpo.
Por que conexão ≠ persistência de capacidades
É isso que quero dizer quando digo "conexão não é persistência de capacidades".
Conectar a um servidor MCP dá ao modelo acesso a uma ferramenta. Não dá ao modelo uma memória de como usou aquela ferramenta antes, ou o que funcionou, ou o que falhou. O servidor expõe as mesmas capacidades em cada sessão, independentemente do que aconteceu nas anteriores.
Continuo pensando sobre isso. Não é exatamente uma falha — é apenas um limite de design. O protocolo lida com comunicação e execução. O que acontece com o resultado dessa execução — se é armazenado, aprendido ou levado adiante — é uma camada completamente diferente.
…pode haver mais aqui. Vou continuar pensando sobre isso.
FAQ
- O que é exatamente um servidor MCP?
Um servidor MCP é um programa leve que expõe ferramentas, recursos e prompts para agentes de IA através do Model Context Protocol. Ele traduz solicitações estruturadas de modelos de linguagem em operações reais — consultas a banco de dados, chamadas de API, leitura de arquivos — e retorna os resultados em um formato padronizado. Pode ser executado localmente na mesma máquina do app de IA, ou remotamente via HTTP.
- Quais protocolos de transporte o MCP utiliza?
MCP suporta dois mecanismos de transporte. Stdio usa fluxos de entrada/saída padrão para comunicação local, na mesma máquina — rápido, sem sobrecarga de rede. HTTP Streamable (o padrão atual para servidores remotos) usa HTTP POST com Eventos Enviados pelo Servidor opcionais para streaming. Todas as mensagens utilizam JSON-RPC 2.0 como o formato subjacente, independentemente de qual transporte esteja em uso.
- Um servidor MCP pode chamar outro servidor MCP?
O protocolo permite isso. Um cliente MCP pode manter conexões simultâneas com múltiplos servidores — um para um banco de dados, outro para acesso a arquivos, um terceiro para uma API externa, todos na mesma sessão. O que é menos comum, e menos claramente definido nas implementações atuais, é um servidor atuando como cliente de outro servidor. Esse padrão existe, mas adiciona complexidade e os limites de segurança ficam mais difíceis de analisar.
O protocolo ainda está se formando. A especificação já mudou significativamente entre o lançamento de novembro de 2024, a atualização de março de 2025, e o que está em uso ativo agora. Como a arquitetura será em outra ou duas versões futuras — eu genuinamente não sei. Mas vou aprender mais sobre isso.
