O que é MCP e por que ele pode se tornar um padrão importante para inteligência artificial
Um modelo de inteligência artificial pode ser extremamente inteligente e ainda assim ter um problema enorme:
ele não conhece automaticamente os sistemas, dados e ferramentas que fazem parte do seu trabalho.
Imagine pedir para uma IA:
“Veja quais leads entraram hoje no CRM, identifique os três mais promissores, consulte o histórico comercial e crie tarefas para os vendedores responsáveis.”
Para responder de verdade, a IA precisa conseguir conversar com:
o CRM;
o banco de dados;
o sistema de tarefas;
as regras de acesso da empresa.
Durante muito tempo, cada uma dessas conexões precisava ser construída de maneira específica.
Uma integração para o CRM.
Outra para o banco.
Outra para GitHub.
Outra para Slack.
Outra para Google Drive.
E se a empresa quisesse trocar Claude por ChatGPT ou utilizar outro agente, parte desse trabalho poderia precisar ser refeita.
É justamente esse problema que o MCP — Model Context Protocol tenta resolver.
MCP é um protocolo aberto criado para padronizar a forma como aplicações de inteligência artificial se conectam a ferramentas, dados e serviços externos.
Em vez de cada aplicativo de IA inventar sua própria forma de conversar com cada sistema, ambos podem falar uma linguagem comum.
É por isso que você provavelmente ouvirá cada vez mais frases como:
“Essa ferramenta possui servidor MCP?”
“Conecte o MCP no agente.”
“Crie um MCP para nosso sistema.”
“Disponibilize nossa API via MCP.”
Mas o que isso realmente significa?
E por que empresas como OpenAI, Google, Microsoft e Anthropic estão adotando um protocolo que nasceu há menos de dois anos?
Vamos por partes.
O que é MCP?
MCP significa Model Context Protocol, ou Protocolo de Contexto de Modelo.
É um padrão aberto que define como aplicações de inteligência artificial podem descobrir e utilizar dados, ferramentas e funcionalidades disponibilizados por sistemas externos.
A primeira versão pública foi apresentada pela Anthropic em 25 de novembro de 2024.
Na época, a empresa descreveu o problema de forma simples: modelos estavam ficando cada vez mais capazes, mas continuavam isolados de informações presentes em repositórios, ferramentas empresariais e outros sistemas. Cada nova fonte exigia uma integração personalizada. O MCP foi criado para substituir parte dessa fragmentação por uma interface comum.
Em uma frase:
MCP é uma linguagem padronizada para conectar aplicações de IA ao mundo externo.
Uma analogia simples: MCP pode ser o “USB-C da inteligência artificial”
Essa analogia ficou extremamente popular.
Antes do USB-C, dispositivos diferentes utilizavam uma infinidade de conectores.
Um cabo para câmera.
Outro para celular.
Outro para monitor.
Outro para armazenamento.
USB-C não elimina aquilo que existe dentro dos aparelhos.
Ele simplesmente cria uma interface comum através da qual diferentes dispositivos conseguem se conectar.
MCP tenta fazer algo parecido na inteligência artificial.
Sem MCP:
Com uma camada padronizada:
É uma simplificação, mas mostra o objetivo.
O sistema expõe capacidades em MCP, e clientes compatíveis conseguem entendê-las através do mesmo protocolo.
MCP não é um modelo de inteligência artificial
Esse é o primeiro erro que precisamos eliminar.
MCP não é:
um LLM;
um concorrente do ChatGPT;
um novo Claude;
uma IA;
um banco de dados;
uma API específica.
Ele é um protocolo de comunicação.
Um modelo continua responsável por interpretar linguagem, raciocinar e decidir o que fazer.
MCP organiza uma das maneiras pelas quais aquela aplicação consegue acessar capacidades externas.
Quem criou o MCP?
O protocolo nasceu dentro da Anthropic, empresa responsável pelo Claude, e foi lançado como projeto aberto no final de 2024.
Mas existe uma atualização extremamente importante:
MCP não pertence mais exclusivamente à Anthropic.
Em dezembro de 2025, a Anthropic doou o projeto para a Agentic AI Foundation (AAIF), uma fundação sob a Linux Foundation criada para trabalhar com infraestrutura aberta para agentes de IA.
A AAIF foi fundada com contribuições da Anthropic, Block e OpenAI e recebeu apoio de empresas como Google, Microsoft, AWS, Cloudflare e Bloomberg.
Isso é estratégico.
Um protocolo que deseja conectar produtos concorrentes tem muito mais chance de ganhar confiança se não estiver sob controle exclusivo de um único fornecedor.
MCP já é utilizado fora do Claude?
Muito.
No final de 2025, os mantenedores já reportavam suporte nativo ou de primeira classe em produtos como:
ChatGPT;
Claude;
Cursor;
Gemini;
Microsoft Copilot;
Visual Studio Code.
Naquele momento, o ecossistema já possuía mais de 10 mil servidores MCP ativos e mais de 97 milhões de downloads mensais de SDKs.
E o crescimento continuou.
Na versão de julho de 2026, os mantenedores afirmaram que os SDKs Tier 1 estavam se aproximando de meio bilhão de downloads por mês, com os SDKs TypeScript e Python ultrapassando individualmente um bilhão de downloads acumulados.
Downloads não significam automaticamente usuários únicos.
Mas deixam claro que MCP deixou de ser um pequeno experimento específico da Anthropic.
Como o MCP funciona?
A arquitetura possui três papéis principais:
Host
Cliente MCP
Servidor MCP
A especificação atual utiliza uma arquitetura client-host-server. O protocolo é baseado em JSON-RPC e, desde a especificação 2026-07-28, seu núcleo é stateless: cada requisição transporta as informações necessárias para ser processada sem depender obrigatoriamente de uma sessão persistente anterior.
Vamos traduzir isso.
O que é um MCP Host?
O host é a aplicação principal de IA.
Pode ser, por exemplo:
ChatGPT;
Claude;
Cursor;
VS Code;
um agente empresarial;
uma aplicação própria.
O usuário conversa com o host.
É ele quem coordena o modelo, contexto, permissões e conexões.
Imagine:
Nesse exemplo, Claude Desktop é o host.
O que é um MCP Client?
Dentro do host existe o componente que fala o protocolo MCP.
Esse é o cliente MCP.
A arquitetura oficial estabelece que cada cliente se comunica com um servidor específico, enquanto o host pode administrar vários clientes simultaneamente.
Visualmente:
Isso ajuda a manter as integrações separadas.
O que é um servidor MCP?
O MCP Server é o componente que disponibiliza dados ou capacidades através do protocolo.
Por exemplo, um servidor MCP conectado ao CRM poderia disponibilizar:
Um servidor do GitHub poderia oferecer:
Um servidor de banco poderia oferecer:
O agente não precisa conhecer internamente cada API.
Ele vê capacidades descritas de maneira padronizada.
O que um servidor MCP pode disponibilizar?
O protocolo trabalha principalmente com três primitivas:
Tools
Resources
Prompts
A especificação atual descreve exatamente essas três categorias como os blocos fundamentais fornecidos por servidores MCP.
Tools: coisas que a IA consegue fazer
Tools são funções executáveis.
Exemplo:
Cada ferramenta possui nome, descrição e um schema indicando quais parâmetros espera.
O cliente pode listar as ferramentas disponibilizadas pelo servidor e o modelo consegue decidir qual delas utilizar conforme o pedido do usuário.
Imagine que você diga:
“Quantos clientes novos entraram hoje?”
O agente pode descobrir uma ferramenta chamada:
e chamá-la com:
Recebe os dados.
Interpreta.
E entrega a resposta.
Resources: informações que servem como contexto
Resources representam dados que o servidor disponibiliza para leitura.
Podem ser:
arquivos;
documentos;
schemas de banco;
histórico Git;
configurações;
conteúdo de aplicações.
Cada recurso recebe uma URI que permite identificá-lo.
A especificação cita explicitamente arquivos, schemas de banco de dados e informações específicas de aplicações como exemplos.
Imagine:
O host decide como incorporar esses recursos ao contexto da IA.
Prompts: fluxos ou instruções reutilizáveis
Servidores também podem oferecer prompts pré-definidos.
Imagine um servidor interno de atendimento que disponibiliza:
Esses prompts podem padronizar workflows conhecidos.
A especificação classifica prompts como controlados principalmente pelo usuário, resources pela aplicação e tools pelo modelo.
Exemplo prático: um agente conectado ao CRM através de MCP
Imagine dizer:
“Encontre os leads desta semana que ainda não receberam retorno e crie uma tarefa para cada vendedor responsável.”
Sem integração, o modelo não consegue fazer isso.
Com um servidor MCP do CRM, o fluxo poderia ser:
1. O usuário faz o pedido
2. O agente consulta as ferramentas disponíveis
O servidor apresenta:
3. A IA escolhe uma ferramenta
Primeiro:
4. O MCP Server consulta o CRM
O servidor traduz aquilo para a API ou lógica interna necessária.
5. Os dados retornam para a IA
O modelo analisa os leads.
6. O agente identifica aqueles sem atendimento
Agora decide chamar:
7. Dependendo das permissões, o usuário aprova
O sistema cria as tarefas.
Perceba algo importante:
MCP não substituiu o CRM nem sua API.
Ele criou uma camada padronizada entre a aplicação de IA e aquelas capacidades.
MCP substitui APIs?
Não.
Esse é provavelmente um dos mitos mais importantes sobre MCP.
APIs continuam fundamentais para a arquitetura de praticamente todo sistema moderno. Se quiser aprofundar esse conceito, veja também nosso guia sobre como funciona uma API e por que praticamente todo sistema moderno usa uma.
Um servidor MCP frequentemente utiliza APIs por baixo.
Pense assim:
API: interface para software conversar com software.
MCP: interface padronizada especificamente para aplicações e agentes de IA descobrirem e utilizarem contexto e ferramentas.
Imagine que um serviço já possua uma API completa.
Você não precisa abandonar essa API para adotar MCP.
A arquitetura pode funcionar assim:
MCP cria uma camada orientada à maneira como agentes descobrem capacidades e entendem como utilizá-las.
A API continua executando grande parte do trabalho real.
Portanto:
MCP não substitui APIs. Ele pode tornar APIs muito mais fáceis de consumir por agentes de inteligência artificial.
Por que MCP combina tão bem com agentes de IA?
Porque um agente precisa de três coisas fundamentais:
raciocínio;
contexto;
capacidade de agir.
Se você ainda não está familiarizado com esse conceito, vale primeiro entender o que são agentes de IA e por que eles estão mudando a forma de trabalhar.
O modelo fornece grande parte do raciocínio.
Os Resources do MCP podem fornecer contexto.
As Tools podem fornecer capacidade de ação.
MCP padroniza justamente a conexão entre esses elementos externos e a aplicação que contém o modelo.
É quase uma infraestrutura natural para a arquitetura agêntica.
Essa relação fica ainda mais evidente em ferramentas modernas de desenvolvimento. Codex, Claude Code, Cursor e GitHub Copilot estão evoluindo de simples assistentes de código para agentes capazes de pesquisar repositórios, utilizar ferramentas e executar tarefas de várias etapas.
Temos um comparativo completo sobre Codex, Claude Code, Cursor e Copilot e qual ferramenta de IA usar para programar.
À medida que esses agentes recebem mais capacidades, surge uma necessidade clara:
eles precisam de uma maneira padronizada de descobrir e utilizar ferramentas.
É exatamente o tipo de problema que MCP tenta resolver.
Então qual é a diferença entre MCP e API?
API tradicional | MCP |
|---|---|
Interface geral entre softwares | Protocolo orientado a aplicações de IA |
Integração definida pelo desenvolvedor | Descoberta padronizada de capacidades |
Endpoints precisam ser conhecidos | Ferramentas podem ser descobertas |
Documentação voltada ao desenvolvedor | Schemas e descrições também são consumidos pelo agente |
Cada API possui seu próprio desenho | MCP cria uma camada comum |
Continua sendo infraestrutura principal | Frequentemente funciona sobre APIs existentes |
Portanto:
MCP não mata APIs. Ele pode tornar APIs mais fáceis de consumir por agentes.
MCP é igual a function calling?
Também não.
Function calling é uma técnica pela qual um modelo consegue produzir uma chamada estruturada para uma função.
Imagine definir:
O modelo percebe que precisa dessa função e produz argumentos.
MCP resolve uma camada diferente.
Ele padroniza:
como descobrir ferramentas;
como descrevê-las;
como chamá-las;
como receber respostas;
como acessar recursos;
como conectar diferentes servidores;
como lidar com autorização e outras capacidades.
Na prática, um aplicativo pode pegar tools descobertas via MCP e apresentá-las ao modelo através do mecanismo de tool/function calling do provedor.
Então:
function calling é a capacidade do modelo chamar funções.
MCP é a infraestrutura padronizada que pode fornecer essas funções ao aplicativo.
MCP é igual a plugin ou conector?
Não.
Um plugin ou conector é um produto ou integração específica.
MCP é o protocolo.
É semelhante à diferença entre:
website e HTTP.
Um website é a experiência.
HTTP é parte do padrão de comunicação.
Da mesma maneira, vários apps e conectores podem ser construídos utilizando MCP.
O ChatGPT, por exemplo, já permite que organizações criem apps personalizados baseados em MCP capazes de consultar informações e, em determinadas configurações, executar ações de escrita e modificação em sistemas empresariais.
MCP é igual a RAG?
Não.
RAG — Retrieval-Augmented Generation — é uma arquitetura utilizada para recuperar informações e adicioná-las ao contexto de um modelo.
MCP pode ajudar uma aplicação a encontrar ou acessar informações.
Mas também pode executar ações.
Por exemplo:
Enquanto MCP pode permitir:
MCP é mais amplo.
MCP é igual a A2A?
Não.
O protocolo A2A, promovido inicialmente pelo Google, trata principalmente de comunicação entre agentes.
MCP trata principalmente da relação:
agente ↔ ferramentas/dados
Enquanto A2A trata:
agente ↔ agente
O próprio Google posiciona os dois protocolos como complementares.
Uma arquitetura futura pode perfeitamente utilizar ambos:
Como o MCP se comunica tecnicamente?
MCP utiliza mensagens JSON-RPC.
Nas implementações atuais existem cenários locais e remotos.
Historicamente, os dois transportes mais importantes foram:
stdio
e
Streamable HTTP.
stdio é especialmente útil quando cliente e servidor rodam localmente: o aplicativo inicia o servidor como um processo e conversa através da entrada e saída padrão.
Streamable HTTP é utilizado para servidores acessíveis via HTTP.
A especificação de julho de 2026 mudou bastante essa arquitetura.
O MCP mudou bastante em 2026
Este é um ponto que muitos artigos antigos já deixam errado.
A especificação atual é a 2026-07-28.
A maior mudança foi tornar o núcleo do protocolo stateless.
Versões anteriores utilizavam handshake e sessões de protocolo.
Agora cada request carrega informações como versão e capacidades necessárias, permitindo que uma requisição possa ser atendida por diferentes instâncias atrás de um balanceador sem depender daquela sessão escondida no transporte.
Isso é extremamente relevante para empresas.
Uma tecnologia que funciona bem em um notebook não necessariamente funciona bem distribuída por centenas de servidores.
A evolução de 2026 deixa MCP mais próximo da infraestrutura HTTP tradicional utilizada para aplicações de larga escala.
Por que transformar MCP em stateless importa?
Imagine um servidor recebendo milhões de chamadas.
Se cada usuário precisar manter uma sessão vinculada a uma determinada máquina:
a infraestrutura precisa preservar essa afinidade.
Com requests independentes:
fica mais simples utilizar balanceamento, replicação e infraestrutura convencional.
Os próprios mantenedores apontam escalabilidade e confiabilidade como razões centrais para essa mudança.
MCP também ganhou extensões
Outro sinal de maturidade é que nem toda funcionalidade precisa entrar no núcleo do protocolo.
Em 2026, MCP consolidou um framework de extensions.
Isso permite adicionar capacidades específicas sem transformar o core em algo gigantesco.
Dois exemplos relevantes são:
MCP Apps
e
Tasks.
O que são MCP Apps?
MCP Apps permitem que uma tool retorne não apenas texto ou JSON, mas uma interface interativa.
Por exemplo:
um formulário;
dashboard;
gráfico;
seletor;
workflow;
visualização.
Essa UI pode aparecer dentro do ambiente do agente.
O suporte foi desenvolvido de maneira colaborativa e já aparece em clientes como ChatGPT, Claude, Goose e Visual Studio Code.
Isso expande bastante a ideia original de “conectar dados à IA”.
MCP pode começar a funcionar também como camada para experiências interativas.
E Tasks?
Algumas ações demoram segundos.
Outras podem durar minutos ou horas.
A extensão Tasks permite representar trabalhos assíncronos de longa duração.
Um servidor pode devolver um identificador de tarefa em vez de exigir que o cliente espere pela resposta final.
Depois, o cliente consegue consultar, atualizar ou cancelar aquela tarefa.
Isso é muito útil para agentes que executam trabalhos complexos.
Por que o MCP está ganhando tanta adoção?
Há uma razão econômica.
Sem um padrão, podemos chegar a um problema combinatório.
Imagine:
10 aplicativos de IA.
100 ferramentas empresariais.
Se cada combinação exigir sua própria integração:
Com um padrão comum, cada lado implementa uma interface interoperável.
Não significa literalmente transformar 1.000 integrações em 110 em todos os cenários reais.
Mas reduz drasticamente a necessidade de construir a mesma camada de conexão repetidamente.
Esse efeito é extremamente poderoso.
Por que fornecedores gostam do MCP?
Imagine que você desenvolva um software SaaS.
Quer permitir que seu sistema seja utilizado por:
Claude;
ChatGPT;
Gemini;
Cursor;
VS Code;
agentes internos de empresas.
A alternativa seria desenvolver e manter integrações específicas para todos.
Com MCP, você consegue expor um servidor padronizado e permitir que clientes compatíveis consumam aquelas capacidades.
Esse é um incentivo enorme para fornecedores.
Por que fabricantes de IA gostam do MCP?
O problema inverso também existe.
Imagine desenvolver ChatGPT ou Claude.
Usuários querem integração com:
GitHub;
Slack;
Notion;
CRM;
ERP;
bancos;
arquivos;
databases;
milhares de SaaS.
Não existe maneira sustentável de uma única empresa manter manualmente integração exclusiva com todos esses sistemas.
Um protocolo aberto distribui esse trabalho.
A adoção do Google é um sinal importante
Em dezembro de 2025, o Google Cloud anunciou suporte oficial a MCP para seus serviços.
Em abril de 2026, já oferecia mais de 50 servidores MCP gerenciados, entre serviços disponíveis e em preview.
Isso inclui integrações em áreas como:
Google Maps;
BigQuery;
GKE;
Cloud Run;
bancos de dados;
serviços de nuvem.
É um sinal particularmente relevante porque MCP nasceu em uma concorrente direta do Google no mercado de modelos de IA.
Padrões começam a ficar interessantes quando concorrentes têm incentivo para adotá-los.
Microsoft também adotou MCP
O Copilot Studio permite conectar agentes a servidores MCP para disponibilizar recursos e ferramentas.
A documentação atual da Microsoft destaca uma vantagem importante: quando tools ou resources disponíveis no servidor mudam, o agente pode refletir dinamicamente aquelas mudanças, reduzindo a necessidade de recriar manualmente cada integração.
O Visual Studio Code também possui suporte específico para adicionar e administrar MCP servers.
OpenAI também adotou o protocolo
Em maio de 2025, a OpenAI adicionou suporte a servidores MCP remotos na Responses API.
A empresa explicou que desenvolvedores poderiam conectar seus modelos a ferramentas hospedadas em servidores MCP com poucas linhas de código.
Desde então, MCP também passou a integrar a plataforma de apps do ChatGPT.
Portanto, o cenário não é:
Anthropic tentando convencer concorrentes a utilizar um protocolo do Claude.
É:
empresas concorrentes utilizando e contribuindo para uma camada comum de interoperabilidade.
MCP já possui um registro oficial
Outro componente importante do ecossistema é o MCP Registry.
Ele funciona como um repositório central de metadados sobre servidores MCP públicos.
Desenvolvedores podem publicar informações sobre seus servidores e clientes podem descobrir integrações disponíveis.
O registro oficial ainda está em evolução, mas possui apoio de participantes relevantes do ecossistema, incluindo Anthropic, GitHub e Microsoft.
A existência de discovery padronizado ajuda a transformar MCP de especificação técnica em ecossistema.
Então MCP já é um padrão?
Depende da definição de padrão.
Ele não é um padrão da web comparável à maturidade de HTTP.
Nem possui décadas de estabilidade.
A primeira versão pública apareceu no fim de 2024.
Portanto, ainda é muito jovem.
Mas já possui características importantes de um padrão de fato emergente:
adoção por fornecedores concorrentes;
governança neutra;
especificação aberta;
SDKs em múltiplas linguagens;
registro;
implementações empresariais;
extensões;
processo formal de evolução;
grande ecossistema.
Os próprios mantenedores passaram a descrevê-lo como padrão de fato para conectar modelos a dados e ferramentas após seu primeiro ano.
O que ainda pode impedir MCP de virar um padrão dominante?
A história da tecnologia está cheia de padrões promissores que perderam espaço.
MCP ainda precisa resolver desafios importantes.
Segurança
Este é provavelmente o maior.
Quando uma IA apenas recebe informação errada, o dano pode ser limitado.
Quando possui acesso a ferramentas que:
enviam e-mails;
apagam arquivos;
consultam banco;
criam pagamentos;
executam código;
o problema muda completamente.
O protocolo precisa coexistir com controles de segurança muito fortes.
Governança empresarial
Empresas precisam conseguir controlar:
quem conecta quais servidores;
quais tools ficam disponíveis;
quais usuários possuem permissão;
quais dados podem sair;
como ações são auditadas.
A evolução atual do protocolo coloca identidade e segurança empresarial entre as principais prioridades do roadmap.
Compatibilidade
Um protocolo que evolui rapidamente também cria versões diferentes coexistindo.
A versão de julho de 2026, por exemplo, introduziu mudanças significativas na arquitetura.
SDKs precisam lidar com clientes antigos e novos durante períodos de migração.
Qualidade dos servidores
Ter um servidor MCP não significa automaticamente que aquela integração seja boa.
Ferramentas podem possuir:
descrições ruins;
schemas confusos;
permissões excessivas;
respostas imprevisíveis;
implementações inseguras.
Um padrão melhora interoperabilidade.
Não garante qualidade.
MCP também cria uma nova superfície de ataque
Existe um paradoxo.
O grande benefício do MCP é permitir que agentes descubram ferramentas e interajam com sistemas.
O grande risco é exatamente o mesmo.
A OWASP alerta que MCP introduz uma superfície de ataque que combina riscos tradicionais com problemas específicos de agentes, incluindo:
tool poisoning;
prompt injection;
rug pull;
excesso de permissões;
confused deputy;
supply chain;
exfiltração de dados.
Isso merece atenção especial.
O que é tool poisoning em MCP?
Imagine um servidor disponibilizando esta ferramenta:
Sua descrição parece legítima.
Mas dentro das instruções fornecidas ao modelo existe algo malicioso tentando convencê-lo a:
ler outro arquivo;
buscar uma credencial;
chamar outra ferramenta;
enviar dados externamente.
Como modelos utilizam descrições e resultados de tools dentro de seu raciocínio, conteúdo malicioso pode tentar manipular o comportamento do agente.
A OWASP chama esse tipo de ameaça de MCP Tool Poisoning.
É mais uma razão para não tratar qualquer servidor encontrado na internet como confiável.
Um servidor MCP possui as mesmas permissões do agente?
Isso depende da implementação.
E justamente por isso existe risco.
Imagine conectar um servidor local que consegue acessar:
Se ele roda com permissões amplas, uma vulnerabilidade ou implementação maliciosa pode acessar muito mais do que o usuário imaginava.
A própria documentação de segurança do MCP alerta para riscos de execução arbitrária, roubo de credenciais, exfiltração e perda de dados associados a servidores locais não confiáveis.
A Microsoft encontrou servidores MCP expostos sem autenticação
Esse não é apenas um risco teórico.
Em maio de 2026, a Microsoft relatou encontrar servidores MCP remotos expostos sem autenticação e afirmou que sinais do Defender for Cloud indicavam que 15% dos servidores MCP remotos observados em sua análise estavam severamente inseguros, permitindo acesso não autenticado a dados ou capacidades sensíveis.
Isso não significa que 15% de todos os MCP servers do mundo sejam inseguros.
É um resultado do conjunto monitorado pela Microsoft.
Mas demonstra que a implementação precisa acompanhar a velocidade da adoção.
MCP possui autenticação?
Sim.
Para servidores HTTP protegidos, a especificação define mecanismos de autorização alinhados a padrões modernos de OAuth.
A revisão atual reforçou validação de emissor, separação correta de tokens e mecanismos de descoberta de autorização.
Uma regra particularmente importante é que tokens destinados a um serviço não devem simplesmente ser repassados para outro.
Isso ajuda a evitar problemas de identidade e confused deputy.
“Se existe OAuth, então MCP é seguro?”
Não.
OAuth resolve parte do problema:
quem pode acessar?
Mas não resolve automaticamente:
o que o agente deveria fazer?
Um usuário pode possuir permissão legítima para excluir um arquivo.
Isso não significa que a IA deveria excluir aquele arquivo após interpretar uma instrução maliciosa escondida dentro de um documento.
É por isso que sistemas agênticos precisam combinar:
autenticação;
autorização;
menor privilégio;
confirmação humana;
validação;
isolamento;
auditoria.
O próprio Google recomenda identidades específicas para agentes e aplicação do princípio de menor privilégio ao utilizar MCP.
MCP e o caso recente do Claude
Os incidentes recentes divulgados pela Anthropic ajudam a mostrar por que esse tema importa.
Quando agentes possuem acesso a ferramentas e sistemas, segurança não pode depender apenas de:
“o modelo vai entender que não deveria fazer isso”.
É preciso limitar tecnicamente aquilo que o agente consegue alcançar.
MCP aumenta enormemente a interoperabilidade.
Isso torna controles de permissão ainda mais importantes.
O que a versão atual do MCP diz sobre aprovação humana?
A própria especificação de tools recomenda que aplicações mantenham humanos no circuito para operações relevantes.
Clientes devem mostrar quais ferramentas estão sendo disponibilizadas e oferecer confirmação para ações quando apropriado.
Essa abordagem é especialmente importante para operações:
destrutivas;
financeiras;
externas;
irreversíveis;
sensíveis.
Como seria um MCP da sua empresa?
Imagine que a Menzzo possua um sistema interno de projetos.
Hoje existe uma API com:
Um servidor MCP poderia transformar essas capacidades em ferramentas semanticamente compreensíveis:
Agora diferentes agentes compatíveis conseguem descobrir essas capacidades.
O servidor MCP continua chamando a API real por baixo.
Isso cria uma separação extremamente valiosa:
Exemplo: MCP para SEO
Imagine um agente de SEO conectado a:
Google Search Console;
analytics;
CMS;
inventário de páginas.
Um servidor MCP poderia expor:
Então o agente recebe:
“Encontre páginas que estão entre as posições 8 e 15 e cuja impressão cresceu nas últimas quatro semanas.”
Ele escolhe as ferramentas necessárias.
Coleta os dados.
Compara.
E prepara a análise.
O valor não está apenas em conectar a IA aos dados.
Está em criar uma interface reutilizável para agentes diferentes.
Exemplo: MCP para desenvolvimento
Este é provavelmente um dos ambientes em que MCP cresceu mais rápido.
Um agente de programação pode possuir servidores para:
GitHub;
filesystem;
banco;
browser;
documentação;
observabilidade.
Agora ele pode receber:
“Descubra por que esta issue acontece e proponha uma correção.”
O agente consulta issue.
Pesquisa arquivos.
Lê documentação.
Executa ferramentas.
Tudo através de interfaces padronizadas.
É por isso que editores e coding agents adotaram MCP tão rapidamente.
Exemplo: MCP em atendimento
Imagine um agente conectado ao CRM e ao sistema de pedidos.
Usuário pergunta:
“Meu pedido ainda não chegou.”
O agente pode:
buscar cliente;
localizar pedido;
consultar transportadora;
verificar prazo;
preparar resposta;
e, se autorizado, abrir chamado.
Não foi necessário ensinar ao modelo os detalhes técnicos de cada API diretamente no prompt.
As ferramentas estão descritas pelo servidor MCP.
O que muda para desenvolvedores?
Talvez bastante.
Historicamente, quando um desenvolvedor adicionava uma nova ferramenta à IA, precisava implementar código específico dentro da aplicação.
Com MCP, a integração pode se tornar uma unidade independente.
Isso permite:
reutilização;
portabilidade;
descoberta;
separação de responsabilidades.
Uma equipe pode cuidar do agente.
Outra cuida do MCP Server.
Outra continua responsável pela API.
Essa modularidade tende a ganhar valor à medida que o número de agentes aumenta.
O que muda para empresas SaaS?
Existe uma pergunta que empresas de software provavelmente começarão a ouvir cada vez mais:
“Vocês possuem MCP?”
Foi parecido com outras eras.
“Possui API?”
“Possui webhook?”
“Possui integração com Zapier?”
“Possui SSO?”
Se agentes se tornarem uma interface central do software empresarial, oferecer uma camada MCP pode virar uma vantagem importante de integração.
Não porque APIs perderão importância.
Mas porque clientes desejarão utilizar seus sistemas através de agentes.
O que muda para usuários?
O usuário final talvez nem saiba que MCP existe.
Ele simplesmente poderá dizer:
“Veja meu calendário e encontre três horários com o cliente.”
“Analise minhas vendas e atualize o relatório.”
“Consulte o GitHub e crie a tarefa correspondente.”
Nos bastidores, diferentes servidores MCP podem estar executando esse trabalho.
Os melhores protocolos frequentemente ficam invisíveis.
Você utiliza HTTP todos os dias sem pensar em HTTP.
Se MCP tiver sucesso, pode acontecer algo parecido.
Por que MCP combina tão bem com agentes de IA?
Porque um agente precisa de três coisas fundamentais:
raciocínio
contexto
capacidade de agir
O modelo fornece grande parte do raciocínio.
Resources podem fornecer contexto.
Tools podem fornecer ação.
MCP padroniza justamente a conexão entre esses elementos externos e a aplicação que contém o modelo.
É quase uma infraestrutura natural para a arquitetura agêntica.
O MCP pode criar um efeito de rede
Aqui está uma das razões mais importantes para acompanhar o protocolo.
Quanto mais clientes suportam MCP, maior o incentivo para empresas criarem servidores MCP.
Quanto mais servidores existem, maior o incentivo para novos clientes suportarem MCP.
Isso cria um ciclo:
É assim que padrões ganham força.
Não apenas por serem tecnicamente bons.
Mas porque a compatibilidade passa a gerar valor econômico.
A governança neutra pode ser decisiva
Imagine que MCP continuasse sendo exclusivamente controlado pela Anthropic.
OpenAI, Google e Microsoft teriam mais motivos para criar alternativas próprias.
Ao levar o protocolo para a Agentic AI Foundation sob a Linux Foundation, o projeto criou uma estrutura mais neutra para sua evolução.
Isso não garante sucesso.
Mas remove uma barreira importante.
A especificação ainda está evoluindo rapidamente
Também não podemos falar sobre MCP como se estivesse terminado.
O roadmap publicado em 22 de agosto de 2026 lista prioridades como:
mensageria para workloads agênticos;
unificação e endurecimento do transporte HTTP;
identidade de agentes;
segurança empresarial;
melhorias nas primitivas;
experiência dos SDKs.
Ou seja:
MCP possui grande adoção.
Mas ainda está amadurecendo.
As duas coisas podem ser verdade ao mesmo tempo.
Devemos construir tudo em MCP agora?
Não necessariamente.
MCP é uma ferramenta arquitetural.
Não uma obrigação.
Se sua aplicação possui:
um único agente;
duas ferramentas internas;
nenhuma necessidade de interoperabilidade;
integrações extremamente específicas;
criar uma camada MCP pode adicionar complexidade sem benefício imediato.
Por outro lado, MCP começa a fazer muito mais sentido quando:
diversos agentes precisam das mesmas ferramentas;
você quer trocar modelos ou clientes;
terceiros precisam conectar seus agentes;
a quantidade de integrações cresce;
ferramentas precisam ser descobertas dinamicamente.
Quando vale a pena criar um servidor MCP?
Considere MCP quando você quer expor capacidades para diferentes aplicações de IA.
Pergunte:
A mesma integração será utilizada por mais de um agente?
MCP ganha valor.
Quero permitir que clientes utilizem meu SaaS através de agentes?
MCP merece avaliação.
Já possuo uma boa API?
Excelente.
Você pode construir o MCP sobre ela.
A ferramenta possui operações sensíveis?
Então segurança e permissões precisam entrar antes da implementação.
Só preciso executar uma função simples em uma aplicação?
Function calling tradicional talvez seja suficiente.
Não transforme toda função em servidor MCP apenas porque a tecnologia está popular.
O que aprender primeiro para trabalhar com MCP?
Você não precisa começar decorando JSON-RPC.
Primeiro entenda cinco conceitos:
host
onde a IA está sendo executada.
client
componente que fala MCP.
server
fornece capacidades.
resources
dados/contexto.
tools
ações.
Depois disso, aprenda:
APIs;
HTTP;
OAuth;
JSON Schema;
permissões;
segurança de agentes.
Com esses conceitos, a arquitetura fica muito mais intuitiva.
MCP vai se tornar o padrão definitivo da inteligência artificial?
É cedo demais para afirmar.
Protocolos podem mudar.
Concorrentes podem surgir.
Novas necessidades podem exigir outras soluções.
Alguns problemas podem ser melhor resolvidos por protocolos complementares.
Mas a posição atual do MCP é difícil de ignorar.
Em menos de dois anos, ele saiu de um projeto da Anthropic para uma infraestrutura utilizada por produtos concorrentes, hospedada sob governança neutra e suportada por algumas das maiores empresas de tecnologia do mundo.
Isso não garante que MCP será “o HTTP dos agentes”.
Mas significa que ele já conquistou algo muito difícil:
coordenação entre concorrentes.
E padrões dependem mais de coordenação do que de hype.
A comparação com USB-C é útil — mas existe uma analogia ainda melhor
Talvez MCP se pareça menos com um cabo e mais com aquilo que aconteceu com protocolos da própria internet.
O valor de HTTP não está em ser a maneira tecnicamente perfeita de fazer tudo.
Está em permitir que:
servidores;
navegadores;
aplicações;
infraestrutura;
empresas;
falem uma linguagem suficientemente compartilhada.
MCP pode ocupar um papel semelhante em uma camada muito específica:
a comunicação entre aplicações de IA e capacidades externas.
Se isso acontecer, o modelo utilizado pode mudar.
A interface pode mudar.
O agente pode mudar.
Mas ferramentas continuam acessíveis através de um contrato comum.
Essa é uma ideia extremamente poderosa.
Conclusão: MCP não torna a IA mais inteligente — torna a IA mais conectada
Durante os últimos anos, grande parte da competição em inteligência artificial esteve concentrada nos modelos.
Quem raciocina melhor?
Quem escreve melhor?
Quem programa melhor?
Quem possui mais contexto?
A próxima disputa acontece também fora do modelo.
Com o que essa inteligência consegue conversar?
Quais dados consegue acessar?
Quais ferramentas consegue utilizar?
Quais ações consegue executar?
E essas integrações continuam funcionando se eu trocar de modelo ou aplicação?
É aqui que MCP entra.
Ele tenta criar uma linguagem compartilhada entre agentes e o ecossistema de software.
Isso reduz integrações personalizadas.
Aumenta portabilidade.
Facilita descoberta de ferramentas.
E cria uma base comum para uma geração de agentes que precisam fazer muito mais do que conversar.
Mas existe um preço.
Quanto mais conectado um agente fica, maior precisa ser o rigor sobre:
permissões;
identidade;
segurança;
auditoria;
aprovação humana.
MCP resolve o problema de como conectar.
Ele não resolve sozinho o problema de em quem confiar e até onde permitir que o agente vá.
Essa provavelmente será a próxima grande batalha.
Ainda é cedo para afirmar que MCP será o padrão definitivo da inteligência artificial.
Mas em setembro de 2026, uma coisa já está bastante clara:
ele deixou de ser apenas uma ideia da Anthropic e se tornou uma das peças mais importantes da infraestrutura emergente para agentes de IA.
Perguntas frequentes sobre MCP
O que é MCP em inteligência artificial?
MCP, ou Model Context Protocol, é um protocolo aberto criado para padronizar como aplicações de inteligência artificial acessam ferramentas, dados, recursos e serviços externos.
O que significa MCP?
MCP significa Model Context Protocol, que pode ser traduzido como Protocolo de Contexto de Modelo.
Quem criou o MCP?
MCP foi originalmente criado pela Anthropic e lançado publicamente em novembro de 2024. Em dezembro de 2025, foi doado para a Agentic AI Foundation, sob a Linux Foundation.
Para que serve o MCP?
MCP serve para conectar aplicações e agentes de IA a ferramentas e dados externos através de uma interface padronizada. Um agente pode utilizá-lo para consultar arquivos, bancos, APIs e sistemas ou executar ações autorizadas.
O que é um MCP Server?
Um MCP Server é um serviço ou processo que disponibiliza ferramentas, recursos e prompts através do protocolo MCP para clientes compatíveis.
O que é um MCP Client?
MCP Client é o componente dentro de uma aplicação de IA responsável por conversar com um MCP Server utilizando o protocolo.
Qual é a diferença entre MCP e API?
Uma API é uma interface geral utilizada para comunicação entre softwares. MCP é um protocolo voltado especificamente para conectar aplicações de IA a recursos e ferramentas. Servidores MCP frequentemente utilizam APIs existentes internamente.
MCP substitui APIs?
Não. MCP normalmente complementa APIs. Ele pode funcionar como uma camada padronizada que permite aos agentes descobrirem e utilizarem capacidades que continuam sendo executadas por APIs e serviços tradicionais.
Qual é a diferença entre MCP e function calling?
Function calling permite que um modelo gere chamadas estruturadas para funções conhecidas pela aplicação. MCP padroniza como ferramentas e recursos são descobertos, descritos e acessados entre diferentes clientes e servidores.
Qual é a diferença entre MCP e RAG?
RAG é uma técnica para recuperar informações e acrescentá-las ao contexto do modelo. MCP é um protocolo de integração mais amplo e pode fornecer tanto informações quanto ferramentas capazes de executar ações.
MCP é a mesma coisa que A2A?
Não. MCP é principalmente voltado à conexão de agentes com ferramentas e dados. A2A é voltado à comunicação entre agentes. Os protocolos podem ser utilizados de maneira complementar.
ChatGPT suporta MCP?
Sim. A OpenAI adicionou suporte a servidores MCP em suas APIs e utiliza MCP em recursos de apps personalizados do ChatGPT.
Claude suporta MCP?
Sim. MCP nasceu originalmente na Anthropic e faz parte do ecossistema Claude, embora atualmente seja um projeto independente sob governança da Agentic AI Foundation.
Gemini suporta MCP?
Sim. O Google adotou MCP em seus produtos e infraestrutura e oferece servidores MCP gerenciados para diversos serviços do Google Cloud.
Cursor suporta MCP?
Sim. Cursor está entre os ambientes de desenvolvimento que adotaram MCP para conectar agentes a ferramentas e fontes externas.
MCP é seguro?
MCP pode ser utilizado com segurança, mas não é seguro automaticamente. Implementações precisam tratar autenticação, autorização, menor privilégio, prompt injection, tool poisoning, servidores maliciosos, exposição de credenciais e aprovação de ações sensíveis.
Posso criar meu próprio servidor MCP?
Sim. Existem SDKs e bibliotecas para diferentes linguagens que permitem criar servidores MCP e disponibilizar tools, resources e prompts.
MCP é gratuito e open source?
A especificação e diversos SDKs são abertos. Serviços ou servidores construídos utilizando MCP podem possuir seus próprios modelos comerciais e custos.
Qual é a versão atual do MCP?
Em setembro de 2026, a especificação estável mais recente é a 2026-07-28, que introduziu um core stateless e várias mudanças voltadas a escalabilidade, extensões e segurança.
MCP pode virar o padrão para agentes de IA?
MCP já apresenta forte adoção entre grandes fornecedores, governança neutra e um ecossistema amplo. Isso o torna um forte candidato a padrão de fato para conexão entre agentes, ferramentas e dados, embora o protocolo ainda esteja evoluindo rapidamente.
