Preview. O Azure Connector Namespace está em preview e sujeito aos Termos de Uso Suplementares para Previews do Microsoft Azure. Durante a preview, está disponível apenas em regiões Azure públicas, sem SLA.
TL;DR: O Azure Connector Namespace é um serviço de integração totalmente gerenciado que oferece conectores pré-construídos, triggers, actions e servidores MCP para ser consumido por apps em Azure Functions, Container Apps, App Service ou compute auto-hospedado. Diferente do Logic Apps, ele não exige um workflow engine. Em preview, sem SLA e com cobertura limitada de conectores, promete reduzir o custo operacional de integrações ao delegar autenticação, polling e retry ao namespace.
O imposto de integração que ninguém orça
No papel, conectar apps aos sistemas que o negócio realmente usa — SharePoint, Salesforce, SAP, Outlook — e voltar a construir funcionalidades parece simples. O que atrapalha raramente é a lógica de negócio. É o encanamento. Você escreve um cliente de API customizado para cada serviço, configura fluxos OAuth e fica de babá do refresh de token, adiciona políticas de retry, lida com throttling, faz paginação e mantém subscriptions de webhook. Nada disso é funcionalidade. Tudo fica com você.
Historicamente, se você queria que esse trabalho fosse feito por você, a resposta era um workflow engine. Isso é ótimo quando você quer um workflow — mas muitos apps só querem chamar uma action ou reagir a um evento a partir do código que já têm, rodando na computação que já usam. Essa lacuna é o que o Azure Connector Namespace preenche.
O que é o Azure Connector Namespace?
O Azure Connector Namespace é um serviço de integração totalmente gerenciado que hospeda um catálogo de conectores reutilizáveis e servidores MCP que seus apps consomem por meio de um modelo de programação consistente. Em vez de escrever e operar um cliente para cada sistema, você cria uma conexão uma vez e chama operações tipadas a partir do código. O namespace cuida da autenticação, rotação de credenciais, polling, entrega de webhooks, retries, throttling e tratamento de erros.
Vale dizer claramente, porque as pessoas perguntam: um connector namespace é independente do Azure Logic Apps. Ele não exige, usa ou muda nada no Logic Apps, e a galeria de conectores do Logic Apps continua funcionando separadamente para workflows. O Connector Namespace é o caminho de integração para computação que não roda em um workflow engine — suas Functions, Container Apps, App Service e serviços auto-hospedados.
Cada conector expõe três tipos de superfície por meio de um modelo de conexão compartilhado:
- Triggers — subscriptions de eventos que seu app registra (um novo e-mail chega, um registro é atualizado, um arquivo cai em uma pasta).
- Actions — operações que seu app chama (enviar uma mensagem, ler uma linha, fazer upload de um arquivo).
- AI agent tools — as mesmas operações, expostas a agents e Copilot por meio de servidores MCP.
Você chama tudo isso a partir de SDKs fortemente tipados para C# (Azure.Connectors.Sdk), Node.js (@azure/connectors) e Python (azure-connectors) — ou via HTTP puro se um SDK tipado não for adequado.
Os blocos de construção
Cinco conceitos e você tem o modelo completo:
| Conceito | O que é |
|---|---|
| Connector namespace | O recurso Azure que hospeda o runtime do conector — carrega e executa operações, mantém estado da conexão e credenciais, faz polling em sistemas de origem, despacha eventos de webhook e aplica políticas de retry e diagnóstico. Crie-o pelo portal Azure, ARM/Bicep ou CLI. |
| Connector | Um componente pré-construído para um serviço (SharePoint, Salesforce, SAP, Outlook). Abstrai a API subjacente, protocolo de autenticação, paginação e comportamento de retry para que seu código fique na lógica de negócio. |
| Connection | Um binding autenticado e configurado para uma conta ou tenant. Conexões são reutilizáveis — vários apps e conectores podem compartilhar uma. Tipos de autenticação: OAuth, API key e Basic. |
| MCP server | Um recurso de primeira classe que expõe ferramentas para agentes de IA pelo Model Context Protocol. Disponível nos sabores managed e hosted (mais abaixo). |
| Connector SDKs | Clientes fortemente tipados para C#, Node.js e Python com o mesmo catálogo, modelo de conexão, telemetria e semântica de retry. Ou chame conectores via HTTP. |
O que você pode fazer com ele?
O objetivo de tudo isso são os cenários que ele desbloqueia. Alguns que mostram o alcance:
| Cenário | Como fica |
|---|---|
| Processar documentos e conteúdo | Uma Azure Function usa operações do conector SharePoint para detectar arquivos novos ou atualizados, processá-los e escrever resultados de volta no SharePoint. |
| Monitorar eventos de serviços externos | Um Azure Container App usa um trigger do Salesforce para receber eventos sobre novos leads conforme são criados. |
| Automatizar produtividade | Um app Node.js usa operações do Outlook para ler e enviar e-mails — reutilizando uma conexão que outro app já possui. |
| Fundamentar cargas de IA e agentes | Um serviço Python chama actions do conector para enriquecer a saída do modelo com dados de sistemas de negócio. |
| Reutilizar código de app existente | Serviços ASP.NET, Node.js e Python usam integrações gerenciadas sem workflow engine no caminho da chamada. |
| Publicar conectores para agentes | Transforme qualquer conector em um servidor MCP em um passo para que Copilot e outros agentes possam chamá-lo como ferramenta. |
Conexões: autentique uma vez, reutilize em todo lugar
As conexões são onde o ecossistema de conectores do Logic Apps compensa. Você tem o mesmo catálogo amplo de serviços Azure first-party e SaaS populares — construído sobre anos de investimento em conectores — sem trazer um workflow engine junto. Você cria uma conexão para um serviço, autentica uma vez, e qualquer número de apps e conectores pode reutilizá-la.
Criar uma é deliberadamente simples, que é a ideia:
- No portal Connector Namespaces (connectors.azure.com), abra seu namespace e selecione Connections > Create connection.
- Encontre e selecione o conector — por exemplo, Office 365 Outlook.
- Dê um nome claro e específico à conexão para facilitar a escolha depois.
- Faça login para autorizar e complete quaisquer etapas extras que o serviço exigir.
- Confirme que a conexão aparece como saudável na página Overview — agora ela está pronta para seus apps usarem.
Os tipos de autenticação suportados hoje são OAuth, API key e Basic. E como o namespace armazena e rotaciona as credenciais, seu app nunca toca em um secret bruto.
Triggers: entregue eventos para a computação que você já executa
Um trigger é uma subscription de evento que seu app registra em um conector — novo e-mail, registro atualizado, novo arquivo. Quando o sistema de origem levanta esse evento, o namespace entrega o payload para a sua computação. E ele faz a parte difícil: gerencia schedules de polling e registro de webhooks baseado no que o serviço subjacente suporta, para que você não precise manter infraestrutura de subscription.
Seu app pode receber esses eventos rodando em:
- Azure Container Apps Sandboxes
- Azure Functions
- HTTP direto — App Services ou ASP.NET, Node.js ou Python auto-hospedados no AKS ou VMs, através do mesmo connector namespace.
Dois detalhes que importam na prática: um trigger é definido independentemente de qualquer app específico, e vários apps podem se inscrever no mesmo evento de trigger pela mesma conexão. Actions, por outro lado, rodam sincronamente quando seu app as chama; a entrega de triggers usa webhooks ou subscriptions baseadas em pull, dependendo do conector e serviço de origem.
Você pode saber mais sobre como usar o Connectors SDK para injetar conectores no Azure Functions aqui.
Servidores MCP: transforme conectores em ferramentas para agentes
Esta é a parte que mais me empolga. Um servidor MCP no seu namespace expõe ferramentas que agentes de IA — Copilot, agentes customizados, qualquer cliente compatível com MCP — podem descobrir e chamar, usando o mesmo modelo de conexão que todo o resto. É assim que você coloca seus sistemas de linha de negócio diretamente na frente de um agente sem escrever wrappers de ferramentas ou levantar hosting. Existem duas formas de obter um.
Servidores MCP gerenciados (Managed)
Pegue qualquer conector no seu namespace e publique-o como um servidor MCP em um único passo. O namespace constrói e configura o servidor — definições de ferramenta, lifecycle, runtime — e a única coisa que você faz é autenticar a conexão subjacente. Se você consegue criar uma conexão, você consegue dar a um agente uma ferramenta.
Servidores MCP hospedados (Hosted)
Às vezes você quer um servidor pronto em vez de um projetado a partir de um conector. Servidores MCP hospedados são imagens pré-construídas de um catálogo curado que o namespace executa em computação dedicada provisionada para você. Você possui a configuração; a plataforma cuida de hosting, scaling, networking, lifecycle, dependências, health monitoring e credenciais. Quando você implanta um, o namespace puxa a imagem, provisiona o runtime com sua configuração e expõe um endpoint MCP seguro ao qual agentes podem se conectar.
O catálogo curado durante a preview inclui:
- Playwright — ferramentas de automação de navegador para navegação, screenshots e interação com páginas.
- Azure SQL — operações SQL expostas como ferramentas MCP via Data API Builder, com abstração de entidades, RBAC e caching para que agentes trabalhem através de um contrato controlado e seguro.
É um conjunto deliberadamente curado hoje, e se expande ao longo do tempo com base na demanda. Você pode saber mais sobre Servidores MCP Hospedados aqui.
Como os agentes autenticam
Servidores MCP hospedados têm duas fronteiras de auth:
- Inbound (cliente para servidor) — OAuth com Microsoft Entra ID. Conexões do GitHub Copilot no VS Code funcionam out-of-the-box; outros clientes MCP precisam de um pouco mais de configuração.
- Outbound (servidor para sistema downstream) — ou uma managed identity atribuída ao namespace, ou on-behalf-of (OBO) usando a identidade do usuário chamador para acesso delegado.
Como tudo se encaixa
De ponta a ponta, o fluxo para conectores é curto:
- Crie um recurso connector namespace em sua subscription.
- Crie uma ou mais conexões para os serviços desejados — por exemplo, uma conexão OAuth para Microsoft 365.
- Seu app — em Functions, Container Apps, App Service ou compute auto-hospedado — referencia o namespace e a conexão através de um Connector SDK, então se inscreve em triggers ou chama actions.
- O namespace lida com autenticação, assinatura de requisições, polling, subscription de webhook e retries. Seu app recebe respostas tipadas e payloads de eventos.
Para servidores MCP, é a mesma forma: crie o namespace, adicione um servidor managed ou hosted do catálogo, autentique a conexão subjacente, e agentes podem encontrar o servidor, ler seu catálogo de ferramentas e invocar tools.
Onde você pode executar
- Compute Azure — App Service, Container Apps e Functions podem consumir operações de conector.
- Auto-hospedado — qualquer serviço auto-hospedado também funciona: ASP.NET, Node.js ou Python no AKS ou Azure VMs.
- Diretamente em agentes — extensões do Copilot e clientes compatíveis com MCP chamam ferramentas em servidores MCP dentro do seu namespace sem passar por uma camada de computação separada; o namespace fornece a computação que executa os servidores.
Segurança e governança, por padrão
- Credenciais ficam com o namespace — ele as armazena, gerencia e rotaciona; seu app nunca lida com secrets brutos.
- Isolamento de rede — restrinja o acesso com integração de rede virtual e private endpoints.
- RBAC — controle quem pode criar conexões, registrar triggers e invocar actions.
- Observability — logs de diagnóstico e IDs de correlação fluem para o Azure Monitor para tracing de ponta a ponta entre o namespace e sua computação.
Antes de construir: realidades da preview
Prefiro que você entre de olhos abertos. Enquanto o Connector Namespace estiver em preview, tenha isso em mente:
| Consideração | O que esperar |
|---|---|
| Sem SLA | Não recomendado para workloads de produção durante a preview. |
| Disponibilidade de região | Regiões limitadas hoje; a lista se expande ao longo do tempo. |
| Cobertura de conectores | Conectores de alto uso e padrão primeiro; conectores enterprise como SAP, IBM MQ e Oracle Database seguem em waves posteriores. |
| Identidade | Conexões com API key e OAuth agora; managed identity para conexões virá depois (e chega antes para servidores MCP selecionados). |
| Versionamento | Versões do SDK e do runtime do namespace são pareadas durante a preview — espere breaking changes entre milestones. |
| Precificação | O modelo de preços não está finalizado; a forma de medição pode mudar antes do GA. |
Experimente e nos dê feedback
Se você já entregou uma integração e depois passou o trimestre seguinte mantendo o encanamento, isso é para você. A preview está aberta: crie um namespace pelo portal Azure, configure uma conexão em connectors.azure.com, e chame sua primeira action ou publique seu primeiro servidor MCP. É fácil começar por aqui:
Saiba mais:
- O que é Azure Connector Namespace?
- Quickstart: Criar e gerenciar connector namespaces
- Criar conexões reutilizáveis em connector namespaces
- Hosted MCP servers no Azure Connector Namespace
Postagens relacionadas:
Repositórios de exemplos:
Esta é uma preview, o que significa que seu feedback genuinamente molda para onde ela vai — quais conectores vêm a seguir, quais servidores MCP entram no catálogo, onde estão as arestas. Leve issues, feature requests e feedback para a página do GitHub. Eu leio. Vamos construir a camada de integração que você realmente quer usar.
Perguntas Frequentes
-
Como o Azure Connector Namespace se diferencia do Azure Logic Apps?
O Connector Namespace é independente do Logic Apps. Ele não requer nem altera nada no Logic Apps; é voltado para computação que não roda em um workflow engine, como Functions, Container Apps e App Service. Enquanto o Logic Apps foca em orquestração de workflows, o Connector Namespace oferece chamadas diretas e reação a eventos via triggers e actions. -
Posso usar o Azure Connector Namespace em produção?
O serviço está em preview e não possui SLA. A Microsoft recomenda não utilizá-lo em workloads de produção. Além disso, a disponibilidade de regiões é limitada, e o modelo de preços ainda não foi finalizado. Versões do SDK e runtime podem ter breaking changes entre milestones. -
Quais conectores estão disponíveis no preview?
O preview oferece conectores de alto uso e padrão primeiro, como SharePoint, Salesforce, Outlook e serviços Azure first-party. Conectores enterprise como SAP, IBM MQ e Oracle Database serão adicionados em waves posteriores. A lista completa pode ser consultada no portal connectors.azure.com. -
Como funciona a autenticação para os conectores?
O namespace gerencia as credenciais de forma centralizada, suportando OAuth, API key e Basic authentication. A aplicação nunca lida com secrets diretamente. Para conexões futuras, está previsto suporte a managed identity. Nos servidores MCP, a autenticação inbound usa OAuth com Microsoft Entra ID, e outbound pode usar managed identity ou OBO. -
Como posso expor conectores como ferramentas para agentes de IA?
Cada connector pode ser publicado como um servidor MCP (Model Context Protocol) em um único passo. Existem duas formas: managed MCP servers (criados a partir de um conector existente) e hosted MCP servers (imagens pré-construídas no catálogo, como Playwright e Azure SQL). Agentes como Copilot podem descobrir e invocar essas ferramentas via MCP.
Artigo originalmente publicado por WSilveira em Azure Updates - Latest from Azure Charts.
