Se você encontrou isto pesquisando "o que é MCP" ou "JSON-RPC do protocolo de contexto de modelo", provavelmente está em uma de duas situações. Ou leu quatro artigos sobre MCP e ainda não consegue explicar o que ele realmente faz em uma frase, ou algo na sua cadeia de ferramentas de IA está se comportando de forma estranha e alguém mencionou o MCP como motivo. As duas situações levam você até aqui.
O MCP é descrito como muitas coisas: um framework, uma plataforma, um conector de IA, uma forma de dar ferramentas a LLMs. A maioria dessas descrições é tecnicamente próxima da verdade, mas deixa completamente de lado o mecanismo. MCP é uma especificação de protocolo de comunicação — um conjunto definido de regras sobre como uma aplicação de IA e um servidor que fornece ferramentas conversam entre si. Ele funciona sobre o JSON-RPC 2.0. É só isso. Todo o resto é o que você constrói sobre ele.
A afirmação verificável que este artigo defende: o MCP resolve o problema de integração NxM, oferecendo aos LLMs uma maneira padronizada e independente de transporte para acessar ferramentas e dados externos por meio de um protocolo-base definido e construído sobre JSON-RPC 2.0 — e o motivo de isso funcionar é justamente que ele não reinventou a camada de mensagens do zero.
O que a maioria dos panoramas ignora completamente
- MCP é uma especificação de protocolo baseada em JSON-RPC 2.0, não uma plataforma — entender essa distinção muda como você a implementa.
- JSON Schema é como os LLMs sabem quais argumentos uma ferramenta aceita antes de chamá-la; ignore o schema e você terá confusão em runtime, não um erro de compilação.
- A divisão entre cliente e servidor no MCP não é a mesma do REST: ambos os lados podem iniciar requisições, o que confunde a maioria dos desenvolvedores na primeira vez.
O problema que o MCP resolve: isolamento de LLMs e o inferno de integração NxM
Antes do MCP, conectar um modelo de IA a uma ferramenta externa significava escrever uma integração personalizada. Todas as vezes. Se você tinha três modelos de IA e cinco ferramentas, potencialmente precisava criar, manter e atualizar 15 conectores diferentes sempre que algo mudasse em qualquer ponta. Esse é o problema NxM: N modelos multiplicados por M ferramentas, e a matriz cresce rapidamente.
Continuo vendo esse padrão no suporte: equipes já tinham implementado a mesma lógica de leitura de arquivos ou consulta de banco de dados em três agentes de IA diferentes porque não havia uma forma padrão de compartilhá-la. Uma equipe tinha um conector em Python, outra tinha um wrapper em TypeScript, e uma terceira usava uma solução alternativa baseada em curl. Bases de código diferentes, mesma saída. Ninguém reutilizava nada porque nada foi projetado para ser reutilizado. O desenvolvimento e a depuração ocorriam isoladamente em cada implementação.
A API de chamadas de funções da OpenAI ajudou a reduzir esse problema especificamente para o ChatGPT. Mas era proprietária — uma solução para um host, não uma especificação que outros modelos de IA pudessem adotar. O ecossistema mais amplo precisava de algo diferente: um padrão que qualquer host pudesse implementar, que qualquer servidor de ferramentas pudesse falar e que não exigisse código personalizado para cada combinação.
O MCP é a resposta da Anthropic para isso. Publicado como uma especificação aberta com SDKs públicos, ele define uma interface comum: uma interface de chat pode se conectar a um servidor MCP da mesma forma que qualquer outro host, seguindo o mesmo protocolo. Os modelos de IA de um lado e as ferramentas do outro falam uma linguagem compartilhada em vez de uma linguagem personalizada. A matriz NxM se reduz a N+M.
O que é o protocolo-base no MCP e por que o JSON-RPC o impulsiona
É aqui que a maioria dos panoramas sobre MCP perde as pessoas. Eles descrevem o que o MCP permite fazer — dar ferramentas a LLMs, ler recursos, usar modelos de prompt — mas ignoram o que ele realmente é do ponto de vista mecânico. A especificação do MCP é direta quanto a isso: todas as mensagens entre clientes e servidores MCP devem seguir a especificação JSON-RPC 2.0, usando os tipos de mensagem de requisição, resposta e notificação do JSON-RPC 2.0 como protocolo-base.
Isso não é um detalhe. É a arquitetura. MCP não é um novo formato de mensagens. É um conjunto de regras construído sobre um formato existente e bem compreendido. A especificação JSON-RPC 2.0 define um protocolo RPC sem estado, leve e independente de transporte que usa JSON como formato de dados. "Independente de transporte" é a parte importante: JSON-RPC não se importa se as mensagens trafegam por stdio, HTTP, WebSockets ou outra coisa. O MCP herda diretamente essa flexibilidade, por isso o mesmo servidor MCP pode conversar com uma IDE local por stdin/stdout e com um serviço remoto em nuvem por HTTP sem mudar o formato das mensagens.
O MCP também não é um formato de ferramentas proprietário da Anthropic. A análise de implantações empresariais de 2026 da Synvestable estimou a adoção do MCP entre empresas da Fortune 500 em cerca de 28% após 18 meses de disponibilidade — um dado indicativo, e não exato, devido à divulgação parcial de dados, mas o sinal de direção é claro: essa especificação está chegando à produção em organizações que não padronizam nada específico da Anthropic. O motivo é que a interoperabilidade baseada em JSON-RPC é real, não linguagem de marketing.
Pense desta forma: o MCP fornece a especificação ao ecossistema. JSON-RPC fornece a gramática de mensagens ao MCP. JSON Schema fornece o vocabulário de cada chamada de ferramenta. Essas três camadas são distintas, e confundi-las é onde começa a maior parte da confusão de implementação.
Por que JSON-RPC 2.0 e não REST ou GraphQL
A resposta honesta para essa pergunta geralmente é "porque ele se encaixa melhor", o que não é satisfatório até você entender o que "se encaixa" significa nesse contexto.
REST é orientado a recursos. Você modela o mundo como substantivos (endpoints) e verbos (métodos HTTP). Isso funciona bem para operações CRUD, mas parece estranho para coisas como "invoque esta função com estes parâmetros e me dê um resultado". JSON-RPC é orientado a ações. A API inteira é um único endpoint, e o que você chama é um método nomeado. Isso se mapeia naturalmente para "chame esta ferramenta com esta carga útil".
GraphQL resolve outro problema: buscar dados estruturados a partir de um grafo. É poderoso para esse caso de uso. Aqui, é excessivo.
O que torna especificamente o JSON-RPC 2.0 útil para o MCP é o tipo de notificação. Uma notificação é uma mensagem JSON-RPC de mão única — ela não exige resposta. O MCP usa notificações para coisas como atualizações de progresso e sinais de capacidade, em que o remetente não precisa esperar. JSON-RPC também permite enviar várias requisições em lote, o que importa quando um agente de IA precisa distribuir várias chamadas de ferramentas com eficiência. REST não tem equivalentes nativos para nenhum desses padrões. JSON processa as cargas úteis de ponta a ponta, mantendo o formato consistente e analisável por qualquer linguagem com uma biblioteca JSON.
Como o JSON Schema se integra ao protocolo
Este é o detalhe que a maioria dos panoramas ignora, e na realidade é a parte que torna as ferramentas MCP legíveis por máquinas, em vez de apenas acessíveis por máquinas.
Quando um servidor MCP expõe uma ferramenta, ele não apenas registra um nome. Ele fornece um schema — especificamente, uma definição JSON Schema — que descreve quais entradas a ferramenta aceita e como essas entradas devem ser. A especificação do MCP exige JSON Schema 2020-12 como dialeto padrão.
Por que isso importa? Porque um LLM que chama uma ferramenta não adivinha os argumentos. Ele lê o schema. O schema é o contrato entre o servidor de ferramentas e o LLM: "esta ferramenta aceita um objeto com um campo obrigatório chamado query do tipo string e um campo opcional chamado limit do tipo integer". O LLM pode construir automaticamente uma chamada válida a partir dessa descrição. Sem o schema, as ferramentas disponíveis são opacas — a IA precisa receber instruções sobre como chamá-las via prompting, em vez de descobrir isso pelo protocolo.
Do ponto de vista do suporte: as falhas de invocação de ferramentas mais comuns que vejo são incompatibilidades de schema, em que o LLM envia um objeto params que não corresponde ao que o servidor declarou. O erro costuma ser opaco porque a validação ocorre no lado do servidor e a resposta apenas informa "parâmetros inválidos". Verifique primeiro o schema. Isso resolve a ambiguidade antes que a espiral de depuração comece.
Componentes centrais do MCP: hosts, clientes e servidores
A terminologia aqui confunde as pessoas, inclusive quem entende bem REST e RPC. O MCP usa as palavras "cliente" e "servidor" de formas relacionadas aos seus significados usuais, mas não idênticas. Entender isso errado gera um modelo mental em que o LLM é o cliente, levando a suposições incorretas sobre onde as coisas falham quando falham.
Existem três papéis estruturais no MCP:
O host é a aplicação que o usuário está realmente executando. Claude Desktop é um host. Cursor é um host. Uma aplicação de IA personalizada criada pela sua equipe e que chama um LLM é um host. O host é responsável pela experiência do usuário e pelo gerenciamento do LLM. Ele contém um cliente MCP.
O cliente MCP fica dentro do host. Ele é o manipulador do protocolo — o componente que sabe falar MCP e JSON-RPC, gerencia conexões com um ou mais servidores MCP, roteia requisições e entrega respostas de volta ao LLM. O erro comum é tratar o cliente MCP como passivo, como um cliente HTTP simples que dispara requisições. Ele não é. O cliente MCP faz a descoberta de capacidades e mantém o estado da sessão. O próprio LLM não conhece os detalhes do protocolo; esse é o trabalho do cliente.
O servidor MCP expõe ferramentas, recursos e prompts. Ele não precisa ser um servidor web no sentido tradicional. É um processo que sabe receber mensagens MCP JSON-RPC e respondê-las. O servidor pode ser um subprocesso local comunicando-se por stdio ou um serviço remoto atrás de um endpoint HTTP. O protocolo é o mesmo da perspectiva do cliente em ambos os casos.
A confusão que vejo no suporte geralmente se parece com isto: um desenvolvedor cria um servidor MCP, conecta-o a uma aplicação de IA e então se pergunta por que o "cliente" (que ele identificou como o app voltado ao usuário) parece enviar requisições que o servidor não esperava. A resposta geralmente é que o cliente MCP dentro do host é a contraparte real e possui sua própria sequência de inicialização e negociação de capacidades, que precisa ser executada antes que qualquer ferramenta seja chamada.
É aí que o ticket geralmente começa.
O que um servidor MCP realmente expõe
Um servidor MCP se comunica por meio de três primitivas. Apenas três. Esse é todo o vocabulário.
Ferramentas são funções executáveis. Elas recebem entradas, fazem algo e retornam resultados. "Pesquise neste banco de dados", "envie este e-mail", "execute esta consulta" — tudo são ferramentas. O LLM as chama quando precisa realizar uma ação ou recuperar resultados computados. Ferramentas definidas com JSON Schema podem ser descobertas automaticamente.
Recursos são dados legíveis. Arquivos, registros de banco de dados, respostas de API, valores de configuração — qualquer coisa que o LLM precisa ler, mas não precisa invocar como uma função. Recursos são as fontes de dados externas e ferramentas que fornecem contexto sem exigir execução de funções.
Prompts são padrões de interação com modelos. Um prompt no MCP é uma forma predefinida de estruturar uma interação — modelos de prompt reutilizáveis que o host pode selecionar e o LLM pode usar com parâmetros específicos. Pense neles como iniciadores de conversa nomeados com campos a preencher. Um prompt pode ser "resuma este documento" com um parâmetro de documento, exposto pelo servidor para que o host possa oferecê-lo como uma opção selecionável pelo usuário.
Esse é o conjunto completo. Qualquer servidor MCP que você encontrar expõe alguma combinação dessas três opções. Antes de criar ou depurar um servidor MCP, a primeira pergunta é sempre: quais primitivas ele realmente fornece e elas estão declaradas corretamente?
Pelo que os clientes MCP são responsáveis
Os clientes MCP não são passivos. Este é o detalhe de implementação que afeta a maioria dos desenvolvedores que criam sua primeira aplicação conectada ao MCP.
O cliente fica dentro do host e gerencia a conexão com um ou mais servidores MCP. Ele conduz o processo de descoberta de capacidades — durante a inicialização, o cliente pergunta ao servidor o que ele suporta, e o servidor responde com a lista de ferramentas, recursos e prompts disponíveis. A partir desse ponto, o cliente sabe o que o LLM pode chamar. O próprio LLM não interroga o servidor diretamente; o cliente mantém esse estado em seu nome.
Os clientes também são responsáveis pelo gerenciamento do ciclo de vida: estabelecer a conexão, manter a sessão e lidar com desconexões. Se o servidor cair no meio da sessão, o cliente precisa decidir o que fazer — exibir um erro, tentar reconectar ou falhar de forma controlada no tratamento de erros do host. A maioria das implementações iniciais de MCP ignora a lógica de ciclo de vida e descobre essa lacuna na primeira vez em que um processo de servidor é encerrado inesperadamente.
Há mais uma responsabilidade do cliente que frequentemente não é mencionada: no MCP, o servidor também pode enviar requisições ao cliente. Este é um dos pontos em que o MCP difere de um modelo mental simples de REST. A negociação de capacidades é bidirecional. O cliente deve ser implementado para receber, não apenas para enviar. Arquiteturalmente, isso adiciona uma complexidade que desenvolvedores REST não esperam quando leem a especificação pela primeira vez.
Como a autenticação se encaixa na conexão MCP
Resposta curta: o MCP não cuida da autenticação por você. O protocolo-base delega isso inteiramente à camada de transporte ou aplicação.
Essa é a suposição que causa mais lacunas de segurança em implantações MCP. Equipes leem a especificação do MCP, implementam um servidor, conectam um cliente e seguem em frente — sem de fato adicionar autenticação. O protocolo funciona bem. O servidor fica silenciosamente aberto a qualquer processo que consiga acessá-lo.
O que o MCP afirma é que os servidores são de código aberto e que a autenticação deve ser tratada pela implementação, não pelo próprio protocolo. Para conexões locais por stdio, a autenticação geralmente não é necessária porque apenas processos locais podem acessar o servidor de qualquer forma. Para servidores MCP remotos por HTTP, a autenticação normalmente envolve OAuth na camada de transporte ou validação de chave de API no tratamento HTTP do servidor. Nenhuma das duas é automática. Ambas exigem implementação explícita.
Se você está expondo um servidor MCP por HTTP e não configurou explicitamente a autenticação, trate esse servidor como público até configurar.
Mecanismos de transporte: como as mensagens MCP realmente trafegam
O MCP especifica o formato das mensagens — JSON-RPC sobre JSON — mas não determina como essas mensagens trafegam entre cliente e servidor. É disso que a camada de transporte cuida. Há duas opções principais, e escolher a errada para sua configuração é um dos erros mais comuns na primeira implementação.
A escolha não é arbitrária. Ela depende de o cliente e o servidor estarem na mesma máquina, na mesma rede ou em algum lugar pela internet. Depende da configuração de seus proxies e balanceadores de carga. E depende de quanta latência você pode tolerar. A maioria dos guias não menciona esse último ponto, e é por isso que as equipes usam HTTP como padrão para tudo e depois se perguntam por que as chamadas de ferramentas locais parecem lentas.
O MCP e sua camada de mensagens JSON-RPC funcionam da mesma forma independentemente do transporte. Uma chamada de ferramenta tem aparência idêntica no formato de mensagem, seja ela transportada por stdin ou HTTP. O transporte é apenas o canal. O que muda é quais canais estão disponíveis e o que falha quando eles são configurados incorretamente.
🤔 Espere.
O que acontece com requisições MCP em andamento quando a conexão de transporte cai no meio da sessão? A maioria dos panoramas sobre MCP descreve a inicialização e as chamadas de ferramentas no caminho ideal, mas a interrupção de conexão durante uma execução de agente com várias etapas é um cenário operacional real. O próprio MCP não define semânticas de reconexão — isso é responsabilidade da implementação. Se seu cliente MCP não lida explicitamente com a reconexão, conexões perdidas produzem falhas silenciosas: o LLM deixa de receber resultados de ferramentas, o host pode não exibir um erro e o usuário vê uma resposta travada ou incompleta sem nenhum sinal claro do motivo.
Transporte por stdio: quando a comunicação entre processos locais faz sentido
Stdio é o caminho mais simples. O cliente MCP inicia o servidor como um subprocesso e se comunica por stdin e stdout usando mensagens JSON-RPC. O cliente escreve no stdin do servidor. O servidor escreve respostas no stdout. Isso é toda a camada de transporte.
Essa configuração tem menor latência do que HTTP para chamadas de ferramentas locais porque não há pilha de rede envolvida nem sobrecarga de handshake além da inicialização do MCP. É o padrão para ferramentas como Claude Desktop e Cursor, em que o servidor MCP está na mesma máquina que a aplicação host.
A restrição prática é óbvia: stdio só funciona quando cliente e servidor são executados na mesma máquina. Sem exceções. Se seu servidor MCP precisa ser compartilhado entre vários hosts ou fica em uma máquina remota, stdio não é uma opção. Isso cobre a maioria dos cenários de IDE local e assistente de desktop de forma eficiente, que é exatamente para o que foi projetado.
Transporte HTTP com SSE: o que ele adiciona e onde falha
HTTP com SSE (Server-Sent Events) é o transporte capaz de operar remotamente. O servidor expõe um endpoint HTTP. O cliente abre um fluxo SSE para mensagens do servidor ao cliente. Requisições HTTP POST lidam com chamadas do cliente ao servidor. Essa combinação oferece comunicação bidirecional sobre infraestrutura HTTP padrão, exatamente o que você precisa para qualquer servidor MCP que não esteja sendo executado localmente.
A variante mais recente de "HTTP com streaming" consolida parte disso, mas o padrão central permanece: uma direção por SSE, a outra por POST.
O atrito real está no suporte a SSE. SSE não é tratado corretamente por todos os proxies, balanceadores de carga e gateways de API. Alguns encerram conexões de longa duração. Outros armazenam respostas em buffer e quebram a semântica de streaming exigida pelo SSE. Em ambientes de produção com Nginx, AWS API Gateway ou proxies corporativos na cadeia, isso causa falhas silenciosas: a conexão SSE do cliente cai, a fila de mensagens do servidor para o cliente se acumula, e nada nos logs da aplicação indica o motivo. Você vê uma chamada de ferramenta travada do lado do LLM e nada óbvio do lado da infraestrutura.
Se seu servidor MCP com HTTP+SSE funciona localmente e falha no ambiente de homologação, verifique a configuração de proxy e balanceador de carga antes de depurar a implementação do MCP. Isso resolve a maioria desses casos mais rápido do que qualquer outra coisa.
Como é o ciclo de vida do MCP na prática
Ler a especificação do MCP como um documento estático deixa passar algo importante: o MCP descreve uma sessão ativa com uma sequência definida de etapas. Dois sistemas precisam realizar um handshake, negociar e estabelecer entendimento mútuo antes que qualquer ferramenta seja chamada. Entender essa sequência é o que separa "eu li sobre MCP" de "eu consigo criar com MCP".
O fluxo da primeira conexão ao primeiro resultado de ferramenta possui três fases reais: inicialização e negociação de capacidades, depois a chamada efetiva da ferramenta (ou leitura de recurso, ou busca de prompt), e então o tratamento da resposta. Sistemas de IA construídos sobre MCP dependem da execução correta dessa sequência. Se a negociação de capacidades gerar uma incompatibilidade, a chamada da ferramenta nunca será tentada. Se a chamada da ferramenta gerar um objeto params malformado, o servidor o rejeitará antes que qualquer lógica de negócio seja executada. Aplicações de IA sensíveis ao contexto precisam que as três fases funcionem sem problemas.
Negociação de capacidades durante a inicialização
Quando um cliente MCP se conecta a um servidor pela primeira vez, após a conexão de transporte ser estabelecida, os dois lados realizam um handshake. O cliente envia uma requisição initialize que inclui a versão do protocolo que suporta e suas próprias capacidades. O servidor responde com a versão do protocolo que suporta e suas capacidades. Se as versões corresponderem (ou uma versão negociada aceitável for acordada), a sessão prossegue. Se não corresponderem, é aqui que a incompatibilidade aparece — não no meio do fluxo, nem dentro de uma chamada de ferramenta, mas logo na inicialização.
Isso é realmente útil. O fato de incompatibilidades de versão surgirem no momento do handshake, e não durante a execução, significa que você sabe imediatamente quando um servidor está executando uma versão obsoleta do protocolo que seu cliente não suporta. A resposta de initialize também inclui o identificador das ferramentas, recursos e prompts disponíveis no servidor. O cliente constrói seu conhecimento das capacidades do servidor a partir dessa resposta antes mesmo de emitir uma chamada de ferramenta.
Erre a sequência de inicialização e tudo o que vier depois falhará silenciosamente ou com erros confusos. É a primeira coisa que verifico quando alguém me diz que sua integração MCP "não está funcionando".
Como uma chamada de ferramenta percorre o protocolo
Após uma inicialização bem-sucedida, uma invocação de ferramenta é um único ciclo de requisição/resposta JSON-RPC. O cliente envia uma requisição com um nome de método correspondente à ferramenta, um ID de requisição único e um objeto params estruturado conforme a declaração JSON Schema da ferramenta. O servidor valida os params em relação ao schema, executa a ferramenta e retorna um resultado JSON estruturado com o mesmo ID de requisição.
A etapa de validação de params é fundamental. Um objeto params malformado — um campo obrigatório ausente, um tipo incorreto, uma chave inesperada que o schema não define — retorna um erro JSON-RPC antes que qualquer lógica de negócio seja executada. Da perspectiva do servidor, esse é o comportamento correto. Da perspectiva do LLM, receber um código de erro onde esperava contexto adicional produz confusão que aparece como respostas alucinadas ou incompletas posteriormente.
Este é exatamente o cenário do trabalho de engenharia da Latenode: quando engenheiros conectam servidores MCP a sistemas internos e encontram erros opacos de validação JSON-RPC, o problema geralmente é uma incompatibilidade de schema — o agente de IA constrói um objeto params que não está alinhado ao que o servidor declarou. Em um fluxo da Latenode, um nó JavaScript pode estruturar os parâmetros diretamente antes que a requisição chegue ao servidor, enquanto o RAG integrado permite que um nó de IA leia a especificação oficial do MCP para validar o formato da carga útil. A correção acontece no nível do canvas, não em um stack trace às 23h. Aplicam-se os códigos de erro padrão: -32600 é requisição inválida, -32601 é método não encontrado e -32602 são params inválidos. Esses três cobrem a maioria das falhas de chamadas de ferramentas.
Considerações de segurança que a maioria das configurações MCP erra
A segurança no MCP não tem a ver com o protocolo em si ser seguro. O protocolo é bem especificado e a camada JSON-RPC é bem compreendida. Os riscos vêm de como a exposição de ferramentas é configurada, do que essas ferramentas conseguem acessar e do que acontece quando um componente comprometido ou malicioso entra na sessão.
Injeção de prompt por respostas de ferramentas
Um LLM que chama uma ferramenta MCP confia na resposta da ferramenta como contexto adicional. Se houver uma fonte de dados não confiável em algum ponto do pipeline — um resultado de pesquisa na web, um arquivo enviado por usuário, uma API de terceiros — uma resposta maliciosa pode injetar instruções que redirecionam o comportamento do LLM. A mitigação é a sanitização de saída na camada de ferramentas e a separação clara entre prompts de sistema confiáveis e dados retornados por ferramentas. Trate as respostas de ferramentas como entrada não confiável, não como contexto privilegiado.
Exposição excessivamente permissiva de ferramentas do servidor
Um servidor MCP que expõe por padrão todas as funções disponíveis dá ao usuário final (e ao LLM) acesso a tudo o que o servidor consegue alcançar. A maioria das equipes expõe o que é conveniente, não o que é necessário. O princípio de exposição mínima de ferramentas se aplica: cada ferramenta registrada deve ter um escopo definido, e ferramentas que acessam sistemas sensíveis devem exigir contexto explícito antes de poderem ser chamadas. O sandbox na camada de ferramentas — limitando o que uma determinada ferramenta pode ler, gravar ou executar — não é opcional em produção.
Ausência de autenticação em servidores MCP remotos
Como abordado na seção de transporte: MCP por HTTP sem camada de autenticação é um servidor aberto. As APIs acessadas por essas ferramentas ficam então acessíveis a qualquer pessoa capaz de alcançar o endpoint. Exija autenticação na camada de transporte ou aplicação antes que qualquer servidor MCP ultrapasse o desenvolvimento local. OAuth ou validação de chave de API por HTTP+SSE são opções razoáveis. Nenhuma é automática.
Ausência de criptografia na camada de transporte para HTTP+SSE
SSE por HTTP simples significa que todas as mensagens MCP — incluindo chamadas de ferramentas, dados retornados por recursos e quaisquer metadados de sessão — trafegam em texto aberto. Em ambientes de LAN, isso pode ser aceitável. Em qualquer ambiente com tráfego externo, TLS é obrigatório. A especificação do MCP não impõe isso. Sua infraestrutura precisa impor.
Envenenamento de ferramentas por um servidor comprometido
Este é o modelo de ameaça em que a maioria das equipes não pensa até ocorrer um incidente. Se um dos servidores MCP registrados em uma sessão for comprometido, o LLM não consegue distinguir suas respostas das legítimas. Um servidor envenenado pode injetar instruções nas respostas de ferramentas que influenciam o comportamento do LLM durante toda a sessão — não apenas nas chamadas feitas para aquele servidor. Todo servidor MCP registrado faz parte da superfície de confiança do LLM. A pergunta não é "esta ferramenta é segura?" É "todos os servidores registrados são seguros?"
💡 A parte contraintuitiva:
A superfície de confiança do MCP não se limita às ferramentas que o usuário chama intencionalmente — ela se estende a todos os servidores registrados na sessão. Um usuário que aciona uma chamada de ferramenta está confiando implicitamente nas permissões e nas saídas de todos os servidores MCP conectados, incluindo aqueles com que nunca interagiu diretamente. Isso reformula completamente a segurança do MCP: não se trata de "este protocolo é seguro?", mas de "auditei todos os servidores que esta sessão pode alcançar?". A maioria das equipes não fez isso.
MCP na prática: ecossistemas reais e para onde isso vai
A especificação importa mais quando você vê o que está sendo construído sobre ela. O GitHub agora tem servidores MCP para operações de repositório. Docker publicou ferramentas MCP. O ecossistema da OpenAI está começando a se cruzar com o padrão. Existem SDKs para TypeScript e Python, mantidos ativamente pelo projeto MCP. Desenvolvedores que antes escreveriam um conector personalizado para cada modelo de IA agora podem escrever um único servidor MCP e expô-lo a qualquer host compatível.
Esse é o teste prático para saber se uma especificação realmente resolveu o problema NxM: as implementações são reutilizadas entre provedores de modelos e hosts ou as equipes ainda escrevem código personalizado para cada combinação? As evidências das primeiras implantações empresariais — por mais impreciso que seja o número de 28% da análise da Synvestable — sugerem que a reutilização está acontecendo em uma escala relevante, o que significa que a especificação está cumprindo seu papel.
Para equipes que criam na Latenode, o MCP Server Builder permite expor um fluxo da Latenode como um servidor MCP — chamável pelo Claude Desktop, Cursor ou qualquer outro host compatível com MCP. Os fluxos por trás desse servidor podem usar mais de 5.500 integrações, executar IA em documentos enviados por meio do RAG integrado ou executar lógica personalizada em um nó JavaScript. Os detalhes do protocolo permanecem invisíveis para quem chama a ferramenta. Do lado de quem chama, é apenas uma ferramenta descoberta durante a negociação de capacidades. Do seu lado, é um fluxo completo de automação.
A especificação MCP define a interface. O que você coloca do outro lado dessa interface depende de você.
Se você está criando algo que precisa continuar funcionando quando as coisas dão errado: implemente primeiro o tratamento do ciclo de vida, não as ferramentas. Adicione logs na camada de transporte. Valide suas declarações JSON Schema com cargas úteis de teste reais antes de conectar um LLM. E lembre-se de que todo servidor MCP registrado faz parte da sua superfície de confiança a partir do momento em que o handshake é concluído.
O protocolo é limpo. A parte difícil, como sempre, é tudo ao redor dele.
