BBDW 2026 · Autonomous Agents Workshop · Tópico 2

O protocolo MCP

No tópico anterior o agente ganhou mãos quando ligamos o MCP. Agora vamos abrir a caixa: o que é o Model Context Protocol, por que ele existe — e você vai construir o seu próprio servidor MCP que lista pods, lê logs e mata pods no OpenShift.

🧩 Host · Client · Server 🛠️ Tools · Resources · Prompts ☕ Quarkus MCP Server
Por que MCP existe

O problema M × N

  • 🧨
    Cada modelo/agente (M) precisa falar com cada ferramenta ou sistema (N). Sem padrão, são M × N integrações sob medida.
  • 🔌
    MCP é o USB-C dos agentes: um único protocolo entre o agente e qualquer ferramenta. Vira M + N.
  • ♻️
    Escreveu um servidor MCP uma vez? Qualquer agente que fale MCP passa a usá-lo — Claude, o seu agente do workshop, IDEs.
💡
A ideia central
MCP padroniza como um agente descobre e chama ferramentas — não quais ferramentas. Você expõe capacidades (listar pods, ler logs…) e qualquer host compatível sabe usá-las, com os argumentos certos.
Definição

Um protocolo aberto entre agente e ferramentas

MCP (Model Context Protocol) é um protocolo aberto, baseado em JSON-RPC 2.0, que padroniza a conexão entre aplicações de IA e fontes externas de contexto e ação. O agente descobre o que existe e chama de forma estruturada — nada de colar texto no prompt na mão.

🧭
Três verbos que importam
Descobrir (tools/list) · Chamar (tools/call) · Receber o resultado estruturado de volta. É só isso — e é poderoso.
🤖
Host
a aplicação de IA (o seu agente)
🔗
Client
1 conexão MCP por servidor
🧰
Server
expõe ferramentas e dados
⛵
Sistema real
OpenShift, banco, API…
Arquitetura

Do agente ao cluster, em uma linha

🤖 Agente host + LLM 🔗 MCP Client JSON-RPC 🧰 MCP Server @Tool: listar, logs, matar ⛵ OpenShift pods reais
tools/call → cliente → servidor MCP → ação no cluster resultado de volta
Capacidades

O que um servidor MCP expõe

🛠️ Tools

Ações que o agente pode executar — com nome, descrição e um schema de argumentos. Ex.: listar_pods(namespace). É o que vamos construir hoje.

📄 Resources

Dados que o agente pode ler como contexto — arquivos, registros, trechos de log — endereçados por URI.

💬 Prompts

Modelos de prompt reutilizáveis que o servidor oferece ao host — fluxos prontos que o usuário pode invocar.

🔎 Discovery

O host chama tools/list e recebe o catálogo com os schemas. O agente passa a saber, sozinho, o que existe e como chamar.

🎯
Hoje focamos em Tools
São o coração do "agente que age". Um servidor com 3 ferramentas bem descritas já muda o jogo — o modelo escolhe qual chamar e com quais argumentos.
Como conversa

Transporte e o handshake

  • 🖥️
    stdio — servidor local, o host o inicia como subprocesso. Ótimo para ferramentas de desktop/IDE.
  • 🌐
    HTTP + SSE — servidor remoto, acessível pela rede. É o que usamos no cluster: o agente fala com o MCP server por uma Route.
  • 🤝
    initialize — toda sessão começa com um handshake: versão do protocolo, capacidades e clientInfo. Só depois vêm tools/list e tools/call.
⚠️
Detalhe que pega todo mundo
Se o initialize não mandar o clientInfo, alguns servidores nunca respondem e o handshake trava. Foi exatamente o bug que enfrentamos ao construir o Forge. Bom saber antes de depurar por horas.
Ciclo de vida

O que acontece numa chamada de ferramenta

01 · DESCOBRE
📇 tools/list
O host pede o catálogo. O servidor devolve nome, descrição e schema de cada ferramenta.
02 · DECIDE
🧠 o LLM escolhe
Diante da pergunta, o modelo decide qual ferramenta usar e monta os argumentos.
03 · CHAMA
📞 tools/call
O cliente envia a chamada. O servidor executa de verdade — aqui, fala com o OpenShift.
04 · RESPONDE
📦 result
O servidor devolve um resultado estruturado. O agente usa para responder ou encadear a próxima ação.
🔒
Determinístico e rastreável
Diferente de "o modelo escreveu um comando", a tool call é um contrato: argumentos validados por schema, execução no servidor, resultado registrado. É isso que torna o agente seguro o bastante para agir num cluster.
Governança

MCP Gateway: poder com controle

Dar ao agente uma ferramenta que mata pods é poderoso — e precisa de guarda-corpos. Um MCP Gateway fica entre o agente e os servidores MCP e aplica política: quais ferramentas são permitidas, para quem, com que limites.

  • ✅
    Permitir listar_pods e ver_logs para todos…
  • 🛑
    …mas exigir aprovação (ou bloquear) matar_pod, ou limitar a taxa (ex.: 5/min).
  • 📊
    E registrar tudo: quem chamou o quê, quando. Auditoria de ponta a ponta.
🧭
No workshop
Hoje você constrói o servidor MCP "cru", para sentir o poder. Mais à frente colocamos o Gateway na frente e vemos, ao vivo, uma política bloquear o kill e filtrar conteúdo — o mesmo servidor, agora governado.
Exercício 2 · Mão na massa

Construa seu MCP server em Quarkus

1️⃣ Scaffold

Um projeto Quarkus com a extensão quarkus-mcp-server-sse. Sem UI, sem banco — só ferramentas.

2️⃣ Três ferramentas

listar_pods, ver_logs(pod) e matar_pod(pod) — cada uma um método anotado com @Tool.

3️⃣ Deploy no seu namespace

Build binário e deploy no OpenShift, com permissão para ler/apagar pods do seu ambiente.

4️⃣ Ligue no seu agente

Aponte o toggle MCP do seu agente para a URL do seu servidor e peça: "liste meus pods".

🏁
Objetivo
Ao final, o seu agente vai matar um pod chamando uma ferramenta que você escreveu — e você vai entender, na prática, por que o MCP é o que transforma um chatbot num operador do cluster. O passo a passo está no seu Mission Control.
O código

Uma ferramenta é um método anotado

// Cada método @Tool vira uma ferramenta que o agente descobre e chama. @Singleton public class ClusterTools { @Inject KubernetesClient k8s; @Tool(description = "Lista os pods de um namespace") public String listar_pods(@ToolArg(description = "Namespace") String namespace) { return k8s.pods().inNamespace(namespace).list().getItems().stream() .map(p -> p.getMetadata().getName() + " · " + p.getStatus().getPhase()) .collect(Collectors.joining("\n")); } @Tool(description = "Mata (deleta) um pod pelo nome") public String matar_pod(@ToolArg(description="Namespace") String namespace, @ToolArg(description="Nome do pod") String pod) { k8s.pods().inNamespace(namespace).withName(pod).delete(); return "pod " + pod + " deletado"; } }
✨
O que o Quarkus faz por você
A extensão gera o schema JSON a partir da assinatura do método, expõe o endpoint SSE e responde a tools/list/tools/call. Você escreve só a lógica — a descrição do @Tool é o que o modelo lê para decidir usá-la.
Fechando o ciclo

Conecte e veja o agente agir

  • 🌐
    Seu servidor sobe com uma Route. Copie a URL do endpoint SSE (ex.: /mcp/sse).
  • 🔌
    No seu agente, ligue MCP e cole a URL. O agente faz o handshake e descobre suas 3 ferramentas.
  • 🗣️
    Peça em linguagem natural: "liste os pods do meu namespace", "mostre os logs do victim", "reinicie o victim matando o pod dele".
  • 👀
    Observe as tool calls aparecerem ao vivo — com argumentos e resultado. O agente escolheu, chamou e agiu.
🤖
Seu agente
toggle MCP ligado
🔗
MCP Client
handshake + tools/list
🧰
Seu MCP Server
listar · logs · matar
⛵
Seu namespace
pods de verdade
Bora construir

Do chat à ação

Quando o seu agente chamar uma ferramenta que você escreveu e um pod sumir do cluster de verdade, o MCP deixa de ser sigla e vira poder. Três métodos anotados — e o agente ganha mãos.

Autonomous Agents Workshop · BBDW 2026 Quarkus MCP · OpenShift · JSON-RPC
AGENT FABRIC
1 / 12