Arquitetura, funcionamento e diferenças para APIs, OpenAPI e Function Calling

Série MCP — Parte 1

Resumo

Modelos de linguagem deixaram de apenas gerar texto. Hoje eles consultam dados, escolhem ferramentas, executam ações e coordenam fluxos de trabalho — e essa mudança criou um problema de integração que ninguém tinha antes. Cada combinação entre uma aplicação de IA e um sistema externo tendia a virar um conector próprio, com seu esquema, sua autenticação e suas convenções. APIs, OpenAPI e function calling resolveram partes desse problema, mas nenhum deles estabeleceu uma camada comum para que uma aplicação de IA descubra capacidades, obtenha contexto e interaja de forma padronizada com sistemas que ela não conhecia de antemão.

O Model Context Protocol (MCP) ocupa esse espaço, adaptando ao domínio da IA conceitos do Language Server Protocol. Este artigo apresenta seus fundamentos, explica a arquitetura Host–Client–Server, detalha as primitivas de servidor (Tools, Resources, Prompts) e de cliente (Sampling, Elicitation, Roots), e o diferencia de REST, OpenAPI e function calling. Discute quatro implementações documentadas em literatura revisada por pares e analisa, com dados experimentais, a superfície de segurança que a padronização abre. A tese central é que o MCP não substitui APIs: ele é uma camada de integração orientada a agentes que consome as APIs existentes. (ANTHROPIC, 2024; FERRAG et al., 2026b).

Palavras-chave: Model Context Protocol; MCP; IA agentiva; agentes de IA; interoperabilidade; function calling; APIs; OpenAPI; JSON-RPC; segurança de agentes; LLM.

1. A IA aprendeu a falar. Depois precisou aprender a agir

Na primeira fase da popularização dos LLMs, a interação cabia em uma frase: o usuário fornecia texto, o modelo devolvia texto. O paradigma mudou quando esses modelos viraram componentes de agentes — sistemas que combinam percepção, raciocínio, planejamento, memória e ação sobre ambientes externos. Responder bem deixou de bastar. (FERRAG; TIHANYI; DEBBAH, 2026).

A distinção importa mais do que parece. Um LLM isolado tem o conhecimento que está em seus parâmetros e o que recebe no contexto da conversa. Ele não tem acesso ao estado atual do mundo nem aos sistemas que uma organização opera. A introdução do function calling estruturado, em 2023, permitiu que LLMs invocassem APIs externas de forma consistente e legível por máquina, viabilizando busca de dados em tempo real, computação e orquestração em múltiplas etapas. (FERRAG et al., 2026b).

O problema surgiu com a escala, e Ferrag et al. o descrevem sem rodeios: a expansão de plugins, conectores e protocolos ultrapassou as práticas de segurança, produzindo integrações frágeis — adaptadores escritos caso a caso para cada novo serviço, credenciais administradas manualmente, tratamento de erro reescrito toda vez, convenções específicas de plataforma a aprender. Fluxos de trabalho ficavam codificados de forma rígida, limitando a capacidade do agente de se adaptar em tempo de execução. E, crucialmente: "a ausência de um mecanismo de descoberta compartilhado ou de um vocabulário comum para capacidades de ferramentas aumenta o risco de lacunas de segurança". (FERRAG et al., 2026b, p. 353).

O MCP nasce dessa fricção.

2. O problema N × M já tinha acontecido antes

Vale uma pausa histórica que raramente aparece nos textos sobre MCP e que é a melhor forma de entender por que um protocolo era a resposta certa.

Em 2016, editores de código viviam uma versão idêntica do problema. Cada editor — VS Code, Vim, Emacs, Sublime — precisava suportar cada linguagem — Python, Go, Rust, TypeScript. Autocompletar, ir para a definição e detectar erros exigiam integração específica por par editor–linguagem. Com 10 editores e 20 linguagens, alguém teria que escrever e manter 200 integrações. A Microsoft, com Red Hat e Codenvy, respondeu com o Language Server Protocol (LSP): cada editor implementa o lado cliente uma vez, cada linguagem implementa um servidor uma vez, e as 200 integrações viram 30. (MICROSOFT, 2016).

Essa filiação não é analogia deste artigo. Ferrag et al. a registram explicitamente na literatura revisada por pares:

"O Model Context Protocol (MCP) adapta conceitos do Language Server Protocol para prover um framework orientado a descoberta, no qual agentes podem consultar serviços disponíveis, negociar formatos de dados e solicitar aprovação humana para operações sensíveis." (FERRAG et al., 2026b, p. 354, tradução nossa).

Trocando os termos: editores viram aplicações de IA, linguagens viram sistemas externos, e o mecanismo de redução do acoplamento é o mesmo.

A aritmética do acoplamento

Tabela 1 — Ordem de grandeza do acoplamento. Valores puramente combinatórios, ilustrativos do princípio arquitetural; não representam esforço real de implementação, que varia com a complexidade de cada integração.

3. APIs, OpenAPI e function calling: o que cada um já resolvia

Antes de dizer o que o MCP acrescenta, é preciso ser justo com o que já existia.

REST é um estilo arquitetural para sistemas distribuídos, formulado por Fielding em 2000, baseado em restrições que favorecem escalabilidade, interface uniforme e separação entre componentes. REST não é sinônimo de HTTP nem de API. Uma API REST resolve como um software acessa recursos e operações de outro software. (FIELDING, 2000; FIELDING; TAYLOR, 2002).

OpenAPI resolve a descrição: um contrato legível por máquina sobre uma API HTTP — endpoints, parâmetros, operações, estruturas de dados — sem exigir leitura do código-fonte. É documentação executável, não mecanismo de orquestração. (OPENAPI INITIATIVE, 2025).

Function calling resolve a decisão. A aplicação informa ao modelo quais funções existem e seus esquemas; o modelo escolhe uma e produz argumentos estruturados; a aplicação executa. Isso tornou previsível a ponte entre LLM e código, mas o conjunto de funções permanece atado àquela aplicação, àquele provedor e àquele momento. Li et al. observam o efeito colateral desse arranjo: ecossistemas de plugins como os da OpenAI, Coze e Yuanqi expandiram o alcance das ferramentas, mas permaneceram isolados, obrigando desenvolvedores a manter múltiplas versões da mesma ferramenta para plataformas diferentes — fragmentação que eleva risco de vulnerabilidade, produz controle de acesso inconsistente e limita auditabilidade. (OPENAI, 2026; LI et al., 2025).

O que faltava era permitir que aplicações de IA descobrissem capacidades de sistemas não registrados de antemão, de forma uniforme.

4. O que é, afinal, o Model Context Protocol

O MCP é um padrão aberto para conectar aplicações de IA a sistemas externos, apresentado publicamente pela Anthropic em 25 de novembro de 2024. A documentação usa a analogia do "USB-C para aplicações de IA": dispositivos diferentes continuam fazendo coisas diferentes, mas compartilham uma forma padronizada de conexão. (ANTHROPIC, 2024; MODEL CONTEXT PROTOCOL, 2026a).

A analogia ajuda e engana em partes iguais. O MCP não torna banco de dados, GitHub, ERP e sistema de arquivos a mesma coisa. Ele padroniza a interface pela qual uma aplicação de IA descobre e usa as capacidades que esses sistemas expõem. Por baixo, cada um continua com seu SQL, seu REST, seu SDK proprietário. Li et al. resumem a função: o protocolo "abstrai modularmente descrições de ferramentas, esquemas de entrada e saída e metadados de permissão", permitindo que LLMs descubram e invoquem ferramentas de forma autônoma. (LI et al., 2025; SABOIA; SWEET; SWEET, 2025).

Daí a definição que sustenta o resto do artigo:

O MCP é uma camada de integração orientada a agentes que consome APIs, bancos, arquivos e serviços como mecanismos subjacentes. Ele não os substitui.

4.1 O MCP não está sozinho: a família de protocolos agênticos

Um ponto que quase todo texto introdutório omite: o MCP resolve o eixo agente ↔ ferramenta. Ele não resolve o eixo agente ↔ agente. Sobre ele surgiram especificações complementares — o Agent-to-Agent (A2A) do Google, o Agent Network Protocol (ANP) e o Agent Communication Protocol (ACP) —, voltadas a colaboração ponto a ponto e orquestração multiagente. (FERRAG et al., 2026b; FERRAG; TIHANYI; DEBBAH, 2026). Estes serão tratados em artigos especificos.

A distinção não é acadêmica. O CoMAS-HPC, analisado adiante, usa os dois ao mesmo tempo: A2A para os agentes conversarem entre si, MCP para cada agente alcançar a infraestrutura. (VINAY P; SAURAV, 2025).

Tabela 2 — Eixos de comunicação em sistemas agênticos. Fontes: Ferrag et al. (2026b); Ferrag, Tihanyi e Debbah (2026); Vinay P e Saurav (2025).

5. Por dentro: Host, Client e Server

Host é a aplicação onde a experiência de IA acontece — um assistente de desktop, uma IDE, um agente de pesquisa. Ele coordena o modelo, as políticas da aplicação, a interação com o usuário e um ou mais clientes MCP.

Client mantém a relação protocolar entre o Host e um servidor específico. É o intermediário entre o LLM e o Server: transmite as requisições de invocação e devolve os resultados. Um Host pode manter vários clientes simultâneos, um por servidor.

Server expõe capacidades — como serviços ampliados ao Client, na forma de ferramentas, recursos e templates de prompt. Pode implementá-las diretamente ou funcionar como fachada sobre sistemas existentes. O servidor não precisa conter um modelo de linguagem. (LI et al., 2025; MODEL CONTEXT PROTOCOL, 2026a).

5.1 A camada de mensagens

Detalhe quase sempre omitido nas explicações introdutórias: o MCP não inventou formato de mensagem. Ele usa JSON-RPC — a mesma base que o LSP adotou. Três fontes independentes registram isso. Guo et al. descrevem que o MCP "permite que LLMs chamem funções, como consultar APIs ou controlar dispositivos, com entradas e saídas estruturadas, usando interfaces como JSON-RPC via stdio ou HTTP". Vinay P e Saurav são igualmente diretos: o MCP "padroniza como agentes interagem com a infraestrutura por meio de uma interface JSON-RPC uniforme, desacoplando a lógica do agente de backends específicos". (GUO et al., 2025; VINAY P; SAURAV, 2025; LI et al., 2025).

Tabela 3 — Transportes. Confira o transporte e a versão vigente na especificação adotada; esta camada mudou mais de uma vez desde 2024.

Nota de versão — leia antes de implementar. A especificação do MCP é versionada por data. Trabalhos publicados ao longo de 2025 descrevem um fluxo em três estágios — Inicialização (conexão e Return Tool List), Execução da Tarefa e Integração do Resultado — que revisões posteriores alteraram. Os conceitos de Host, Client, Server, Tools, Resources e Prompts permanecem estáveis; detalhes de handshake, transporte e autorização, não. Todo trabalho técnico sobre MCP deve registrar a versão da especificação utilizada. (LI et al., 2025; MODEL CONTEXT PROTOCOL, 2026e).

6. As primitivas: o vocabulário do protocolo

6.1 O que o servidor oferece

Tabela 4 — Primitivas de servidor. Fontes: Model Context Protocol (2026b; 2026c; 2026d); Li et al. (2025).

A distinção entre Tool e Resource é a que mais rende didaticamente. Um Resource entrega o esquema de uma base; uma Tool executa a consulta sobre ela. Um Resource entrega o conteúdo de um arquivo; uma Tool publica a alteração. A primeira é leitura, a segunda tem efeito sobre o mundo — e é por isso que a especificação prevê aprovação humana para operações sensíveis, mecanismo que Ferrag et al. destacam como parte do desenho do protocolo. (FERRAG et al., 2026b; MODEL CONTEXT PROTOCOL, 2026b).

Prompts são o elemento menos compreendido dos três. Em vez de esconder um template de instrução dentro da aplicação, o servidor o publica como parte da sua interface: quem conhece o domínio distribui junto a forma de interrogá-lo.

6.2 O que o cliente oferece — e por que isso muda tudo

Aqui está a diferença estrutural entre MCP e function calling que a maioria dos textos deixa passar: o canal é bidirecional. O servidor também pode pedir coisas ao cliente.

A consequência prática do Sampling merece ênfase: um servidor MCP pode conter inteligência sem carregar um modelo. Ele pede o raciocínio emprestado ao Host. Em function calling, essa via de volta não existe — a aplicação chama a função e a função responde, ponto final. É também essa bidirecionalidade que, como veremos, desloca controle e risco para o lado do LLM. (LI et al., 2025).

7. Uma interação ponta a ponta

Um usuário pergunta a um assistente corporativo: "Qual foi o faturamento do último trimestre e quais filiais caíram mais de 10%?"

Repare em onde o modelo entra: só no meio. A descoberta é protocolar e determinística; a escolha da ferramenta é probabilística; a execução volta a ser determinística. Essa alternância é o que torna o sistema auditável — e é também onde os riscos se concentram.

8. MCP não é uma API — com uma ressalva

A frase funciona como chamada de atenção, mas exige precisão. O MCP tem operações e mensagens que formam uma interface programática; em sentido amplo, ele também é uma API. O que ele não é é uma API de negócio como GET /clientes ou consultarSaldo(). Ele é um protocolo de integração que padroniza a relação entre aplicações de IA e servidores de capacidades.

Tabela — Diferenças conceituais. Fontes: Fielding (2000), OpenAPI Initiative (2025), OpenAI (2026), Gasmi et al. (2026), Li et al. (2025).

A diferença que mais importa cabe em duas frases. No function calling, a aplicação diz ao modelo: "estas são as funções que você pode usar agora". No MCP, servidores publicam e descrevem suas capacidades, e a aplicação as consulta em tempo de execução. Internamente, o Host pode muito bem usar function calling para decidir qual Tool acionar — os dois operam em camadas distintas e não competem.

9. Quatro implementações documentadas

9.1 OpenBridge — quando OpenAPI vira ferramenta MCP

Desenvolvido no Center for Research Computing da Universidade de Notre Dame, o OpenBridge é um servidor MCP que atua como proxy: ele lê a especificação OpenAPI de uma API científica, extrai as definições de endpoint e mapeia parâmetros e respostas para o formato de ferramenta MCP — automaticamente. Isso "elimina a necessidade de configuração manual de ferramentas e permite que o sistema evolua conforme as APIs mudam". (SABOIA; SWEET; SWEET, 2025).

Claude Desktop → MCP → OpenBridge → REST/OpenAPI → API dos PADs

O caso de uso são os Paper Analytical Devices (PADs), testes de baixo custo que verificam autenticidade farmacêutica em contextos de poucos recursos. O exemplo mais instrutivo do artigo é uma consulta em linguagem natural: "Liste os projetos que envolvem cartões usados para testes de medicamentos na Tanzânia." O assistente encadeou autonomamente uma sequência de chamadas — recuperar todos os projetos, filtrar por relevância geográfica, obter metadados estruturados do projeto identificado, e por fim consultar a escala, revelando mais de 3.100 amostras associadas. Os autores registram: nenhum desses passos foi explicitamente implementado.

Isso responde à pergunta "por que OpenAPI não bastava?". Mesmo APIs tecnicamente abertas "frequentemente carecem da clareza semântica de que os agentes precisam para raciocinar sobre a funcionalidade disponível ou formular chamadas de ferramenta apropriadas". O OpenBridge acrescentou ainda JSON-LD às respostas, ligando os dados a uma ontologia de domínio — lembrete de que interoperabilidade sintática e semântica são problemas relacionados, mas distintos.

9.2 SensorMCP — geração automática de ferramentas

Da Universidade Chinesa de Hong Kong, o SensorMCP inverte a lógica usual: em vez de expor ferramentas prontas, é um servidor MCP que gera ferramentas de sensor sob demanda, por meio de um pipeline de co-desenvolvimento entre ferramenta e linguagem. Um pedido como "monitorar vida selvagem" dispara a criação de uma ferramenta de detecção de objetos sob medida, com refinamento por feedback. A avaliação preliminar, com conjuntos de dados reais de zoológico, atingiu até 95% de taxa de sucesso de ferramenta em cenários de monitoramento animal. (GUO et al., 2025).

9.3 HARMONY — casas inteligentes (em simulação)

O HARMONY — Home Autonomous Resilient Multimodal Operations Nexus for You — combina um LLM multimodal com agentes especializados em conforto e ambiência, segurança, assistência culinária e entretenimento, coordenados por um Agente Orquestrador. O MCP fornece a orquestração padronizada: consultas de estado, assinaturas de evento, recuperação de dados, invocação de ações e gestão consistente de estado, enquanto o acesso aos dispositivos permanece nas APIs RESTful do ecossistema Samsung SmartThings. (MOHANAPRASAD K. et al., 2026).

Ressalva metodológica importante: a avaliação é baseada em simulação, em um ambiente doméstico simulado. Os próprios autores delimitam que as contribuições estão "dentro de um ambiente de casa inteligente inteiramente simulado". O trabalho demonstra viabilidade de orquestração, não desempenho em campo.

9.4 CoMAS-HPC — supercomputação

Do Centre for Development of Advanced Computing (Bengaluru), o CoMAS-HPC organiza uma federação de agentes especialistas — Orquestrador, Gerente de Operações, Analista de Performance — para administrar sistemas de computação de alto desempenho. A arquitetura separa dois planos com dois protocolos: A2A para os agentes conversarem entre si, MCP para cada um alcançar Slurm, Prometheus e Cassandra. (VINAY P; SAURAV, 2025).

O argumento central dos autores é a descoberta em tempo de execução: um agente "pode recuperar uma nova capacidade em tempo de execução e incorporá-la imediatamente ao seu plano — um nível de adaptação dinâmica impossível em sistemas multiagentes tradicionais, que exigem recompilação para integrar novas ferramentas". Em vez de escrever CQL para o Cassandra, o Analista de Performance invoca uma ferramenta genérica get_metric_timeseries.

Nos casos demonstrados, uma crise térmica coordenada foi resolvida em menos de cinco minutos, evitando dano de hardware. A validação, porém, foi feita em um único nó, deliberadamente, para isolar o comportamento do plano de controle.

O que os quatro têm em comum: o MCP não se resume a "plugin de chatbot". Ele funciona como plano de integração entre agentes e infraestruturas heterogêneas — desde que acompanhado de autenticação, autorização, validação e governança. É disso que trata a próxima seção.

10. Padronizar redistribui o risco — não o elimina

Tornar ferramentas e contexto descobríveis em tempo de execução amplia a capacidade do agente e, na mesma medida, sua superfície de ataque. Descrições de ferramentas e resultados de execução entram no contexto do modelo, e tudo que entra no contexto pode influenciar o raciocínio.

Li et al. identificam a vulnerabilidade estrutural: o arquivo de descrição de ferramentas armazenado no servidor é consultado pelo Client e usado durante a inferência do LLM. Atacantes podem lançar tool poisoning manipulando esse arquivo, ou construir servidores MCP falsos que se passam por legítimos. Como o MCP não possui verificação confiável de servidor e de metadados de ferramenta, ele é vulnerável a Rug Pull attacks — quando funcionalidade, permissões ou comportamento de uma ferramenta são alterados maliciosamente depois que o consentimento do usuário foi concedido. A resposta proposta é uma dupla assinatura: uma plataforma terceira confiável audita e assina o servidor e suas ferramentas; o desenvolvedor acrescenta a própria assinatura. Ambas precisam ser válidas antes da invocação. (LI et al., 2025).

Não é ameaça hipotética. Ferrag et al. catalogam mais de trinta técnicas de ataque em quatro categorias — Manipulação de Entrada, Comprometimento do Modelo, Ataques de Sistema e Privacidade, e Vulnerabilidades de Protocolo — e citam exploits reais, entre eles o Toxic Agent Flow no servidor MCP do GitHub e injeções Prompt-to-SQL (P2SQL). O framework foi validado por revisão de especialistas e mapeamento cruzado com incidentes reais e repositórios públicos de vulnerabilidade (CVE, NIST NVD). (FERRAG et al., 2026b).

10.1 O experimento de Gasmi et al.

O estudo mais direto sobre a questão comparou arquiteturas de function calling e MCP em 3.250 cenários de ataque distribuídos por sete modelos de linguagem, com controles positivos e negativos, execução em triplicata e avaliação cega. (GASMI et al., 2026).

O resultado que circula é o agregado: 73,5% de taxa de sucesso de ataque (ASR) no function calling contra 62,6% no MCP. Lido isoladamente, ele sugere que o MCP é mais seguro. Os dados por categoria mostram outra coisa.

Tabela 7 — ASR por categoria de ameaça. Adaptado de Gasmi et al. (2026, Tabela 4). Destaques em negrito indicam a arquitetura mais vulnerável em cada linha extrema.

Leia as duas últimas linhas. Em T8 (manipulação de confiança) e T9 (evasão de governança), o MCP é mais vulnerável. A vantagem agregada vem de T3 a T6 — ameaças centradas no sistema, que a separação cliente-servidor do MCP dificulta. O preço aparece nas ameaças centradas no contexto.

Gráfico — A troca é simétrica. O function calling concentra 88% de ASR em ameaças centradas no sistema e apenas 59% nas centradas no LLM. No MCP a relação se inverte: 57% e 68,3%. Trocar de arquitetura move o risco de lugar. Dados: Gasmi et al. (2026, Fig. 9).

O caso mais agudo dessa inversão está nos ataques simples por vetor:

Tabela — ASR por vetor em ataques simples. Adaptado de Gasmi et al. (2026, Fig. 12). O MCP tem 98% de sucesso de ataque em injeção indireta de prompt — o número mais alarmante do estudo, e o que o agregado de 62,6% esconde por completo.

10.2 Três achados contraintuitivos

Complexidade importa mais que arquitetura. Ataques encadeados de cinco passos atingiram 91% a 96% de sucesso em todas as configurações testadas. No function calling da Azure, a progressão vai de 35% (um passo) a 95% (cinco passos). O MCP degrada mais lentamente — a curva mais estável foi de 51% a 91% —, mas nenhuma arquitetura resiste. Os autores comparam com benchmarks estabelecidos: o AgentDojo alcança 92% de eficácia de defesa contra injeção direta, mas essa defesa cai para 67,4%–73,8% de sucesso de ataque diante de ataques compostos, que nenhum dos três benchmarks avaliados cobre. (GASMI et al., 2026).

Ataques compostos afetam as arquiteturas em direções opostas. Do simples para o composto, o function calling piora (56% → 70%), enquanto o MCP melhora (60% → 51,3%). A separação cliente-servidor obriga o atacante a comprometer componentes independentes, em vez de explorar interfaces fortemente acopladas.

Modelos com raciocínio detectam mais e caem mais. Modelos com capacidade de raciocínio apresentaram taxa de recusa superior — 17,8% contra 12,3% dos demais — e, ainda assim, os mais sofisticados registraram as maiores taxas de sucesso de ataque (Claude 3.5 com 75%, GPT-4.1 com 72%). Detecção inicial melhor não se traduziu em menor exploração depois que a defesa é rompida. Sob a mesma política de segurança, a variação entre modelos da mesma família chegou a 9,44 pontos.

Vale registrar um dado operacional: o tempo médio até o comprometimento foi menor no MCP (9,83 s) do que no function calling (16,69 s).

Tabela 9 — Superfície de ataque por camada. Síntese a partir de Ferrag et al. (2026b), Li et al. (2025) e Gasmi et al. (2026).

A conclusão é desconfortável e necessária: quando o modelo deixa de produzir texto e passa a provocar efeitos sobre sistemas, permissão mínima, validação de entrada e saída, aprovação humana para ações sensíveis, auditoria e proveniência deixam de ser boas práticas e viram requisitos.

11. Quando MCP faz sentido — e quando não

O MCP rende mais quando há muitas ferramentas ou fontes, quando as mesmas capacidades servem a várias aplicações, quando é preciso descobrir capacidades em tempo de execução, ou quando se quer desacoplar a lógica do agente dos detalhes de cada backend. OpenBridge, SensorMCP, HARMONY e CoMAS-HPC ilustram esses cenários.

O contrário também vale. Uma aplicação com uma integração estável, conhecida e inteiramente sob controle do time provavelmente não recupera o custo de uma camada a mais — nem o custo de segurança que ela traz. MCP é ferramenta arquitetural, não obrigação tecnológica de quem usa LLM.

12. Conclusão

O MCP não surgiu porque APIs pararam de funcionar. Surgiu porque a expansão dos agentes expôs um problema de interoperabilidade que as camadas anteriores não endereçavam — o mesmo problema que o LSP resolvera uma década antes em outro domínio, e cujos conceitos o MCP deliberadamente adaptou.

REST segue útil para arquiteturas distribuídas. APIs seguem sendo o modo de acessar serviços. OpenAPI segue descrevendo interfaces HTTP. Function calling segue sendo o mecanismo pelo qual um modelo indica função e argumentos. O MCP atua acima de todos eles, e ao lado de protocolos agente-a-agente que resolvem um eixo que ele não cobre.

Os casos documentados reforçam o posicionamento: o OpenBridge converte APIs OpenAPI em ferramentas; o SensorMCP gera ferramentas sob demanda; o HARMONY orquestra agentes domésticos em simulação; o CoMAS-HPC combina MCP e A2A para desacoplar agentes de sistemas de supercomputação. O valor do protocolo aparece menos em substituir tecnologias e mais em conectá-las a aplicações capazes de raciocinar sobre qual capacidade usar e quando.

Resta a tensão que definirá os próximos anos, e os dados de Gasmi et al. a tornam concreta. Adotar o MCP reduz exposição a ataques centrados no sistema e aumenta exposição a ataques centrados no contexto — com 98% de sucesso em injeção indireta de prompt e 91% a 96% em cadeias de cinco passos. Interoperabilidade e confiança puxam em direções opostas. É no equilíbrio entre as duas, e não na adoção do protocolo em si, que se decide se a IA agentiva será confiável o bastante para operar sistemas de verdade.

Referências

ANTHROPIC. Introducing the Model Context Protocol. 25 nov. 2024. Documento eletrônico. Acesso em: 12 ago. 2026.

FERRAG, Mohamed Amine; TIHANYI, Norbert; DEBBAH, Mérouane. From LLM Reasoning to Autonomous AI Agents: A Comprehensive Review. IEEE Access, v. 14, p. 84237–84285, 2026. DOI: 10.1109/ACCESS.2026.3698694.

FERRAG, Mohamed Amine; TIHANYI, Norbert; HAMOUDA, Djallel; MAGLARAS, Leandros; LAKAS, Abderrahmane; DEBBAH, Merouane. From prompt injections to protocol exploits: Threats in LLM-powered AI agents workflows. ICT Express, v. 12, p. 353–383, 2026. DOI: 10.1016/j.icte.2025.12.001.

FIELDING, Roy Thomas. Architectural styles and the design of network-based software architectures. 2000. Tese (Doutorado em Information and Computer Science) — University of California, Irvine, 2000.

FIELDING, Roy T.; TAYLOR, Richard N. Principled design of the modern Web architecture. ACM Transactions on Internet Technology, v. 2, n. 2, p. 115–150, 2002.

GASMI, Tarek; GUESMI, Ramzi; BENNACEUR, Jihene; BELHADJ, Ines. Bridging AI and software security: A comparative vulnerability assessment of LLM agent deployment paradigms. Information Sciences, v. 740, art. 123231, 2026. DOI: 10.1016/j.ins.2026.123231.

GUO, Yunqi; ZHU, Guanyu; LIU, Kaiwei; XING, Guoliang. SensorMCP: A Model Context Protocol Server for Custom Sensor Tool Creation. In: 3rd International Workshop on Networked AI Systems (NetAISys '25). Anaheim: ACM, 2025. 6 p. DOI: 10.1145/3711875.3736687.

LI, Shiqiang; WEI, Xinghai; YUAN, Jie; WANG, Xingwu; MIAO, Keji. Secure Model Context Protocol for Large Language Models with Dual Signatures. In: Workshop on Mobility in the Evolving Internet Architecture (MobiArch '25). Hong Kong: ACM, 2025. 6 p. DOI: 10.1145/3737897.3767287.

MICROSOFT. Language Server Protocol Specification. 2016. Documento eletrônico.

MODEL CONTEXT PROTOCOL. Architecture overview. Especificação do Model Context Protocol. 2026a. Acesso em: 12 ago. 2026.

MODEL CONTEXT PROTOCOL. Server Tools. 2026b. Acesso em: 12 ago. 2026.

MODEL CONTEXT PROTOCOL. Server Resources. 2026c. Acesso em: 12 ago. 2026.

MODEL CONTEXT PROTOCOL. Server Prompts. 2026d. Acesso em: 12 ago. 2026.

MODEL CONTEXT PROTOCOL. Specification changelog. 2026e. Acesso em: 12 ago. 2026.

MOHANAPRASAD K.; ROHITH G.; MONDAL, Akash; SINGH, Shrestha; TIWARI, Sourabh; SHARMA, Jalal. HARMONY: A Framework for Multimodal LLM-Powered AI Agents in Smart Homes via the Model Context Protocol. IEEE Access, v. 14, p. 13669–13687, 2026. DOI: 10.1109/ACCESS.2026.3653992.

OPENAI. Function calling. OpenAI API Documentation. 2026. Acesso em: 12 ago. 2026.

OPENAPI INITIATIVE. OpenAPI Specification, version 3.2.0. 2025. Acesso em: 12 ago. 2026.

SABOIA, Priscila; SWEET, James; SWEET, Christopher. OpenBridge: Bridging Domain Scientists and APIs through AI-Powered Interfaces. In: Practice and Experience in Advanced Research Computing (PEARC '25). Columbus: ACM, 2025. 3 p. DOI: 10.1145/3708035.3736045.

VINAY P, Tejas; SAURAV, Sumit Kumar. CoMAS-HPC: A Collaborative Multi-Agent System for HPC Administration. In: 2025 Supercomputing India (SCI). IEEE, 2025. DOI: 10.1109/SCI68648.2025.11333875.