Uma das maiores ilusões quando falamos de agentes de IA é achar que o problema principal está no modelo.
Não está.
O modelo é importante, claro. Mas, em aplicações corporativas, o gargalo quase sempre aparece em outro lugar: como conectar o agente ao mundo real.
Um agente que só responde texto tem utilidade limitada. O valor começa a aparecer quando ele consegue consultar dados, chamar ferramentas, acionar sistemas, buscar informações e participar de fluxos reais da empresa. Só que essa conexão com ferramentas pode virar rapidamente uma bagunça: uma integração para cada API, um formato diferente para cada sistema, autenticações espalhadas, descrições inconsistentes, contratos frágeis e manutenção difícil.
Foi por isso que a chegada do Model Context Protocol, o MCP, ao Azure AI Foundry Agent Service em junho de 2025 chamou minha atenção. No resumo oficial de junho, a Microsoft destacou suporte a MCP no Agent Service, permitindo integrar agentes a backends usando chamadas padronizadas baseadas em JSON-RPC, reduzindo a necessidade de criar especificações OpenAPI customizadas para cada integração. (devblogs.microsoft.com)
Esse é o tipo de novidade que parece pequena para quem olha só a tela do produto, mas é grande para quem já tentou colocar agente em produção.
Porque agente sem ferramenta é conversa. Agente com ferramenta pode virar software.
O problema das ferramentas em agentes
Quando uma empresa começa a experimentar agentes, normalmente o primeiro protótipo é simples: o usuário pergunta, o modelo responde. Depois vem a próxima pergunta: “e se esse agente consultasse o CRM?”, “e se abrisse um chamado?”, “e se buscasse dados no ERP?”, “e se consultasse uma base de produtos?”, “e se acionasse um fluxo no sistema interno?”
É aí que a arquitetura começa a ficar séria.
Cada sistema tem seu próprio contrato. Cada API tem seu próprio jeito. Cada autenticação tem uma particularidade. Cada time escreve uma descrição diferente da ferramenta. Cada desenvolvedor cria um wrapper diferente. Depois de alguns meses, a empresa não tem uma plataforma de agentes. Tem um conjunto de integrações artesanais.
O MCP entra justamente nessa dor: padronizar a forma como agentes descobrem e usam ferramentas externas.
A própria documentação do Agent Service descreve que, em junho de 2025, a ferramenta MCP passou a permitir estender capacidades dos agentes conectando-os a ferramentas hospedadas em servidores MCP remotos. (learn.microsoft.com)
Para mim, esse é um avanço de arquitetura, não apenas de recurso.
O que é MCP, na prática?
MCP significa Model Context Protocol. A ideia é criar um padrão para conectar aplicações de IA a ferramentas, dados e sistemas externos.
Em vez de cada agente precisar conhecer uma integração específica de forma completamente customizada, o MCP funciona como uma camada padronizada entre o agente e o servidor que expõe ferramentas. O servidor MCP descreve o que está disponível, e o agente pode usar essas ferramentas dentro de um contrato mais consistente.
A Microsoft explica no resumo de junho que o MCP permite integrar qualquer backend por chamadas JSON-RPC padronizadas, evitando a necessidade de criar especificações OpenAPI customizadas para cada caso. (devblogs.microsoft.com)
Essa frase é importante porque toca em um ponto prático: o custo invisível da IA corporativa não está só no token. Está na manutenção da integração.
Se cada agente exige uma integração sob medida, sua arquitetura não escala.
Por que isso importa para o Azure AI Foundry?
O Azure AI Foundry Agent Service já vinha se consolidando como uma plataforma gerenciada para criar, publicar, escalar, rastrear e monitorar agentes. Em maio de 2025, o serviço entrou em GA, e em junho a Microsoft avançou na direção de ferramentas mais padronizadas e extensíveis com MCP. (learn.microsoft.com)
Isso importa porque o Foundry não quer ser apenas um lugar onde você conversa com modelos. Ele quer ser uma camada de construção de aplicações e agentes de IA.
E, para construir agentes úteis, você precisa de ferramentas.
Só que ferramenta sem padrão vira acoplamento. E acoplamento demais mata a evolução da plataforma.
O MCP ajuda a resolver exatamente essa tensão: dar mais capacidade para o agente sem transformar cada integração em um projeto isolado.
A diferença entre demo e arquitetura
Em uma demo, você pode criar uma função simples chamada get_order_status e mostrar o agente consultando um pedido. Fica bonito.
Em produção, a história é diferente.
Você precisa lidar com autenticação.
Precisa limitar permissão.
Precisa validar entrada.
Precisa tratar erro.
Precisa versionar contrato.
Precisa auditar chamada.
Precisa saber qual agente chamou qual ferramenta.
Precisa impedir que uma ferramenta seja usada fora do contexto correto.
Quando falamos de agentes conectados a sistemas reais, a pergunta não é apenas “funciona?”. A pergunta é: funciona com segurança, governança e manutenção?
É aqui que MCP começa a ter relevância. Ele não elimina a necessidade de arquitetura. Mas cria uma base melhor para que ferramentas sejam expostas e consumidas de forma mais padronizada.
Exemplo prático: agente de suporte técnico com MCP
Imagine um agente interno de suporte técnico para uma empresa que usa Azure.
A função dele é ajudar analistas a consultar documentação interna, verificar status de serviços, abrir tickets e sugerir próximos passos. Sem MCP, você provavelmente criaria uma integração customizada para cada ferramenta:
Uma função para consultar status.
Uma função para abrir ticket.
Uma função para buscar documentação.
Uma função para consultar inventário.
Uma função para acionar um workflow.
Cada uma com seu próprio wrapper, seu próprio padrão, sua própria descrição e seus próprios problemas de manutenção.
Com MCP, a lógica muda. Você pode expor um conjunto de ferramentas em um servidor MCP e permitir que o agente consuma essas capacidades de forma mais padronizada. O agente não precisa carregar toda a complexidade de cada backend. Ele passa a interagir com ferramentas descritas por um contrato comum.
O ganho não é só técnico. É operacional.
Quando a empresa cria um novo agente, ela pode reutilizar ferramentas já expostas. Quando uma ferramenta muda, o ajuste fica mais concentrado. Quando um time quer controlar governança, ele consegue pensar em catálogo de ferramentas, não em integrações espalhadas.
Como eu desenharia esse cenário
Eu separaria a arquitetura em cinco camadas.
A primeira camada seria o agente no Azure AI Foundry Agent Service. Ele entende a intenção do usuário, decide se precisa de ferramenta e responde com base no resultado.
A segunda camada seria o servidor MCP. Ele expõe ferramentas disponíveis para o agente, com contratos padronizados.
A terceira camada seria a camada de sistemas corporativos. Aqui ficam APIs internas, CRM, ERP, Service Desk, banco de dados, sistemas legados ou serviços Azure.
A quarta camada seria a camada de identidade e autorização. Essa camada define quem pode chamar o quê, com quais permissões e sob quais condições.
A quinta camada seria a camada de observabilidade e governança. Ela registra chamadas, erros, tempo de resposta, uso de ferramentas e comportamento do agente.
O erro seria colocar tudo direto no prompt ou direto no agente, como se o modelo tivesse que entender toda a empresa sozinho.
Um bom agente não precisa saber tudo. Ele precisa saber usar bem as ferramentas certas.
O que uma ferramenta MCP deveria ter
Se eu fosse expor ferramentas para agentes via MCP, eu não pensaria apenas no código da função. Eu definiria um padrão mínimo.
Toda ferramenta deveria ter uma descrição clara.
Deveria ter parâmetros bem definidos.
Deveria ter validação de entrada.
Deveria ter tratamento de erro previsível.
Deveria respeitar autorização.
Deveria ter logs.
Deveria ter limites de uso.
Deveria deixar claro quando não pode executar uma ação.
Isso parece básico, mas é onde muitos projetos quebram. Ferramenta mal descrita gera agente confuso. Ferramenta permissiva demais gera risco. Ferramenta sem log gera operação cega.
No mundo agentic, descrever bem uma ferramenta é parte da arquitetura.
Um exemplo de catálogo de ferramentas
Para um agente técnico interno, eu começaria com poucas ferramentas:
Tool: search_internal_docs
Purpose: Search approved internal technical documentation.
Risk: Low
Requires approval: No
Tool: check_service_status
Purpose: Check the status of selected internal systems or Azure services.
Risk: Medium
Requires approval: No
Tool: create_support_ticket
Purpose: Create a support ticket with summary, category and priority.
Risk: Medium
Requires approval: No, but requires user confirmation.
Tool: request_architecture_review
Purpose: Send a request for human review when the question involves production architecture, security or compliance.
Risk: Low
Requires approval: NoEsse tipo de catálogo ajuda a tirar o agente do improviso. Ele deixa claro o que existe, para que serve e qual risco está associado.
Eu não começaria expondo ferramenta para alterar configuração, remover recurso, aprovar compra, mudar política ou executar ação irreversível. Esse tipo de autonomia precisa vir depois, com muito mais controle.
MCP não substitui governança
Esse ponto é fundamental.
MCP padroniza conexão com ferramentas. Ele não resolve sozinho governança, segurança, permissão ou risco de negócio.
Se você expõe uma ferramenta perigosa para um agente, o MCP não transforma isso automaticamente em uma boa decisão. A arquitetura ainda precisa definir limites.
A pergunta certa é:
Quais ferramentas esse agente pode acessar?
Qual usuário está por trás da solicitação?
A ferramenta executa leitura ou escrita?
A ação exige confirmação?
Existe risco financeiro, jurídico ou operacional?
A chamada está sendo registrada?
Existe fallback humano?
Sem essas respostas, você só criou uma forma mais elegante de errar.
O papel do desenvolvedor muda
Com MCP, o desenvolvedor deixa de pensar apenas em “como eu faço o agente chamar esta API?” e passa a pensar em “como eu exponho uma capacidade reutilizável para agentes?”
Essa mudança é grande.
No modelo antigo, cada integração era quase um conector artesanal. No modelo mais maduro, você começa a criar uma camada de capacidades reutilizáveis: consultar pedido, buscar documento, abrir chamado, verificar estoque, validar política, gerar resumo, acionar workflow.
A empresa começa a construir um inventário de ferramentas agentic.
Isso é muito mais escalável do que deixar cada time criar sua própria integração.
O papel do arquiteto também muda
O arquiteto precisa olhar para MCP como parte de uma estratégia de plataforma.
Não é só uma feature. É uma forma de organizar como agentes se conectam ao ecossistema corporativo.
Eu olharia para três decisões:
1. Quais ferramentas devem virar capacidades compartilhadas?
Nem toda API precisa virar ferramenta para agente. Escolha as que têm uso recorrente e valor claro.
2. Quais ferramentas exigem controle mais forte?
Leitura é diferente de escrita. Consulta é diferente de ação. Recomendação é diferente de execução.
3. Como será feita a observabilidade?
Você precisa saber qual agente usou qual ferramenta, quando, com qual entrada e qual resultado.
Essa visão evita que MCP vire só mais uma camada técnica sem governança.
MCP e OpenAPI: competição ou complemento?
A Microsoft destacou em junho que o MCP ajuda a integrar backends com chamadas JSON-RPC padronizadas, reduzindo a necessidade de criar OpenAPI specs customizadas para cada integração. Isso não significa que OpenAPI deixa de existir ou perde valor. Significa que, para determinados cenários agentic, MCP pode ser um caminho mais natural de exposição de ferramentas. (devblogs.microsoft.com)
Eu vejo assim: OpenAPI continua excelente para expor e documentar APIs tradicionais. MCP aparece como uma camada mais adaptada à relação entre agentes e ferramentas.
A decisão não deve ser ideológica. Deve ser arquitetural.
Se a empresa já tem APIs bem documentadas, OpenAPI pode continuar fazendo sentido. Se a empresa quer criar um catálogo de ferramentas para agentes, MCP começa a ficar muito interessante.
O erro que eu evitaria
O erro seria olhar para MCP e pensar: “agora posso conectar o agente em tudo”.
Não. Não pode.
O que você deve pensar é: “agora tenho uma forma melhor de padronizar as ferramentas que realmente fazem sentido para agentes”.
Essa diferença é crítica.
Conectar tudo é ansiedade.
Conectar o necessário é arquitetura.
Um agente bom não é aquele que tem acesso a cem ferramentas. É aquele que tem acesso às ferramentas certas para cumprir uma missão bem definida.
Checklist para usar MCP com responsabilidade
Antes de expor uma ferramenta para um agente, eu passaria por este checklist:
A ferramenta resolve uma tarefa clara?
Ela tem descrição objetiva?
Os parâmetros são bem definidos?
Existe validação de entrada?
Existe controle de permissão?
A ferramenta executa leitura ou escrita?
A ação precisa de confirmação humana?
Os erros são tratados de forma previsível?
As chamadas são registradas?
Existe limite de uso?
O resultado é seguro para ser usado pelo modelo?
A ferramenta pode ser reutilizada por outros agentes?
Se a resposta para essas perguntas não está clara, a ferramenta ainda não está pronta para produção.
Minha leitura sobre junho de 2025
Junho de 2025 foi um mês importante porque reforçou que o Azure AI Foundry não estava evoluindo apenas em modelos. Ele estava evoluindo na camada de plataforma.
O resumo oficial de junho trouxe vários pontos: suporte a MCP no Agent Service, novos modelos como o3-pro, Sora e DeepSeek-R1, mudanças de plataforma com novo tipo de recurso unificado do Azure AI Foundry, gestão simplificada de API version com endpoints latest e preview, SDK unificado, extensão para VS Code e outras atualizações voltadas para desenvolvedores. (devblogs.microsoft.com)
Mas, para mim, o MCP é um dos temas mais importantes porque toca no coração da arquitetura de agentes: conexão com ferramentas.
Sem ferramentas, agentes ficam limitados.
Com ferramentas mal governadas, agentes ficam perigosos.
Com ferramentas padronizadas, agentes começam a ficar sustentáveis.
Conclusão
O MCP no Azure AI Foundry Agent Service representa uma evolução importante na forma de construir agentes corporativos.
A grande questão não é apenas “como faço meu agente chamar uma API?”. A questão agora é: “como organizo um ecossistema de ferramentas reutilizáveis, seguras e governáveis para agentes?”
Essa é a diferença entre uma demo e uma plataforma.
Na demo, o agente chama uma função e impressiona.
Na produção, o agente precisa chamar a ferramenta certa, com permissão correta, dentro do contexto certo, registrando o que fez e respeitando os limites do negócio.
É por isso que MCP importa.
Porque a próxima fase da IA corporativa não será vencida apenas por quem tiver o melhor modelo. Será vencida por quem conseguir conectar modelos, ferramentas, dados e governança de forma mais inteligente.
E, nesse ponto, o Azure AI Foundry começa a se posicionar não apenas como um lugar para criar agentes, mas como uma base para organizar uma verdadeira arquitetura agentic.
Seja o primeiro a comentar