MCP e sistemas multiagentes: conectando agentes, ferramentas e contexto

Série MCP — Parte 3

Pergunta central: onde o Model Context Protocol entra em uma arquitetura agentiva?

Sistemas baseados em grandes modelos de linguagem estão evoluindo de agentes isolados para arquiteturas formadas por múltiplos agentes especializados, mecanismos de orquestração, memória, políticas, ferramentas e fontes externas de conhecimento. Essa evolução cria um problema arquitetural: como permitir que diferentes agentes acessem bancos de dados, APIs, sistemas RAG, grafos de conhecimento, dispositivos, arquivos e serviços sem construir uma integração específica para cada combinação?

O Model Context Protocol (MCP) surge como uma possível camada de interoperabilidade entre o plano de controle de um sistema agentivo e seus recursos externos. Mas é importante começar pela distinção correta: MCP não é, por si só, um orquestrador multiagente nem um protocolo completo de coordenação entre agentes. A literatura recente tende a posicioná-lo principalmente como interface padronizada para contexto, ferramentas e capacidades externas, enquanto protocolos como A2A tratam mais diretamente de descoberta, delegação e comunicação entre entidades agentivas (ADIMULAM; GUPTA; KUMAR, 2026; EHTESHAM et al., 2025).

A hipótese arquitetural deste artigo é simples: MCP pode funcionar como a fronteira entre o plano de controle agentivo — agentes, planejamento, orquestração e governança — e o plano de capacidades externas — ferramentas, dados e sistemas reais.

1. Um agente sozinho é relativamente simples

Uma aplicação simples baseada em LLM pode ser representada assim:

Usuário
  ↓
LLM
  ↓
Resposta

Quando adicionamos ferramentas:

Usuário
  ↓
Agente
  ↓
Ferramenta
  ↓
Sistema externo

A complexidade cresce quando distribuímos responsabilidades entre especialistas:

Usuário
  ↓
Agente coordenador
  ├── Agente de pesquisa
  ├── Agente de banco de dados
  ├── Agente analista
  ├── Agente de conformidade
  └── Agente executor

Nesse cenário, especialização não basta. É necessário determinar quem executa cada tarefa, em qual ordem, com quais informações, sob quais políticas e com quais mecanismos de validação. Estudos recentes de orquestração multiagente tratam planejamento, estado, políticas e controle como preocupações distintas da interface utilizada para acessar ferramentas e serviços externos (ADIMULAM; GUPTA; KUMAR, 2026).

2. A primeira resposta: MCP entra entre o agente e o mundo externo

Uma arquitetura introdutória útil é:

Usuário
  ↓
Agente
  ↓
Orquestrador
  ↓
MCP Client
  ↓
MCP Servers
  ↓
Sistemas externos

Essa representação captura a ideia de que o MCP pode funcionar como interface padronizada entre a inteligência do sistema e as capacidades externas de que essa inteligência necessita. Em arquiteturas multiagentes, o orquestrador pode decompor objetivos, gerenciar estado e distribuir tarefas; o MCP operacionaliza o acesso a ferramentas, dados e serviços necessários para executar essas decisões (ADIMULAM; GUPTA; KUMAR, 2026).

O MCP não decide o que o sistema deve fazer. Ele padroniza como determinadas capacidades e contextos podem ser acessados para que o sistema consiga fazê-lo.

FIGURA SUGERIDA — Onde MCP entra em uma arquitetura agentiva?
Representar duas regiões: Plano de Controle (Agente → Planejamento → Orquestração) e Plano de Execução e Contexto (MCP → Tools/Resources → Sistemas externos).

3. MCP não é o cérebro do sistema

Considere a solicitação:

“Compare três fornecedores, encontre seus contratos, analise os riscos regulatórios e prepare um relatório.”

Um orquestrador poderia decompor o objetivo em identificar fornecedores, recuperar contratos, obter requisitos regulatórios, analisar riscos, comparar evidências e produzir um relatório. Essa decomposição pertence à lógica de planejamento e orquestração.

O MCP pode viabilizar capacidades como:

buscar_contrato()
consultar_fornecedor()
pesquisar_normativa()
consultar_knowledge_graph()
obter_documento()
executar_consulta_sql()

Mas não determina sozinho qual agente deve executar cada etapa, quando duas tarefas entram em conflito, quando uma tarefa terminou ou quando uma operação exige aprovação humana.

Podemos resumir:

MCP ≠ Orquestrador
MCP ≠ Planner

4. Uma formalização conceitual

Considere um objetivo do usuário G. Um orquestrador O recebe o objetivo, o contexto C e o estado S:

Π = O(G, C, S)

onde Π = {t₁, t₂, ..., tₙ} representa um plano formado por tarefas.

Cada tarefa pode ser atribuída a um agente:

A(tᵢ) = aⱼ

Antes da execução, uma camada de políticas pode decidir:

P(aⱼ, tᵢ, identidade, estado)
→ permitir | negar | exigir aprovação

Somente então a tarefa é transformada em uma chamada externa:

Rᵢ = MCP(server, tool, args)

O resultado altera o estado e pode gerar novo planejamento:

Sᵢ₊₁ = Update(Sᵢ, Rᵢ)

Essa equação é uma abstração didática, não uma definição do protocolo. Ela serve para localizar MCP na sequência:

Objetivo → Planejamento → Política → MCP → Execução

5. Sistemas multiagentes têm duas direções diferentes

Existem pelo menos duas relações fundamentais.

Agente → ferramenta:

Agente Financeiro
  ↓
consultar_balanco()
  ↓
Banco financeiro

Agente → agente:

Agente Coordenador
  ↓
“Analise estes dados”
  ↓
Agente Financeiro

A primeira envolve acesso a capacidades. A segunda envolve delegação de trabalho entre entidades autônomas. Surveys recentes sobre protocolos agentivos diferenciam essas funções e normalmente caracterizam MCP como protocolo de acesso a ferramentas e contexto, enquanto A2A e outros protocolos tratam diretamente da colaboração agent-to-agent (EHTESHAM et al., 2025; YANG et al., 2025).

6. MCP e A2A podem ocupar camadas complementares

                 A2A
Agente A ───────────────── Agente B
   │                           │
   │ MCP                       │ MCP
   ↓                           ↓
Server A                    Server B
   ↓                           ↓
Sistema X                   Sistema Y

Uma forma didática de pensar é:

A2A ≈ agent-to-agent
MCP ≈ agent-to-context/tool

Essa separação não é uma limitação absoluta dos protocolos, mas uma divisão arquitetural útil. Trabalhos de revisão e propostas de arquitetura colocam MCP e A2A como componentes complementares dentro de uma mesma pilha agentiva (EHTESHAM et al., 2025; ADIMULAM; GUPTA; KUMAR, 2026).

7. MCP pode conectar dois agentes?

Tecnicamente, sim. Essa nuance é importante.

Predoaia et al. (2026) implementaram o mesmo cenário multiagente usando MCP e A2A. O estudo concluiu que MCP pode suportar coordenação entre agentes em cenários relativamente restritos e pode resultar em uma implementação mais leve. Entretanto, estado conversacional, coordenação do ciclo de vida da tarefa e interações stateful de longo prazo precisam ser implementados acima do protocolo quando MCP é utilizado dessa forma.

MCP pode transportar uma interação com outro agente, mas isso não significa que MCP resolva sozinho todo o problema de coordenação multiagente.

8. A evolução para uma arquitetura em camadas

A arquitetura introdutória ainda esconde componentes importantes. Uma arquitetura mais madura seria:

                    USUÁRIO
                       ↓
                  INTERFACE
                       ↓
                 ORQUESTRADOR
                       ↓
          ┌────────────┼────────────┐
          ↓            ↓            ↓
      Agente A      Agente B      Agente C
          └────────────┬────────────┘
                       ↓
                 POLÍTICAS
                GOVERNANÇA
                       ↓
                  MCP GATEWAY
                       ↓
          ┌────────────┼────────────┐
          ↓            ↓            ↓
     MCP Server    MCP Server    MCP Server
          ↓            ↓            ↓
         APIs          RAG          IoT
         SQL       Knowledge Graph  Files

FIGURA PRINCIPAL SUGERIDA — Arquitetura agentiva governada.
Camadas: Experiência → Agentes → Orquestração → Governança → MCP Access Plane → MCP Servers → Sistemas reais. Mostrar A2A horizontalmente entre agentes.

9. Orquestração como plano de controle

Em sistemas distribuídos é comum separar control plane e data plane. Podemos aplicar uma abstração semelhante:

Control Plane: objetivos, planejamento, delegação, políticas, estado, prioridades e validação.

Capability / Execution Plane: consultas, APIs, leitura de documentos, gravações, comandos e operações externas.

Sob essa interpretação:

Orquestração ≈ Control Plane
MCP ≈ Capability Access Plane

Essa leitura é compatível com arquiteturas recentes em que a orquestração funciona como camada de controle e MCP operacionaliza a comunicação com ferramentas e sistemas de contexto (ADIMULAM; GUPTA; KUMAR, 2026).

10. Agentes especializados e contextos menores

Em vez de fornecer a um único agente centenas de ferramentas, dezenas de políticas e fontes heterogêneas de dados, uma arquitetura multiagente pode dividir responsabilidades:

O CoMAS-HPC oferece um exemplo concreto: o sistema divide administração de HPC entre um Orchestrator-Agent, um Ops-Manager-Agent e um Perf-Analyst-Agent. Os agentes colaboram, enquanto MCP padroniza o acesso a Slurm, métricas, arquivos e outros recursos da infraestrutura (VINAY P; SAURAV, 2025).

11. CoMAS-HPC: MCP desacoplando agentes da infraestrutura

A arquitetura do CoMAS-HPC pode ser resumida como:

Administrador
   ↓
Orchestrator
   ↓
Agentes especializados
   ↓
MCP
   ↓
Slurm · métricas · arquivos · infraestrutura

O ponto importante é que MCP desacopla a lógica dos agentes da tecnologia específica utilizada abaixo. Um agente pode solicitar uma capacidade genérica para consultar métricas sem precisar conhecer detalhes de Cassandra, Prometheus ou outro backend (VINAY P; SAURAV, 2025).

12. HARMONY: agentes, MCP e IoT

O framework HARMONY oferece outro caso. Ele combina um modelo multimodal, um orquestrador e agentes especializados em conforto, segurança, cozinha, entretenimento e gerenciamento de recursos. Esses agentes usam MCP para acessar dispositivos inteligentes, enquanto APIs do ecossistema SmartThings continuam abaixo da camada de abstração (MOHANAPRASAD K. et al., 2026).

Usuário multimodal
   ↓
MLLM
   ↓
Orchestrator Agent
   ↓
Agentes especialistas
   ↓
MCP
   ↓
SmartThings / APIs
   ↓
Dispositivos

MCP não substitui o sistema de IoT. Ele fornece a interface entre o raciocínio agentivo e esse sistema.

13. AgentMaster: MCP e A2A no mesmo sistema

O trabalho AgentMaster, apresentado no EMNLP 2025, é especialmente útil porque combina explicitamente A2A e MCP. O sistema realiza decomposição de consultas, roteamento dinâmico e execução por agentes especializados; MCP fornece acesso unificado a ferramentas e recursos, enquanto A2A suporta interações entre agentes (LIAO; LIAO; GADIRAJU, 2025).

Usuário
   ↓
Coordinator
   ↓
Domain Agents
   ↕ A2A
   ↓
MCP
   ↓
Tools + Resources

Esse desenho reforça que os protocolos podem atuar em eixos diferentes de interoperabilidade.

14. Três tipos de interoperabilidade

Essa última linha é importante: não existe evidência de que um único protocolo seja suficiente para resolver toda a coordenação de sistemas multiagentes. Propostas como MPAC exploram justamente coordenação de múltiplos agentes sobre estados e recursos compartilhados (QIAN; FANG; LI, 2026).

15. MCP como camada de contexto

O próprio nome do protocolo é revelador: Model Context Protocol. Contexto é mais amplo que ferramentas. Servidores MCP podem expor Resources para disponibilizar arquivos, documentos, schemas e outras fontes de informação ao Host.

Imagine três agentes:

Agente Jurídico
Agente Ambiental
Agente Comercial
        ↓
       MCP
        ↓
contexto do produto
legislação
evidências
dados comerciais

Cada agente pode consultar apenas o subconjunto de contexto necessário ao seu papel.

16. Contexto compartilhado não é memória compartilhada

Dois agentes podem acessar o mesmo Resource ou a mesma base de conhecimento e ainda manter estados internos totalmente distintos:

Memory_A ≠ Memory_B
State_A ≠ State_B

MCP pode permitir que agentes acessem a mesma fonte de contexto, mas isso não significa que compartilhem memória episódica, histórico de raciocínio, objetivos ou tarefas pendentes. Esse gerenciamento pertence normalmente à camada de orquestração. Essa distinção ajuda a explicar por que trabalhos que usam MCP para coordenação direta entre agentes precisam adicionar explicitamente mecanismos de estado e ciclo de vida da tarefa (PREDOAIA et al., 2026).

17. MCP + RAG

RAG pode aparecer abaixo da interface MCP:

Agente
  ↓
MCP Client
  ↓
Knowledge MCP Server
  ↓
Retriever
  ↓
Vector Database

Nesse desenho, o agente não precisa saber qual banco vetorial está sendo usado, como embeddings são produzidos ou onde documentos estão armazenados. Ele interage com uma capacidade estável, como search_knowledge(query).

A abstração torna-se:

Agent → MCP → RAG

em vez de acoplar diretamente o agente a Pinecone, pgvector, Elasticsearch ou outro backend específico.

18. MCP + Knowledge Graph

A mesma ideia vale para grafos de conhecimento. Trabalhos recentes como mcp-proto-okn exploram MCP como interface de linguagem natural para grafos científicos, incluindo inspeção de schema, SPARQL e expansão por ontologias (ROSE et al., 2026).

Regulatory Agent
   ↓
MCP
   ↓
Knowledge Graph Server
   ↓
Ontologia + Grafo

Outro agente poderia usar um MCP Server SQL. O orquestrador continua independente de onde ou como os dados são fisicamente armazenados.

19. A fronteira MCP

Essa leitura permite separar dois lados da arquitetura.

Acima do MCP:

• intenção;
• raciocínio;
• planejamento;
• agentes;
• políticas;
• governança;
• decisões.

Abaixo do MCP:

• APIs;
• bancos de dados;
• RAG;
• Knowledge Graphs;
• IoT;
• arquivos;
• SaaS e serviços corporativos.

FIGURA SUGERIDA — A fronteira MCP.
Parte superior: Agentic Control Plane. Centro: MCP Interoperability Boundary. Parte inferior: Enterprise Capability Plane.

20. Por que surge o MCP Gateway?

Quando vários agentes acessam vários MCP Servers, aparecem perguntas operacionais inevitáveis:

• quem pode chamar qual ferramenta?
• em nome de quem o agente está agindo?
• onde registrar as chamadas?
• como limitar custo e frequência?
• como revogar acesso?
• como aplicar DLP?
• como correlacionar uma decisão de ponta a ponta?

É nesse contexto que aparece o padrão arquitetural de MCP Gateway:

Agentes
  ↓
MCP Gateway
  ↓
MCP Servers

O gateway pode centralizar autenticação, autorização, roteamento, rate limiting, observabilidade, inspeção e aplicação de políticas. Ele não é uma exigência do protocolo; é um padrão de implantação particularmente útil em ambientes corporativos.

A revisão da especificação MCP de julho de 2026 também caminhou em direção a um núcleo stateless e mecanismos mais adequados a gateways e intermediários de infraestrutura. Como MCP evolui rapidamente, qualquer implementação deve registrar a versão da especificação utilizada.

21. Governança antes da execução

Considere uma operação:

transferir_pagamento(
  destino="Fornecedor X",
  valor=250000
)

A decisão do modelo de utilizar a ferramenta não deve constituir autorização suficiente. Uma camada de política pode avaliar identidade, papel, escopo, valor, ambiente, risco e necessidade de aprovação humana:

Allowed = Policy(
  identity,
  agent,
  tool,
  arguments,
  context
)

Se a decisão for negativa, a chamada MCP não é encaminhada. Isso cria uma separação fundamental:

Semântica e raciocínio sugerem ações; políticas e autorização impõem limites.

22. Por que governança é ainda mais importante em sistemas multiagentes?

Ações podem formar cadeias:

Agente A
  ↓
obtém documento

Agente B
  ↓
interpreta documento

Agente C
  ↓
seleciona ação

Agente D
  ↓
executa ação

Uma informação incorreta em A pode influenciar B, que influencia C e provoca uma ação em D. Uma falha local pode tornar-se uma falha sistêmica.

Pesquisas recentes sobre segurança MCP descrevem riscos como prompt injection, tool poisoning, servidores maliciosos e propagação de compromissos por cadeias agentivas (FERRAG et al., 2026; HOU et al., 2026).

23. O Gateway como Policy Enforcement Point

                POLICY DECISION
                      ↓
Agente → Gateway → MCP Server
            ↑
    POLICY ENFORCEMENT

O gateway pode registrar:

agent_id
user_id
tool
server
arguments
timestamp
policy_decision
result
trace_id

Isso permite reconstruir uma pergunta essencial em sistemas autônomos:

Quem decidiu o quê, utilizando qual ferramenta, com qual contexto, em nome de quem e com qual resultado?

24. Contexto também precisa de governança

Não basta governar ações. É necessário governar o contexto que alimenta as decisões.

Frameworks recentes, como ContextNest, tratam context governance como problema próprio: determinar quais artefatos estão aprovados, atuais, atribuíveis e verificáveis antes de serem disponibilizados aos agentes (SULPOVAR et al., 2026).

Governance = ActionGovernance + ContextGovernance

25. A arquitetura completa

Usuário / Aplicação
        ↓
     Orquestrador
        ↓
 ┌──────┼──────┐
 ↓      ↓      ↓
A1     A2     A3
 ↔ A2A / mensagens ↔
        ↓
Políticas e Governança
        ↓
    MCP Gateway
        ↓
 ┌──────┼──────────┬─────────┐
 ↓      ↓          ↓         ↓
RAG    SQL    Knowledge     IoT
MCP    MCP    Graph MCP     MCP
 ↓      ↓          ↓         ↓
Vector DB Banco     KG    Dispositivos

Uma forma útil de organizar essa arquitetura é em sete camadas:

Observabilidade e memória/estado atravessam várias camadas.

26. Tool ou Agent? A fronteira pode ser difusa

Um MCP Server pode expor algo aparentemente simples:

generate_market_report()

Mas internamente essa “Tool” pode iniciar:

Research Agent
   ↓
Financial Agent
   ↓
Reviewer Agent
   ↓
Report

Para o chamador continua parecendo uma Tool. Portanto:

Tool externa = Sistema agentivo interno

Isso permite arquiteturas compostas:

Agent
 ↓
MCP Tool
 ↓
Multi-Agent System
 ↓
MCP Tools
 ↓
External Systems

“Agente”, “Tool” e “serviço” podem ser papéis diferentes dependendo do nível de abstração.

27. Escalar o número de agentes não é suficiente

Mais agentes produzem mais mensagens, mais contexto, mais chamadas, mais custo, mais estados e mais pontos de falha. Por isso, sistemas multiagentes exigem orquestração explícita.

N_agentes ↑  não implica automaticamente  performance ↑

Trabalhos de orquestração destacam que sobrecarga de comunicação e conflitos podem se tornar gargalos se a coordenação não for cuidadosamente projetada (ADIMULAM; GUPTA; KUMAR, 2026).

28. Cada agente deveria enxergar todas as Tools?

Provavelmente não.

Um Compliance Agent pode precisar de:

search_regulation
get_policy
validate_requirement

mas não deveria necessariamente possuir:

delete_database
deploy_production
transfer_money

Uma boa arquitetura pode definir:

Tools(aᵢ) ⊂ Tools_global

Isso melhora simultaneamente segurança, clareza semântica, custo de contexto e probabilidade de seleção correta.

29. Princípio do menor privilégio agentivo

Um agente deve possuir apenas as capacidades necessárias para cumprir seu papel.

Permissions(Agent)
= MinimumCapabilities(Role)

e não:

Permissions(Agent)
= AllTools

Esse princípio torna-se ainda mais importante à medida que MCP facilita a conexão com um número crescente de capacidades.

30. Um exemplo empresarial completo

Imagine que o usuário peça:

“Avalie o fornecedor X para contratação.”

O orquestrador cria tarefas:

T1 → Due Diligence Agent
T2 → Financial Agent
T3 → Regulatory Agent
T4 → Risk Agent

O Financial Agent acessa ERP e SQL por um Finance MCP Server. O Regulatory Agent consulta RAG e Knowledge Graph por um Knowledge MCP Server. O Due Diligence Agent acessa fontes externas por um Search MCP Server. Os resultados convergem para um Risk Agent e, antes da decisão final, um Reviewer Agent verifica evidências.

Goal
 → Plan
 → Agents
 → MCP
 → Evidence
 → Validation
 → Decision

31. Rastro de auditoria

Se meses depois alguém perguntar “por que o sistema aprovou esse fornecedor?”, precisamos recuperar:

trace_id
user
orchestrator_plan
agents_involved
tools_called
arguments
sources
policy_decisions
results
final_decision

Ou seja:

Decision → EvidenceChain

MCP pode fornecer parte dos eventos de acesso, mas a correlação ponta a ponta precisa envolver orquestração, identidade dos agentes e decisões de política.

32. Segurança: capacidade maior, superfície maior

Quanto mais fácil conectar sistemas, maior o número de caminhos pelos quais um agente pode agir:

Capability ↑  ⇒  PotentialAttackSurface ↑

Ferrag et al. (2026) analisam vulnerabilidades que atravessam entradas, modelos, sistemas e protocolos em agentes LLM. A conclusão arquitetural é direta: interoperabilidade precisa ser acompanhada de autenticação, autorização, isolamento, validação, auditoria, confirmação humana e menor privilégio.

33. O que MCP resolve — e o que não resolve

34. Uma pilha de interoperabilidade começa a aparecer

┌────────────────────────────────┐
│       BUSINESS / GOALS         │
├────────────────────────────────┤
│       AGENT ORCHESTRATION      │
├────────────────────────────────┤
│   AGENT-TO-AGENT PROTOCOLS     │
│      A2A · ACP · outros        │
├────────────────────────────────┤
│      GOVERNANCE / POLICY       │
├────────────────────────────────┤
│              MCP               │
├────────────────────────────────┤
│ APIs · DB · RAG · KG · IoT     │
└────────────────────────────────┘

Essa pilha é conceitual, não um padrão oficial. Mas a literatura recente sobre interoperabilidade aponta nessa direção: protocolos diferentes estão emergindo para problemas diferentes (EHTESHAM et al., 2025; KONG et al., 2025).

35. Talvez o futuro não seja “um protocolo”

A Web não depende de uma única tecnologia. DNS, TCP/IP, TLS, HTTP, OAuth, HTML e JSON resolvem problemas distintos e se compõem.

Sistemas agentivos podem evoluir de forma semelhante:

Identity
   +
Governance
   +
Agent Communication
   +
MCP
   +
APIs

A interoperabilidade surgiria da composição das camadas.

36. MCP como “southbound interface” agentiva

Uma analogia útil vem de redes definidas por software. Em SDN, existe separação entre o plano de controle e interfaces que conectam o controlador aos dispositivos.

Agentic Control Plane
Planning · Agents · Policies
          ↓
         MCP
          ↓
   Capability Plane

Sob essa interpretação, MCP funciona como uma espécie de interface southbound do sistema agentivo. Não é uma terminologia oficial do protocolo; é uma analogia arquitetural para explicar sua posição.

37. Uma evolução em quatro estágios

Estágio 1 — LLM isolado

User → LLM

Estágio 2 — Agent + Tools

User → Agent → APIs

Estágio 3 — MCP-enabled Agent

User → Agent → MCP → Systems

Estágio 4 — Governed Multi-Agent System

User
 ↓
Orchestrator
 ↓
Specialized Agents
 ↓
Policy / Governance
 ↓
MCP Gateway
 ↓
MCP Servers
 ↓
Enterprise Systems

Horizontalmente:

Agent ← A2A / Messaging → Agent

FIGURA SUGERIDA — A evolução dos sistemas agentivos.
Quatro painéis: LLM → Agent + Tools → Agent + MCP → Multi-Agent + Governance + MCP Gateway.

38. A literatura ainda está amadurecendo

MCP foi apresentado publicamente no final de 2024 e sofreu mudanças importantes ao longo de 2025 e 2026. Parte relevante da literatura específica sobre MCP e multiagentes ainda é composta por preprints. Outras fontes já passaram por publicação em conferências e periódicos.

Isso exige cautela: resultados experimentais devem ser interpretados dentro dos respectivos ambientes e versões do protocolo.

39. O que a literatura permite afirmar hoje?

1. Arquiteturas multiagentes necessitam de mecanismos explícitos de orquestração, estado e comunicação.
2. MCP fornece uma interface padronizada para acesso de agentes a ferramentas e fontes externas de contexto.
3. Trabalhos científicos já integram MCP a arquiteturas multiagentes em HPC, IoT e sistemas conversacionais.
4. MCP e A2A podem ocupar camadas complementares.
5. MCP pode suportar determinadas formas de interação entre agentes, mas não oferece sozinho todas as abstrações necessárias para coordenação stateful e ciclo de vida das tarefas.
6. Gateways e camadas de governança estão emergindo como padrões importantes para implantações corporativas.

40. A resposta à pergunta central

Onde MCP entra em uma arquitetura agentiva?

A resposta mais útil não é apenas “entre o LLM e uma API”. Uma resposta arquiteturalmente mais rica é:

MCP entra na fronteira entre o plano de controle agentivo — onde vivem agentes, planejamento, orquestração e políticas — e o plano de capacidades externas — onde vivem ferramentas, dados e sistemas reais.

Agents
  ↓
Orchestration
  ↓
Governance
  ↓
MCP
  ↓
Capabilities

Em ambientes corporativos:

Agents
  ↓
Orchestration
  ↓
Governance
  ↓
MCP Gateway
  ↓
MCP Servers
  ↓
Systems

41. A ideia que você precisa guardar

No primeiro contato, MCP pode parecer apenas uma forma nova de chamar ferramentas. Em sistemas agentivos maiores, a interpretação mais poderosa é:

MCP = interoperability boundary

entre inteligência e capacidade operacional.

O orquestrador pensa sobre quem deve fazer o quê. A política decide o que pode ser feito. O MCP padroniza como acessar a capacidade necessária. O MCP Server traduz essa interação para o sistema real.

42. Conclusão

O Model Context Protocol torna-se mais interessante quando deixa de ser analisado isoladamente como mecanismo para executar Tools e passa a ser colocado dentro de uma arquitetura agentiva completa.

A camada de agentes fornece especialização e raciocínio. A camada de orquestração transforma objetivos em planos coordenados. A camada de governança define limites, identidade, políticas e supervisão. MCP fornece uma interface padronizada para acessar ferramentas e contexto. MCP Servers traduzem essa interface para APIs, bancos de dados, RAG, Knowledge Graphs, IoT e outros sistemas.

Experimentos como AgentMaster mostram que MCP pode coexistir com A2A; CoMAS-HPC utiliza MCP como interface para infraestrutura; HARMONY utiliza a camada para conectar agentes a dispositivos inteligentes. Ao mesmo tempo, estudos comparativos mostram que MCP não deve ser apresentado como uma solução completa para coordenação multiagente: estado conversacional, negociação, conflitos e ciclo de vida de tarefas frequentemente exigem abstrações adicionais.

A direção emergente não é a substituição de todos os protocolos por MCP. É a formação de uma pilha agentiva de interoperabilidade:

Goal
 → Agents
 → Orchestration
 → Governance
 → MCP
 → Systems

com comunicação entre agentes ocorrendo paralelamente por mecanismos como A2A ou outras abstrações especializadas.

Talvez essa seja a consequência mais importante do MCP: não estamos apenas criando uma forma padronizada para um chatbot chamar uma função. Estamos começando a definir a fronteira operacional entre sociedades de agentes e a infraestrutura digital sobre a qual esses agentes podem perceber, raciocinar e agir.

Referências

ADIMULAM, Apoorva; GUPTA, Rajesh; KUMAR, Sumit. The Orchestration of Multi-Agent Systems: Architectures, Protocols, and Enterprise Adoption. arXiv preprint arXiv:2601.13671, 2026.

EHTESHAM, Abul et al. A survey of agent interoperability protocols: Model Context Protocol (MCP), Agent Communication Protocol (ACP), Agent-to-Agent Protocol (A2A), and Agent Network Protocol (ANP). arXiv preprint arXiv:2505.02279, 2025.

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

FERRAG, Mohamed Amine et al. 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.

HOU, Xinyi et al. Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions. ACM Transactions on Software Engineering and Methodology, 2026.

KONG, Dezhang et al. A Survey of LLM-Driven AI Agent Communication: Protocols, Security Risks, and Defense Countermeasures. arXiv preprint arXiv:2506.19676, 2025.

KRISHNAN, Naveen. Advancing Multi-Agent Systems Through Model Context Protocol: Architecture, Implementation, and Applications. arXiv preprint arXiv:2504.21030, 2025.

LIAO, Callie C.; LIAO, Duoduo; GADIRAJU, Sai Surya. AgentMaster: A Multi-Agent Conversational Framework Using A2A and MCP Protocols for Multimodal Information Retrieval and Analysis. In: Proceedings of EMNLP 2025: System Demonstrations. Association for Computational Linguistics, 2025.

LI, Shiqiang et al. Secure Model Context Protocol for Large Language Models with Dual Signatures. In: MobiArch '25. ACM, 2025. DOI: 10.1145/3737897.3767287.

MODEL CONTEXT PROTOCOL. Model Context Protocol Specification. 2025–2026.

MOHANAPRASAD K. et al. HARMONY: A Framework for Multimodal LLM-Powered AI Agents in Smart Homes via the Model Context Protocol. IEEE Access, v. 14, 2026. DOI: 10.1109/ACCESS.2026.3653992.

PREDOAIA, Ionut et al. A Comparative Study of MCP and A2A for Inter-Agent Coordination in LLM-Based Systems. arXiv preprint arXiv:2607.23884, 2026.

QIAN, Kaiyang; FANG, Xinmin; LI, Zhengxiong. MPAC: A Multi-Principal Agent Coordination Protocol for Interoperable Multi-Agent Collaboration. arXiv preprint arXiv:2604.09744, 2026.

ROSE, Peter W. et al. mcp-proto-okn: Natural-language access to open scientific knowledge graphs through the Model Context Protocol. arXiv preprint arXiv:2605.30283, 2026.

SARKAR, Anjana; SARKAR, Soumyendu. Survey of LLM Agent Communication with MCP: A Software Design Pattern Centric Review. arXiv preprint arXiv:2506.05364, 2025.

SULPOVAR, Misha et al. ContextNest: Verifiable Context Governance for Autonomous AI Agent. arXiv preprint arXiv:2607.02116, 2026.

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.

YANG, Yingxuan et al. A Survey of AI Agent Protocols. arXiv preprint arXiv:2504.16736, 2025.

Este artigo faz parte da série MCP do MirandasTech.