No post anterior, argumentamos que escalar IA dentro de uma empresa é um problema operacional: como ferramentas e dados são expostos, controlados, observados e faturados conforme o uso se expande por equipes e ambientes.
Vivenciamos isso em primeira mão durante 2025 enquanto construíamos junto com parceiros de design que eram pioneiros em workflows agentic. Em quase todos os casos, o padrão era o mesmo: alguns provas de conceito promissoras, seguidas pela parte difícil—deployar agentes que fechem o loop e entreguem resultados confiáveis em sistemas reais. É aí que os gargalos apareciam repetidamente: proliferação de conexões, falta de observabilidade, permissões inconsistentes e custos crescentes sem atribuição.
Essas restrições nos impulsionaram em direção a infraestrutura de contexto: tratar o tráfego MCP como uma superfície de produção de primeira classe. Isso é o que a Malha MCP é. Originalmente a construímos como uma camada interna para deployar esses sistemas com clientes. Este lançamento transforma essa camada em um componente self-hosted e a compartilha com a comunidade open-source—porque muitas equipes de plataforma parecem estar esbarrando nos mesmos problemas.
Por que as equipes acabam pagando um "imposto de integração"
Uma vez que você vai além de alguns PoCs, você começa a pagar pelas integrações MCP em três lugares ao mesmo tempo:
- Tempo de engenharia: lógica de integração frágil e duplicada espalhada por bases de código
- Operações: debugging sem uma única fonte de verdade
- Risco + custo: políticas aplicadas inconsistentemente (ou não aplicadas), sem atribuição, guardrails fracos
Uma Malha MCP é nossa resposta para isso: um plano de controle self-hosted que fica entre seus apps/agentes e seus servidores MCP, para que você possa gerenciar o tráfego MCP como qualquer outra superfície de produção—com roteamento, controle de acesso, observabilidade e estratégias de runtime.
O que a Malha MCP é (e onde fica)
A Malha MCP fica entre suas aplicações (agentes, ferramentas internas, clientes IDE) e seus servidores MCP.
Seu código se integra com um endpoint. Atrás desse endpoint, a malha pode chamar qualquer servidor MCP—GitHub, Jira, bases de dados internas, ferramentas customizadas, até provedores LLM expostos como MCP—enquanto centraliza as preocupações que você não quer reimplementadas em cada app:
Roteamento + execução
qual MCP chamar, como autenticar, como fazer retry, como falhar
Aplicação de políticas
quem (equipe/usuário/agente) pode acessar quais ferramentas e dados
Observabilidade
logs, traces, latência, erros entre chamadas MCP e chamadas de modelo
Controles de custo + taxa
atribuição e guardrails aplicáveis. Em breve
Estratégias de runtime
diferentes formas de expor ferramentas e contexto dependendo das necessidades de latência/custo/precisão
Essa é a diferença entre "conectamos ferramentas a agentes" e "podemos operar o acesso a ferramentas em produção."
Primitivas centrais (do que é construída)
O que as equipes precisam conforme MCP entra em produção
Fase 1: Conectar & Debugar
Primeiro você precisa que funcione de ponta a ponta. A maioria das equipes faz isso com lógica de integração ad hoc. A malha se trata de tornar esse passo rápido sem criar proliferação de longo prazo.
Deploy em qualquer lugar
A malha é self-hosted por design com zero-config para setup local.
Outros setups típicos:
- Docker Compose (SQLite ou Postgres)
- Runtime Bun/Node
- Kubernetes via Helm
Consolidação de conexões (e tunneling em dev-time)
Em vez de gerenciar oito conexões de servidor MCP em seu cliente—cada uma com config e auth separadas—você configura um endpoint. Todo o tráfego MCP da sua organização flui por ele.
Também suportamos tunneling em dev-time (deco.host) para que você possa rodar e testar servidores MCP localmente durante o desenvolvimento sem publicá-los.
Fase 2: Controlar
Uma vez que funciona, precisa funcionar de forma confiável, segura e previsível.
É aqui que as equipes normalmente descobrem que não precisam apenas de "um agregador MCP"—elas precisam de um plano de controle.
Observabilidade
Sem observabilidade centralizada
- sem trilha de auditoria
- falhas difíceis de debugar
- capacidade limitada de atribuir latência/custos
- risco de compliance evitável
Com a malha
- logging unificado de chamadas de modelo e invocações de ferramentas MCP
- rastreamento de latência por provedor
- taxas de erro e traces entre workflows multi-etapas
Quando algo quebra, você pode ver a cadeia: qual chamada MCP falhou, quanto tempo levou, o que retornou e o que aconteceu depois.
Controle de Custo
Rastreamento de custo ao nível de token por equipe/usuário/agente/aplicação, além de guardrails como caps de orçamento e limites de taxa.
Governança & Segurança
Controle de acesso baseado em função ao nível de modelo, MCP e ferramenta. Políticas aplicadas no plano de controle, não duplicadas em apps. Logs de auditoria apropriados para ambientes regulados.
O objetivo é tornar "seguro por padrão" o caminho mais fácil.
Fase 3: Otimizar (estratégias de runtime como gateways)
Uma vez que agentes rodão em produção, um novo problema aparece: funcionam, mas ficam lentos e caros conforme as superfícies de ferramentas crescem.
O Problema da Descoberta de Ferramentas
A abordagem ingênua é descrever cada ferramenta para o modelo em cada chamada. Isso funciona com um conjunto pequeno de ferramentas. Quebra quando você tem dezenas de servidores MCP e centenas de ferramentas: o contexto cresce, a latência sobe e a seleção de ferramentas fica mais difícil.
Exemplo concreto: 50 MCPs × 10 ferramentas cada = 500 ferramentas. Mesmo que descrições sejam curtas, você pode gastar uma parte significativa da janela de contexto apenas listando capacidades—pagando em tokens e tempo, frequentemente com pior seleção de ferramentas.
Gateways: um endpoint, diferentes estratégias de exposição
Internamente, começamos a modelar "estratégias de runtime" como implementações de gateway.
Um gateway ainda te dá um endpoint (utilizável de Cursor, Claude Desktop, agentes internos, etc.), mas muda como ferramentas são expostas:
Modo contexto completo (passthrough)
expor tudo, sempre. Simples, determinístico, melhor para superfícies pequenas de ferramentas.
Seleção inteligente de ferramentas
uma abordagem em dois estágios que estreita o conjunto de ferramentas antes da execução.
Modo execução de código
em vez de descrever ferramentas em detalhe, deixe o modelo escrever código contra uma interface restrita e o execute em uma sandbox (útil para superfícies maiores e lógica multi-etapas).
Gateways são configuráveis e extensíveis. Você pode criar novos gateways, experimentar diferentes estratégias e adotar aquele que se encaixa em suas restrições de latência/custo/precisão.
Fase 4 — Compor & estender (de gateways a capacidades duráveis)
Com o tempo, as equipes param de pensar em agentes pontuais e começam a construir componentes reutilizáveis. Duas coisas importam aqui:
MCPs Virtuais: bundling e curadoria
Porque gateways podem escolher o que expor, eles também podem se tornar uma forma de curar e agrupar ferramentas de múltiplos servidores MCP em um único "MCP virtual."
Isso é útil mesmo antes de você ter um framework de app completo:
- agrupar as poucas ferramentas que um agente deveria ter (e nada mais)
- apresentar interfaces estáveis mesmo conforme servidores MCP subjacentes evoluem
- criar conjuntos de ferramentas construídos a propósito por equipe ou ambiente
Essa lógica de bundling/curadoria é também como pensamos sobre apps MCP (em breve): empacotando capacidades duráveis que podem ser compartilhadas entre equipes—e eventualmente distribuídas mais amplamente através de uma loja.
Bindings: manter apps estáveis enquanto ferramentas mudam
Em escala empresarial, ferramentas mudam constantemente—vendors, sistemas internos, schemas, propriedade. Se cada app está acoplado a uma implementação MCP específica, sua camada agentic fica frágil.
Bindings definem contratos para tipos de capacidades comuns (coleções, agentes, workflows), para que apps possam visar o contrato em vez do provedor. Troque o MCP atrás da interface, mantenha suas UIs e workflows intactos.
Bindings de coleção
uma interface padrão para "coisas que contêm outras coisas."
Bindings de agente
uma interface padrão para agentes IA, independente de provedor.
Bindings de workflow
uma interface padrão para orquestração determinística multi-ferramenta.
(Entraremos em detalhes sobre bindings de agente/workflow em um post futuro.)
Multi-tenancy
Com contratos e interfaces compartilhadas, o mesmo código de aplicação pode funcionar entre equipes com diferentes permissões e conjuntos de ferramentas—sem ramificar seu sistema em variantes por-equipe.
O caminho do meio: consolidar o que você deve, ficar flexível onde você pode
Há uma tensão que continuamos vendo: construir tudo você mesmo, ou integrar uma dúzia de ferramentas e viver com proliferação.
Nossa abordagem é centralizar a infraestrutura que você não deveria reconstruir repetidamente—conexões, governança, observabilidade, roteamento, controles de custo—enquanto mantém as bordas compostas. Quando um servidor MCP forte aparece (vendor, interno, open source), você pode adotá-lo. Quando você precisa de algo específico de domínio, pode construir. Quando implementações mudam, seus contratos podem manter-se estáveis.
A parte interessante é o que acontece com o tempo: seu investimento cresce em vez de fragmentar.
Roadmap do Produto
Disponível Agora (Q4 2025):
Chegando em Q1 2026:
- Fundação Studio: bindings para agentes, workflows, views
- Suporte a MCP App (MCPs virtuais com QuickJS)
- Histórico de versões para configs de malha
- Runtime de pacote NPM
- Visual workflow builder
- Carteira unificada: rastreamento de custo + analytics
- Seleção de runtime auto-otimizada
- Módulo pré-construído: gerador de blogpost
Feedback de nossos clientes e comunidade moldam este roadmap.
Comece agora
npx @decocms/meshPor que estamos começando aqui
A Malha MCP resolve os problemas imediatos de infraestrutura que as equipes enfrentam quando MCP entra em produção: proliferação, falta de visibilidade, políticas inconsistentes e custos sem atribuição.
Mais importante, ela torna o próximo passo prático: transformar configurações de agentes pontuais em capacidades reutilizáveis que podem ser empacotadas, governadas e compartilhadas—sem reescrever integrações a cada vez.
