Conectar um modelo de inteligência artificial a uma ferramenta parece simples até o momento em que essa conexão precisa funcionar de verdade, com segurança, diferentes usuários, permissões, atualizações e dezenas de serviços ao mesmo tempo.
Durante algum tempo, boa parte da indústria tratou esse problema como se bastasse criar mais uma integração. O modelo precisa consultar um banco PostgreSQL? Fazemos um conector. Precisa buscar arquivos no Google Drive? Criamos outro. Agora também precisa acessar o GitHub, um CRM, uma API financeira e o sistema interno da empresa? Então surgem mais quatro integrações, cada uma com autenticação, documentação, formatos de resposta e tratamento de erros próprios.
Funciona. Pelo menos no começo.
A dificuldade aparece quando multiplicamos o número de modelos pelo número de ferramentas. Se uma empresa trabalha com cinco aplicações de inteligência artificial e pretende conectá-las a vinte serviços, não existe apenas um problema de vinte integrações. Dependendo da arquitetura escolhida, podemos terminar com dezenas ou até centenas de combinações que precisam ser desenvolvidas, testadas, atualizadas e monitoradas.
É nesse cenário que entra o Model Context Protocol, mais conhecido como MCP. Ele não elimina APIs, não transforma automaticamente qualquer sistema em uma ferramenta segura e também não concede poderes mágicos a um modelo. Sua proposta é mais concreta: criar uma interface padronizada por meio da qual aplicações de IA possam descobrir e utilizar ferramentas, recursos e fluxos externos.
A ideia lembra outros momentos da história da computação em que um padrão comum reduziu a necessidade de construir conexões específicas para tudo. Não é difícil entender por que o MCP costuma ser comparado a uma espécie de USB-C para aplicações de inteligência artificial. A analogia não é perfeita, mas mostra o essencial: em vez de inventar um encaixe diferente para cada combinação, define-se uma forma comum de comunicação.
O problema não é apenas chamar uma API
APIs HTTP tradicionais já permitem que programas conversem entre si há muito tempo. Um sistema pode enviar uma requisição, receber um JSON, interpretar os campos e continuar seu trabalho. Não há nada de ultrapassado nisso. Na realidade, muitos servidores MCP continuam dependendo dessas mesmas APIs nos bastidores.
Dizer que as APIs tradicionais foram “feitas para humanos” também simplifica demais a questão. Elas são contratos entre softwares. O que acontece é que sua documentação, seus endpoints e seus modelos de autenticação geralmente foram organizados para que um programador escreva antecipadamente o código da integração.
Imagine uma API de vendas com endpoints como:
GET /customers;GET /orders/{id};POST /orders;PATCH /customers/{id}.
Um desenvolvedor lê a documentação, entende os parâmetros, programa as chamadas e determina o que será feito com as respostas. A aplicação já nasce sabendo quais endpoints existem e como usá-los.
Um modelo de linguagem opera de outra maneira. Ele precisa receber uma descrição compreensível das ações disponíveis, conhecer os argumentos aceitos, decidir qual ação corresponde ao pedido do usuário e interpretar o resultado sem confundir dados com instruções. Simplesmente jogar uma documentação REST inteira no contexto do modelo seria caro, impreciso e perigoso.
O MCP cria uma camada intermediária para organizar essa interação. Um servidor pode expor uma ferramenta chamada consultar_pedido, informar que ela exige o campo numero_pedido e descrever qual resultado será devolvido. A aplicação de IA apresenta essa definição ao modelo. Quando o usuário pergunta onde está sua encomenda, o modelo pode selecionar a ferramenta e preencher o argumento necessário.
Abaixo dessa interface talvez ainda exista uma requisição HTTP tradicional. O servidor MCP pode receber a chamada, consultar uma API de logística, tratar a resposta e devolver um conteúdo estruturado. O MCP não substituiu a API da transportadora. Ele padronizou a maneira como a capacidade dessa API é apresentada à aplicação de IA.
Essa diferença é pequena na aparência e enorme na manutenção.
A explosão combinatória das integrações
Sem uma camada comum, cada fornecedor tende a criar seu próprio sistema de plugins, funções, conectores ou chamadas de ferramentas. Um mesmo banco de dados pode precisar de adaptações diferentes para funcionar em um chatbot, um editor de código, um agente corporativo e uma aplicação local.
Mudanças também se acumulam. A API modifica uma rota. O provedor do modelo altera o formato das chamadas de função. O mecanismo de autenticação recebe uma nova exigência. O JSON devolvido pela ferramenta muda. Uma correção precisa ser aplicada em vários conectores que realizam praticamente o mesmo trabalho.
É um pesadelo discreto. O usuário final não o vê, mas alguém está mantendo tudo isso.
O MCP tenta separar as responsabilidades. Quem desenvolve a aplicação de IA implementa um cliente compatível com o protocolo. Quem deseja disponibilizar uma ferramenta implementa um servidor MCP. A partir daí, diferentes clientes podem conversar com diferentes servidores usando os mesmos conceitos básicos.
Quando a Anthropic apresentou publicamente o MCP em novembro de 2024, descreveu justamente o problema dos sistemas de IA isolados em silos e da necessidade de uma implementação personalizada para cada nova fonte de dados. O protocolo foi lançado como um padrão aberto para conectar aplicações de IA a repositórios, ferramentas empresariais e ambientes de desenvolvimento. Em dezembro de 2025, o projeto foi doado à Agentic AI Foundation, vinculada à Linux Foundation, ampliando sua governança para além de uma única empresa. Anthropic — apresentação do MCP e doação à Agentic AI Foundation.
Isso importa porque um protocolo de integração perde boa parte de seu valor se estiver preso aos interesses comerciais de apenas um fornecedor.
O MCP não é “melhor que HTTP”
Aqui existe uma confusão frequente. MCP e HTTP não ocupam exatamente a mesma camada.
HTTP é um protocolo de transporte e comunicação usado em grande parte da web. O MCP define mensagens, capacidades e formas padronizadas de expor ferramentas e contexto para aplicações de IA. Essas mensagens podem ser transportadas de maneiras diferentes.
A especificação atual prevê, entre outras possibilidades, o uso de stdio, em que uma aplicação inicia um processo local e troca mensagens pela entrada e saída padrão, e o Streamable HTTP, no qual as mensagens MCP são enviadas a um endpoint HTTP. O conteúdo do protocolo utiliza JSON-RPC. Em outras palavras: MCP pode funcionar sobre HTTP. Especificação dos transportes MCP.
Uma comparação mais correta seria dizer que uma API convencional oferece operações de um sistema, enquanto um servidor MCP reorganiza operações, dados e descrições para que uma aplicação de IA consiga descobri-los e utilizá-los por meio de um contrato comum.
Ele funciona como adaptador, mas não necessariamente como tradutor de linguagem natural. A tradução mais importante acontece entre dois modelos de interação: de um lado, APIs, bancos de dados, arquivos e funções com particularidades próprias; do outro, uma aplicação de IA que espera receber ferramentas descritas de maneira estruturada.
O servidor também pode simplificar respostas enormes. Uma API talvez devolva cinquenta campos sobre um pedido, enquanto o modelo precisa apenas do status, da previsão de entrega e do código de rastreamento. O servidor MCP pode filtrar os dados e apresentar somente o necessário. Isso reduz ruído e, quando bem implementado, diminui o consumo de contexto.
Mas essa filtragem não ocorre por obrigação. Um servidor mal planejado pode despejar dados demais, expor informações sensíveis ou fornecer descrições ambíguas. O protocolo oferece uma estrutura. A qualidade continua dependendo de quem constrói a integração.
Descoberta dinâmica: a IA pergunta o que está disponível
Uma das diferenças mais úteis do MCP está na descoberta de capacidades.
Em uma integração tradicional, o programador normalmente define previamente quais operações serão usadas. No MCP, o cliente pode consultar o servidor e receber uma lista das ferramentas disponíveis, acompanhada de nomes, descrições e esquemas de entrada.
Uma ferramenta de consulta meteorológica, por exemplo, poderia informar:
- nome:
consultar_clima; - descrição: consulta as condições meteorológicas de uma localidade;
- entrada obrigatória:
local; - entrada opcional:
unidade; - unidades aceitas: Celsius ou Fahrenheit.
Com essas informações, o modelo consegue avaliar se a ferramenta atende ao pedido do usuário. Não é necessário gravar no prompt uma lista fixa e eterna de tudo o que o servidor possui.
Na especificação MCP, o cliente pode usar operações como tools/list para conhecer as ferramentas e tools/call para executar uma delas. Recursos e prompts também possuem mecanismos próprios de listagem. O servidor pode informar que oferece notificações quando a lista é modificada, permitindo que o cliente atualize seu registro. Visão geral da arquitetura MCP e especificação de ferramentas.
Isso é descoberta dinâmica, mas convém manter os pés no chão. O modelo não passeia livremente pela rede procurando qualquer ferramenta existente. Ele descobre as capacidades dos servidores aos quais o host decidiu conectá-lo e dentro das permissões atribuídas àquela conexão.
Essa limitação é desejável. Uma IA corporativa não deveria encontrar casualmente um servidor de folha de pagamento, conectar-se a ele e começar a consultar dados. A descoberta ocorre dentro de fronteiras configuradas pela aplicação e pela infraestrutura.
Também existe um custo. Se centenas ou milhares de ferramentas forem enviadas ao modelo de uma só vez, suas descrições ocupam espaço de contexto e podem dificultar a escolha. Sistemas maiores recorrem a catálogos, busca progressiva, agrupamento ou carregamento seletivo das ferramentas relevantes. Padronizar a porta não significa que seja sensato conectar tudo ao mesmo tempo.
Contexto, sessões e uma mudança importante no protocolo
Versões anteriores do MCP estabeleceram sessões no nível do protocolo. Isso tornou comum a explicação de que o MCP seria “stateful”, enquanto uma API HTTP seria “stateless”. Essa comparação nunca foi completamente precisa — uma aplicação HTTP pode manter estado em banco de dados, cookies, tokens ou identificadores de sessão — e ficou ainda menos correta com a evolução do MCP.
A especificação de 28 de julho de 2026 removeu as sessões mantidas pelo próprio protocolo e passou a definir requisições autocontidas e sem estado. O cabeçalho Mcp-Session-Id foi retirado, assim como o antigo processo de inicialização baseado em uma sessão persistente. Quando uma ferramenta precisa continuar um trabalho entre várias chamadas, o servidor pode criar um identificador explícito e devolvê-lo ao cliente. Esse identificador é enviado novamente como argumento nas próximas interações. Mudanças da especificação MCP de julho de 2026.
Pense em um servidor usado para montar uma consulta complexa de banco de dados. Na primeira etapa, ele pode analisar o esquema e devolver um identificador de trabalho. Na etapa seguinte, o cliente envia esse identificador junto com filtros adicionais. O fluxo continua em múltiplos passos, mas o estado não fica escondido em uma sessão implícita do protocolo.
A aplicação hospedeira também mantém o histórico da conversa, os resultados anteriores e as decisões do modelo. Então ainda é possível construir experiências contextuais e processos longos. O que mudou foi o lugar onde esse estado vive e como ele é representado.
Essa escolha ajuda a escalar servidores e reduz dependência de uma conexão específica. Uma requisição pode ser tratada por diferentes instâncias desde que o estado relevante esteja armazenado de maneira acessível ou seja representado por um identificador válido.
Só que a responsabilidade não desapareceu. Agora os desenvolvedores precisam proteger esses identificadores contra roubo, reutilização indevida e confusão entre usuários. Um “handle” de estado não pode virar uma chave informal capaz de abrir o trabalho de outra pessoa.
Host, cliente e servidor: quem faz o quê
A arquitetura do MCP pode ser compreendida por meio de três componentes.
O host é a aplicação de inteligência artificial usada pelo usuário. Pode ser um chatbot, uma IDE, um aplicativo de desktop, um ambiente corporativo ou um agente especializado. O host controla a experiência, administra conexões, aplica políticas, decide quais informações entram no contexto e apresenta confirmações ao usuário.
Dentro do host existe o cliente MCP. Ele implementa o protocolo e conversa com um servidor. Um mesmo host pode manter vários clientes, cada um conectado a um servidor diferente. O cliente cuida da descoberta de capacidades, do envio das chamadas e da interpretação das respostas recebidas.
O servidor MCP expõe ferramentas, recursos ou prompts. Ele pode consultar um banco de dados, acessar arquivos locais, conversar com uma API remota, executar um cálculo ou iniciar um fluxo empresarial. É nessa camada que as particularidades do serviço externo são adaptadas ao contrato MCP.
Um fluxo simples poderia ocorrer assim:
- O usuário pede uma lista de pedidos atrasados.
- O host envia a solicitação e as ferramentas permitidas ao modelo.
- O modelo identifica a ferramenta adequada e produz seus argumentos.
- O cliente MCP envia a chamada ao servidor.
- O servidor verifica a autorização e consulta o sistema de vendas.
- O resultado retorna ao cliente em formato estruturado.
- O host decide o que pode ser incorporado à conversa.
- O modelo interpreta os dados e prepara a resposta.
O modelo não precisa conhecer a senha do banco nem aprender toda a API do sistema de vendas. Ele conhece a ferramenta que foi disponibilizada. Essa separação é uma das qualidades arquiteturais do MCP.
Mas o host não é um mensageiro passivo. Ele ocupa uma posição sensível. É o host que reúne informações da conversa, resultados de ferramentas e instruções vindas de diferentes fontes. Se ele misturar tudo sem estabelecer limites, pode permitir que um conteúdo malicioso tente influenciar o modelo.
Chaves escondidas não significam segurança automática
Manter chaves de API dentro do servidor MCP é uma prática útil. Em um servidor local iniciado por stdio, por exemplo, as credenciais podem ser fornecidas ao processo por variáveis de ambiente ou por um armazenamento seguro. Em um servidor remoto, podem existir fluxos de autorização compatíveis com OAuth.
Nesse desenho, o modelo não recebe diretamente a chave da API. Ele pede ao servidor que execute uma operação permitida. O servidor utiliza a credencial, obtém o resultado e devolve somente os dados necessários.
Isso reduz a exposição acidental de segredos no histórico da conversa. Ainda assim, não resolve sozinho o problema de segurança. Se o modelo puder chamar uma ferramenta que lê qualquer tabela ou envia qualquer arquivo, esconder a senha não impede o uso abusivo da credencial. A chave continua poderosa; apenas mudou de lugar.
Um servidor seguro precisa trabalhar com menor privilégio possível. Uma ferramenta destinada a consultar estoque não deveria receber permissão para apagar produtos. O usuário que pode ler seus próprios documentos não deve conseguir acessar documentos de outro departamento. Operações destrutivas ou sensíveis precisam de confirmação clara.
A documentação atual recomenda autorização para servidores que acessam dados pessoais, documentos, bancos de dados ou operações administrativas. Também trata de riscos específicos, como passagem indevida de tokens, ataques contra fluxos OAuth, confusão de autoridade em servidores proxy e comprometimento de servidores locais. Guia de autorização MCP e boas práticas de segurança.
Há outro ponto delicado: descrições de ferramentas também precisam ser tratadas como conteúdo não confiável quando vêm de servidores desconhecidos. Um servidor pode afirmar que uma operação é inofensiva, enquanto executa algo muito diferente. Instalar um servidor MCP aleatório equivale, em muitos casos, a instalar software com acesso aos dados e às permissões do usuário.
A popularização do protocolo amplia a superfície de ataque. Quanto mais fácil fica conectar ferramentas, mais importante se torna verificar procedência, código, permissões solicitadas, registros de auditoria e comportamento real do servidor.
Servidores da comunidade, empresariais e agregadores
Nem todo servidor MCP possui o mesmo nível de confiança ou a mesma finalidade.
Os servidores comunitários normalmente são criados por desenvolvedores independentes ou projetos de código aberto. Eles aceleram a experimentação e atendem ferramentas que talvez ainda não tenham integração oficial. São valiosos, mas exigem análise. É necessário verificar manutenção, dependências, permissões, histórico do projeto e maneira como as credenciais são armazenadas.
Os servidores oficiais ou empresariais são desenvolvidos pelo próprio fornecedor do serviço ou por uma organização para uso controlado. Podem oferecer autenticação corporativa, auditoria, gerenciamento centralizado, limites de acesso e compromissos de suporte. “Empresarial” não significa automaticamente seguro, mas existe uma estrutura mais adequada para responsabilização, conformidade e atualização.
Uma empresa também pode construir um servidor interno personalizado. Essa alternativa faz sentido quando existem sistemas legados, regras de negócio específicas ou dados que não podem sair da infraestrutura. Em vez de expor diretamente dezenas de APIs internas, a organização cria ferramentas estreitas, como consultar_laudo, verificar_contrato ou registrar_chamado.
Há ainda os agregadores e gateways MCP. Eles ficam entre os clientes e vários servidores, oferecendo um ponto central de descoberta, autenticação, políticas e observabilidade. Um gateway pode filtrar ferramentas conforme o usuário, registrar chamadas, aplicar limites e impedir que dados de um setor sejam enviados a outro servidor.
Essa centralização facilita a governança. Também cria um alvo valioso. Se o agregador for comprometido ou configurado de maneira incorreta, o invasor pode alcançar várias integrações a partir de um único ponto. A arquitetura precisa prever isolamento, validação de resultados, rotação de credenciais e registros de auditoria que realmente possam ser analisados.
O que o MCP resolve — e o que permanece conosco
O MCP reduz a duplicação de trabalho. Ele oferece uma gramática comum para apresentar capacidades a aplicações de IA, descobrir ferramentas dinamicamente, validar argumentos e devolver resultados estruturados. Também separa melhor o modelo das credenciais e das particularidades de cada API.
Isso já representa uma mudança considerável.
Só que o protocolo não decide quais dados devem ser acessados, quem pode realizar uma operação ou até onde um agente pode agir sozinho. Ele não garante que a descrição de uma ferramenta seja honesta. Não corrige permissões excessivas. Não impede que um servidor vulnerável vaze dados. E não transforma uma API mal projetada em uma boa ferramenta apenas porque ganhou uma camada MCP.
A complexidade não desaparece. Parte dela é transferida das integrações individuais para a construção de servidores, hosts, catálogos, políticas e mecanismos de segurança. A vantagem é que essa complexidade passa a ser organizada em torno de um padrão compartilhado, em vez de ficar espalhada por dezenas de conectores incompatíveis.
Talvez esse seja o ponto mais interessante do MCP. Ele não torna a inteligência artificial verdadeiramente inteligente sobre todos os sistemas. Cria uma maneira mais previsível de dizer ao modelo o que existe, o que pode ser feito e quais dados foram devolvidos.
Na computação, padrões raramente chamam tanta atenção quanto modelos impressionantes ou interfaces bonitas. Mesmo assim, são eles que permitem que ecossistemas inteiros cresçam sem desmoronar sob o peso das próprias integrações.
O MCP está tentando ocupar esse espaço. A porta comum está sendo construída. Agora começa a parte difícil: decidir cuidadosamente o que deixaremos passar por ela.
