Nos últimos dois meses, três peças importantes entraram no chão da fábrica enterprise. Em março, a Google liberou o MCP Toolbox for Databases SDK em Java. Nesta semana, a ServiceNow tornou GA o seu MCP (Model Context Protocol) Server, anunciado como Action Fabric no Knowledge 2026 em 5 de maio, com Now Assist Skills expostas como tools. E a Jama disponibilizou o Jama Connect MCP Server. Em paralelo, e quase em silêncio, a Quarkiverse foi shippando, na linha 1.9.x do Quarkus LangChain4j, três extensões que mudam o nível do que um arquiteto Java consegue entregar em cima desse novo encanamento: quarkus-langchain4j-mcp, quarkus-langchain4j-skills e quarkus-langchain4j-neo4j.
A combinação dessas duas ondas (mercado empurrando MCP para o status de protocolo de plataforma; Quarkiverse fechando o stack Java com extensões dedicadas) é o sinal mais claro de que agente em Java deixou de ser exercício acadêmico e virou decisão de arquitetura.
O cenário: MCP virou peça de infraestrutura, não experimento
Quem acompanha o ecossistema Java no último ano e meio viu MCP nascer como mais uma sigla na lista. Hoje a foto é outra. A ServiceNow descreve o seu próprio MCP Server como peça nativa do Now Assist, com OAuth 2.1 com PKCE, escopo mínimo de permissão e consentimento human-in-the-loop. A Jama publicou o seu MCP Server como porta de entrada oficial para integração de agentes externos. A Google entregou o MCP Toolbox em Java, ao lado dos clientes Python e JS que já existiam.
Quando vendor dessa categoria começa a tratar MCP como GA e não como preview, o trabalho do arquiteto muda. Não é mais “vou testar essa novidade num PoC”; é “como eu integro o servidor MCP do meu vendor de processo no agente que roda no meu cluster, com a observabilidade, o modelo de identidade e o pipeline de build que eu já tenho em produção”.
E é exatamente esse vão (entre o servidor MCP que o vendor entrega e o agente que precisa rodar dentro do meu ambiente, no meu runtime, sob minhas regras) que a linha 1.9.x do Quarkus LangChain4j veio fechar.
Deep dive: o que as três extensões entregam de fato
A primeira coisa que importa é entender o que cada extensão faz, e por que elas não são “syntactic sugar” sobre a lib core do LangChain4j.
A extensão quarkus-langchain4j-mcp é um cliente MCP first-class, configurável via application.properties, com suporte a STDIO, HTTP/SSE (legacy) e Streamable HTTP (recomendado). Em vez de instanciar McpClient na mão e amarrar lifecycle, você declara o servidor MCP como configuração:
quarkus.langchain4j.openai.api-key=${OPENAI_API_KEY}
# Servidor MCP local via STDIO
quarkus.langchain4j.mcp.filesystem.transport-type=stdio
quarkus.langchain4j.mcp.filesystem.command=npm,exec,@modelcontextprotocol/server-filesystem,/srv/docs
# Servidor MCP remoto via Streamable HTTP
quarkus.langchain4j.mcp.servicenow.transport-type=streamable-http
quarkus.langchain4j.mcp.servicenow.url=https://mcp.servicenow.example.com/mcp
E na hora de plugar isso num AiService, a integração é declarativa. A extensão expõe a anotação @McpToolBox, que faz o agente descobrir e usar dinamicamente as tools do servidor MCP indicado:
import io.quarkiverse.langchain4j.RegisterAiService;
import io.quarkiverse.langchain4j.mcp.runtime.McpToolBox;
import dev.langchain4j.service.SystemMessage;
import dev.langchain4j.service.UserMessage;
@RegisterAiService
public interface IncidentAssistant {
@SystemMessage("""
Você é um assistente de operações que ajuda
SREs a investigar incidentes em ambiente enterprise.
""")
@McpToolBox({"servicenow", "filesystem"})
String investigar(@UserMessage String pergunta);
}
Pouquíssimo código. E vem com Dev Services, hot reload, integração com quarkus.tls.*, e binding nativo para AOT compilation. Esse é o ponto que não aparece quando você compara só os snippets.
A extensão quarkus-langchain4j-skills é a outra peça que mudou o jogo. Ela carrega skills definidas em diretórios (Markdown com YAML front matter, seguindo a Agent Skills specification: formato SKILL.md aberto, originado na Anthropic e hoje suportado por múltiplos agentes) e registra um SkillsToolProvider como CDI bean, que injeta as skills carregadas no system message do agente. Você anota o AiService com o provider correto e pronto:
import io.quarkiverse.langchain4j.RegisterAiService;
import io.quarkiverse.langchain4j.skills.SkillsSystemMessageProvider;
@RegisterAiService(systemMessageProviderSupplier = SkillsSystemMessageProvider.class)
public interface IncidentAnalyst {
String analisar(String contexto);
}
quarkus.langchain4j.skills.directories=skills,classpath:other-skills
A primeira release dessa extensão suporta apenas o modo “tool” das skills, mas já é suficiente para padronizar como o time descreve playbooks de operação fora do código Java. Skill virou artefato de configuração, versionado no mesmo repositório do agente, revisado em PR.
A terceira peça é quarkus-langchain4j-neo4j, que entrega o embedding store em cima do driver oficial Quarkus Neo4j. Para times que já usam Neo4j para grafo de domínio, é a porta de entrada para hybrid retrieval (vetor + relacionamento) sem precisar montar uma stack paralela só para RAG. A extensão herda Dev Services do quarkus-neo4j, então o ambiente local sobe sozinho.
Aplicação prática: o que muda em produção
Em ambiente enterprise, a diferença entre “tem AI no código” e “AI roda em produção, no meu SLA, dentro do meu controle” é quase sempre o resto da plataforma. Native compilation, observabilidade, identidade, build pipeline, FinOps. E é aí que o stack Quarkus + LangChain4j vira recomendação, não preferência estética.
Quando o agente roda em Quarkus, ele herda automaticamente os adaptadores de Micrometer, OpenTelemetry e o tracing distribuído que a plataforma já tem para REST e mensageria. A invocação da tool MCP entra no mesmo trace do request HTTP que disparou o agente. O fact-check disso é trivial: a extensão é uma extensão Quarkus padrão, registrada no CDI, e respeita os interceptadores que já estão instalados.
Em compilação nativa, o stack inteiro é suportado. Isso muda o cálculo de custo: agente AI em container serverless ou cold-start crítico pode rodar como Native Image, com binário pequeno e arranque rápido, sem perder o cliente MCP, o RAG ou o serviço CDI. Ainda dá trabalho cuidar de reachability metadata para libs que fazem reflection pesada, mas o stack Quarkus LangChain4j não te empurra nesse pântano por padrão.
E o ponto que mais pesa em conversa de procurement: Java enterprise não é o ambiente onde “tem que rodar um sidecar Python para AI”. O sidecar Python é elegante para prototipar, e nada impede de rodar agentes Python em paralelo. O que é difícil de defender ainda hoje é manter a parte enterprise do agente (fluxo, identidade, observabilidade, deploy) num runtime que não é o mesmo do resto da casa.
Trade-offs reais
Vou ser direto sobre os trade-offs reais, porque baboseira de “Java é melhor” não ajuda ninguém.
O ecossistema Python continua tendo mais integrações de terceiros prontas. Frameworks como LangGraph e CrewAI têm exemplos para quase qualquer cenário, do DevDay para o repositório de exemplo.
Vale notar também que essas três extensões (mcp, skills, neo4j) ainda estão classificadas como “preview” no catálogo oficial do Quarkus. API estável o suficiente para apostar, mas pode mudar entre releases. Considere isso no roadmap, principalmente para quem vai pinar versão de plataforma corporativa.
Por outro lado, em quase todos os outros eixos relevantes para empresa que tem Java em produção em escala (compliance, identidade, observabilidade, reuso de pipeline de build, FinOps de runtime, integração com IDP/IAM corporativo) o caminho Quarkus LangChain4j economiza meses de plataforma. E a partir do momento em que MCP virou a fronteira de integração com vendor enterprise, o “ecossistema Python tem mais exemplos” deixou de ser o argumento dominante. O servidor MCP que a ServiceNow ou a Jama publicam é o mesmo para qualquer cliente conforme a spec. O cliente Java consome com o mesmo nível de fidelidade.
Recomendação prática: se o seu time tem Java rodando em produção e está olhando para colocar agente no produto, comece pelo stack Quarkus LangChain4j. Use Python para experimento ou ETL de embedding. Não duplique plataforma por moda.
Conclusão
A foto ficou clara: MCP é o protocolo de integração padrão entre agente e vendor enterprise, e o stack Quarkus + LangChain4j fechou o lado Java desse encanamento com três extensões que tiram trabalho de plataforma do caminho. Cliente MCP declarativo via application.properties, skills carregadas como artefato de configuração, embedding store em Neo4j com Dev Services. Tudo em cima do runtime que sua empresa já roda.
Se você é Staff Engineer ou arquiteto e ainda está convencendo o seu time de que vale a pena experimentar agente em Java, esta semana é o melhor momento para abrir o repositório e subir o primeiro @McpToolBox apontando para um servidor MCP local. O trabalho duro de plataforma não está mais lá. Está na decisão de fazer.
E se você quer a minha ajuda pessoal para aprender a colocar tudo isso em aplicações Java com clareza arquitetural, observabilidade e responsabilidade técnica, o Método Java AI Specialist é pra você: https://eldermoraes.ai
