O sistema central da empresa pode ter vinte anos, uma interface difícil e documentação incompleta — e ainda carregar regras sem as quais a operação para. Substituí-lo exige migração de dados, homologação, treinamento, convivência entre versões e risco de interromper processos que hoje funcionam. Não fazer nada também custa: cada novo agente, chatbot ou aplicativo cria sua própria integração e multiplica credenciais, testes e manutenção.
O Model Context Protocol, ou MCP, pode abrir um terceiro caminho: preservar o núcleo do legado e construir uma borda pequena, padronizada e governável para que aplicações de IA descubram e utilizem capacidades específicas. Em condições adequadas, essa é uma forma mais barata de começar porque reduz migração e evita refazer o mesmo conector para cada agente. Mas MCP não torna um sistema antigo seguro, compreensível ou integrável por decreto.
A ideia central
MCP não moderniza o legado inteiro. Ele pode modernizar a fronteira pela qual agentes encontram e usam suas capacidades.
O que MCP resolve — e o que ele não resolve
A especificação oficial do MCP define um protocolo aberto para conectar aplicações de IA a ferramentas, recursos e outros contextos. Um servidor publica capacidades com nomes, descrições e esquemas; um cliente descobre essas capacidades e chama a ferramenta escolhida. O legado pode continuar falando procedure, SOAP, arquivo, fila, API proprietária ou até interface gráfica. Um adaptador próximo a ele traduz esse mecanismo para ferramentas MCP estreitas.
Essa padronização resolve a conversa entre a aplicação de IA e a borda do sistema. Ela não descobre sozinha regras de negócio, corrige dados ruins, cria autorização, garante idempotência nem confirma que a ação teve efeito. Também não elimina o adaptador. O trabalho muda de “integrar cada agente ao legado” para “publicar uma vez capacidades que clientes compatíveis possam reutilizar”.
Por que o legado cria uma armadilha econômica
Legado não é apenas software velho. É software acoplado a pessoas, equipamentos, relatórios, fechamento financeiro e conhecimento que raramente está todo documentado. Uma migração ampla tenta mover muitas dependências ao mesmo tempo. Uma integração pontual parece menor, mas, repetida por cada canal e fornecedor de IA, cria uma segunda forma de dívida.
Um recorte público ajuda a dimensionar essa tensão. Em 2025, o Government Accountability Office dos Estados Unidos analisou 69 sistemas federais legados e selecionou 11 considerados mais críticos; oito usavam linguagens antigas, quatro tinham hardware ou software sem suporte e sete operavam com vulnerabilidades conhecidas. O governo federal informava destinar cerca de 80% de mais de US$ 100 bilhões anuais de TI à operação e manutenção de sistemas existentes. É um contexto governamental norte-americano, não uma média para empresas brasileiras, mas demonstra por que manter e substituir podem ser caros ao mesmo tempo.
MCP é atraente nesse intervalo porque permite aplicar uma estratégia de estrangulamento gradual: novas experiências consomem contratos modernos, enquanto o núcleo antigo continua respondendo até que haja justificativa para substituir uma parte. A economia potencial está em reduzir superfície e repetição, não em fingir que a dívida desapareceu.
De onde pode vir a economia com MCP
Uma adaptação, vários clientes
Sem uma fronteira comum, cada agente precisa aprender autenticação, formato, erro e operação do legado. Com MCP, um servidor pode publicar “consultar ordem”, “registrar inspeção” e “solicitar bloqueio” para mais de uma aplicação compatível. A equipe mantém a tradução perto do sistema e evita bibliotecas diferentes para cada chatbot, copiloto ou canal.
Migração seletiva, não big bang
A empresa começa com duas ou três capacidades de alto valor, sem migrar todo o banco, reproduzir cada tela ou redesenhar o processo completo. Quando o sistema de destino mudar, é possível preservar o contrato externo e trocar a implementação do adaptador. Essa estabilidade precisa ser projetada; renomear uma ferramenta ou mudar seu esquema continua sendo uma quebra de contrato.
Catálogo descobrível e esquema reutilizável
Ferramentas MCP declaram entrada e, quando disponível, saída estruturada. Isso reduz documentação paralela e permite que clientes descubram somente capacidades autorizadas. O benefício não é deixar o modelo experimentar livremente: é dar nomes de negócio e limites verificáveis ao que antes dependia de conhecimento tribal.
Governança compartilhada
Quando catálogo, identidade, política, execução e evidência são comuns, uma nova experiência não precisa reconstruir todos os controles. Essa é a diferença entre padronizar transporte e reduzir custo total. Um servidor MCP isolado, com credencial ampla e logs próprios, pode ser apenas mais uma ilha.
Quatro caminhos para colocar MCP diante de um legado
| Condição do legado | Adaptação mínima | Quando funciona bem | Cuidado principal |
|---|---|---|---|
| API ou serviço já existe | Servidor MCP traduz ferramentas para os contratos atuais | Operações estáveis, frequentes e documentadas | Não duplicar regra que já pertence à API |
| Procedure, serviço local ou programa de linha de comando | Adaptador interno expõe somente operações permitidas | Regra existente pode ser acionada sem acesso genérico | Isolar credencial, validar entrada e limitar recursos |
| Arquivo, lote ou fila | Ferramenta cria uma solicitação e devolve identificador para consulta | Processos assíncronos que não prometem resposta imediata | Mostrar recebido, processando, concluído e rejeitado corretamente |
| Somente interface gráfica | RPA controlado fica atrás de uma ferramenta MCP | Ponte temporária, baixo volume e consequência delimitada | Mudanças visuais, sessão, duplicidade e plano de substituição |
Em todos os caminhos, MCP é a interface para o cliente de IA, não necessariamente o protocolo usado pelo legado. Essa distinção permite pouca ou nenhuma migração do núcleo, mas sempre existe trabalho novo na borda. Se o sistema já oferece uma boa API OpenAPI e só haverá um consumidor, publicar MCP pode acrescentar uma camada sem economia. Compare em API, RPA ou integração direta antes de escolher o protocolo por entusiasmo.
Quando MCP tende a ser o caminho mais barato
- Reutilização real: dois ou mais agentes, canais ou produtos precisam das mesmas capacidades.
- Recorte pequeno: poucas operações explicam boa parte da dor, sem exigir reproduzir o sistema inteiro.
- Fronteira estável: há API, procedure, fila, arquivo ou ação de interface que pode receber um contrato claro.
- Núcleo difícil de mover: migrar dados e regras agora custa mais e oferece mais risco que adaptar a borda.
- Dono de manutenção: alguém responde por esquema, versão, credencial, disponibilidade e aposentadoria.
- Governança reutilizável: identidade, permissão, aprovação, custo e evidência não serão recriados em cada servidor.
A conta deve comparar custo total, não apenas dias até a demonstração. No caminho personalizado, some descoberta do legado, conector por cliente, autenticação, testes, observabilidade e manutenção de cada combinação. No caminho MCP, some descoberta, adaptador único, servidor, governança compartilhada, integração dos clientes e atualização de protocolo. A economia aparece quando o custo reaproveitado supera a nova camada.
Meça horas para publicar a primeira e a segunda capacidade, tempo para conectar um novo cliente, falhas por mudança do legado, incidentes de credencial, custo por execução concluída e quantidade de contratos duplicados. Sem esses números internos, “mais barato” é uma tese a testar, não um fato.
Quando MCP não é a salvação
- A empresa não conhece as regras que a operação precisa preservar.
- A única proposta é oferecer SQL, URL, shell ou navegação irrestrita ao modelo.
- O sistema apresenta vulnerabilidade, hardware sem suporte ou risco de continuidade que exige modernização estrutural.
- Uma API atual já atende com menor complexidade e não existe demanda de reutilização entre clientes de IA.
- A tarefa depende de transação longa e distribuída que o adaptador não consegue confirmar ou compensar.
- Ninguém manterá o servidor MCP, suas dependências, credenciais, versões e testes.
MCP tampouco é um congelador de dívida. Ele pode ganhar tempo para uma migração responsável, mas a empresa ainda precisa documentar destino e critério de aposentadoria do legado. Um adaptador temporário sem plano costuma se tornar permanente. O post sobre gateway privado sem acesso livre ao banco aprofunda como criar essa fronteira quando o sistema permanece dentro da rede.
O barato fica caro quando segurança e versões são ignoradas
A OWASP destaca riscos específicos do MCP: descrição de ferramenta maliciosa, troca posterior do esquema, colisão de nomes, credencial excessiva, repetição de mensagens e o problema do agente que usa o privilégio do servidor sem representar corretamente a pessoa. A recomendação inclui menor privilégio, esquemas estritos, revisão e fixação das definições, isolamento, aprovação para ações sensíveis e auditoria central.
Trate nome, descrição, anotação e retorno de um servidor externo como dados não confiáveis. Gere um fingerprint do catálogo, exija revisão administrativa para ferramentas novas ou alteradas e comece com escrita classificada como alto risco. Autorização do protocolo não substitui autorização de negócio: um token válido para acessar o servidor não prova que a pessoa pode bloquear um lote de outra empresa.
Versão também entra no orçamento. A revisão MCP 2026-07-28 tornou o núcleo sem sessão, acrescentou roteamento por cabeçalhos, cache do catálogo e reforços de autorização, mas trouxe mudanças incompatíveis e uma política formal de descontinuação. O projeto informa quase meio bilhão de downloads mensais somados nos SDKs Tier 1 e mais de um bilhão acumulado em TypeScript e Python; downloads não equivalem a empresas ou implantações maduras. O dado mostra atividade do ecossistema e, ao mesmo tempo, reforça a necessidade de fixar revisão, testar compatibilidade e planejar atualização.
Exemplo composto: modernizar a borda de um sistema de manutenção
Considere um exemplo composto e didático, sem representar cliente ou resultado medido da Uiless. Uma indústria usa há 24 anos um sistema de manutenção ligado a equipamentos e históricos que não podem ser migrados durante uma parada curta. Ele não possui API moderna, mas oferece uma procedure homologada para abrir ordem e uma exportação local para consultar ativo e pendências.
Um adaptador dentro da rede publica três ferramentas: consultar_ativo, abrir_ordem_inspecao e consultar_status_ordem. O esquema exige código do ativo, tipo permitido, descrição limitada e chave idempotente. Não existe “executar procedure”, “consultar banco” ou “abrir tela”. O servidor MCP traduz as três ferramentas para os mecanismos antigos e devolve identificador, estado e horário do sistema responsável.
A Uiless importa o catálogo, trata descrições remotas como não confiáveis e mantém as escritas bloqueadas até classificação administrativa. Uma técnica solicita por voz a inspeção; identidade, empresa, permissão e dados obrigatórios são verificados. A chamada percorre aprovação quando necessária, controle de custo, idempotência e evidência. O legado continua funcionando; a mudança ocorre na borda e na forma de acesso.
Se a empresa substituir o sistema no futuro, o novo adaptador pode preservar as três capacidades e alterar o destino por trás delas. O piloto compara tempo até a ordem válida, retrabalho, duplicidades, falhas de autenticação, disponibilidade e esforço para adicionar um segundo canal. O ganho virá da medição; não é garantido pelo nome do protocolo.
Um roteiro de baixo risco para provar a economia
- Escolha uma dor frequente e uma capacidade de leitura antes da escrita mais crítica.
- Identifique regra, fonte, dono, mecanismo suportado e forma de confirmar resultado.
- Defina ferramenta com nome de negócio, esquema estreito, saída estruturada e estados de erro.
- Mantenha credenciais e execução próximas do legado, preferencialmente numa fronteira privada.
- Fixe revisão do MCP e SDK, valide origem do servidor e gere fingerprint do catálogo.
- Classifique risco, configure permissão, aprovação, limite de custo e idempotência.
- Teste ambiguidade, duplicidade, timeout, retorno malformado, alteração de esquema e revogação.
- Conecte um segundo cliente ou canal para verificar se a prometida reutilização acontece.
- Compare custo total com API direta, gateway ou RPA e registre critério de continuidade.
O roteiro pode entrar num piloto de automação em 90 dias. Para não confundir conector com resultado, use também os oito critérios de uma boa automação.
Como a Uiless ajuda
Na arquitetura Uiless, MCP, OpenAPI, REST e gateway privado podem convergir para um contrato comum de ferramenta. A plataforma consegue conectar uma fonte MCP remota, descobrir seu catálogo e transformar cada capacidade em uma definição administrável. Anotações do servidor são apenas indícios: operações importadas sem classificação interna começam de forma conservadora, com escrita tratada como alto risco, sem repetição automática e dependente de revisão.
No sentido inverso, a Uiless pode disponibilizar por MCP somente as ferramentas e os recursos autorizados para aquela pessoa e empresa. Uma chamada de ferramenta não vai direto ao legado: percorre o mesmo caminho de validação, permissão, aprovação, billing, idempotência, execução e evidência usado pelos demais canais. App, voz, WhatsApp, Telegram ou outro cliente compatível não precisam reconstruir a integração.
A Uiless não transforma automaticamente qualquer sistema em servidor MCP e não elimina o trabalho de modelar a fronteira. Quando OpenAPI ou REST já resolvem melhor, eles podem continuar sendo o caminho. Quando o legado exige proximidade de rede, o gateway permanece adequado. O papel da plataforma é permitir que a empresa escolha o adaptador mais estreito e reutilize governança, experiência e evidência — o mecanismo que pode tornar MCP economicamente interessante sem uma migração ampla.
Comece pela metodologia Uiless de operação por intenção: escolha um resultado, publique a menor capacidade segura e prove o valor antes de ampliar o catálogo.
