A maioria das ferramentas de automação sem código-incluindo N8N-entrou naturalmente no mercado de agentes de IA, o que faz todo o sentido. No entanto, desde que o envolvimento do Openai provocou um aumento significativo na adoção, o MCP foi posicionado como a abordagem superior para a construção de agentes de IA.
O MCP é uma grande iniciativa, mas também imaturo e, portanto, propensa a birras. Basta olhar para a autorização e a segurança geral sem brilho da primeira iteração do protocolo (novembro de 2024 – março de 2025). A imaturidade do protocolo e a adoção realmente rápida do mercado nos proporcionam uma experiência irregular e inconsistente.
Aqui estão algumas conversas do MCP que espero em um futuro próximo:
- A segurança se tornará de responsabilidade dos fornecedores
- Modelo de segurança da cadeia de suprimentos
- Gerenciamento de custos
- Travessuras de compatibilidade com versões anteriores
- Orquestrando agentes MCP
Agora vamos mergulhar em cada um desses desafios e explorar o que eles significam para as equipes, considerando o MCP em ambientes de produção!
A segurança é de responsabilidade dos fornecedores
Os fornecedores estão expondo seus produtos a usuários finais, oferecendo seus próprios servidores MCP. Isso significa que os usuários podem interagir com o produto via LLM. Seja qual for a maneira de girar isso, é responsabilidade do fornecedor aplicar o acesso seguro de terceiros ao seu produto. Nesse caso, a segurança deve ser implementada no nível do servidor.
Então, os fornecedores agora se preocupam com a segurança no nível do MCP? Não! Como o Equixly pessoal encontrado:
- Vulnerabilidades de injeção de comando: 43% das implementações testadas continham falhas de injeção de comando
- Arquivo de travessia/arbitrário de travessia de caminho Leia: 22% permitiu acessar arquivos fora dos diretórios pretendidos
- Vulnerabilidades do SSRF: 30% permitiu buscar URL irrestrito
Eu faço alguns pontos abaixo sobre compatibilidade com versões anteriores, o que significa que a implementação de segurança no próprio servidor MCP pode exigir revisitar constante à medida que o protocolo evolui. Uma opção é implementar a segurança em uma camada de proxy, como em um API Gateway conforme sugerido pelo Solo.io CTO, embora sugerindo ser obviamente tendencioso.
É muito engraçado injetar um gateway da API entre os recursos do MCP quando o objetivo era mais não confiar no APIS!
O que esperamos:
A aplicação da segurança pode impedir a facilidade de uso do MCP até o ponto em que não será viável usá -lo. Se as políticas de segurança restringirem os fluxos de trabalho do agente de fazer sua coisa autônoma, também podemos derrubar os servidores MCP.
A segurança da cadeia de suprimentos de modelo se torna cada vez mais importante
Vamos supor que você tenha um usuário genuíno, mas comprometido. Eles provavelmente satisfaziam todas as condições de autenticação e autorização, mas o modelo que eles usam está contaminado. Como fazer backdoor grandes modelos de idiomas Mostra um exemplo de como um modelo poluído pode incluir um script malicioso.
Se você se lembra do XZ Backdoor, um colaborador construiu um perfil confiável ao longo de dois anos e, em seguida, implementou gradualmente o backdoor na ferramenta XZ Utils. Isso pode muito bem acontecer com o Open Source LLMS.
O que esperamos:
Esperamos aplicação formal de modelos aprovados ao acessar servidores MCP. Outras abordagens podem implementar alguns algoritmos de detecção para as respostas enviadas pelo modelo.
Gerenciamento de custos
Os tokens ditam como o projeto de lei para APIs genai é calculado. Então, temos duas oportunidades para o agente consumir seus custos:
- O agente é terrivelmente ineficiente em escrever uma solicitação única e eficaz, especialmente para modelos de raciocínio.
- Puxando grandes quantidades de dados consumem o contexto.
O diagrama abaixo é uma ótima representação do primeiro ponto.
Para gerenciar o custo, você deve otimizar a API para uso com o MCP. Este artigo faz um ótimo trabalho ao explicar como fazer isso. Não sou um engenheiro de API (e não sei como codificar), então estou sendo transparente e dizendo que pedi a Claude para reescrever os exemplos usando terminologia genérica em vez da API do parque temático do artigo.
- Dados de API de pré-processo e estrutura para ajustar melhor as consultas do modelo: Em vez de expor dados brutos ou profundamente aninhados, reestruture e simplifique as respostas da API para facilitar o LLM para extrair informações relevantes rapidamente. Achatar ou inverter a hierarquia de dados reduz a contagem de token e a complexidade da análise durante a inferência.
- Filtre os dados o mais próximo possível da fonte para minimizar o tamanho da carga útil: Em vez de devolver grandes conjuntos de dados e deixar o LLM examiná -los, implemente métodos de API que permitam filtragem precisa com base nos parâmetros de entrada, retornando apenas as informações mínimas necessárias para a tarefa em questão.
- Remova pontos de extremidade redundantes ou excessivamente amplos para orientar o LLM em direção a interações otimizadas: Poda ou desative os métodos de API genéricos que retornam dados a granel ou não filtrados, mesmo que pareçam convenientes. Isso impede que o LLM faça chamadas ineficientes que inflem o uso do token e garante que ele use consistentemente os caminhos mais eficientes que você projetou.
O que esperamos:
Para que o MCP seja financeiramente viável, todos os provedores de servidores precisam otimizar seu uso da API. No geral, o MCP ainda é um invólucro de API.
Alta adoção e travessuras de compatibilidade com versões anteriores
Com todo mundo pulando na onda enquanto o protocolo está em sua infância, espero o seguinte:
- Muitos casos e vulnerabilidades do mundo real
- Muitas discussões sobre melhorias e desenvolvimentos
- Muitos lançamentos de recursos de RIP-e RIP-e
Espere gerenciamento constante e consistente da sua infraestrutura MCP.
Por exemplo, Substituindo HTTP+SSE por novo transporte “Streamable HTTP” Introduz o transporte HTTP transmissível para o MCP, abordando as principais limitações do transporte HTTP+SSE atual. Esta abordagem é declarada para ter compatibilidade com versões anteriores. Mas to Manter compatibilidade com versões anteriores Com o transporte HTTP+SSE depreciado, clientes e servidores podem tomar as seguintes medidas:
Servidores que suportam clientes legados:
- Continue hospedando o SSE do antigo transporte e poste pontos de extremidade ao lado do novo “MCP Endpoint” definido para o transporte HTTP transmissível.
- Como alternativa, mescla o antigo ponto final do post com o novo ponto de extremidade do MCP, embora isso possa introduzir complexidade desnecessária.
Clientes que suportam servidores legados:
- Aceite os URLs do servidor MCP fornecidos pelo usuário, que podem apontar para servidores usando o transporte antigo ou novo.
- Tente enviar um post inicializerequest para o URL do servidor, incluindo o cabeçalho aceita.
O que esperamos:
O MCP requer gerenciamento contínuo, não apenas para lidar com a segurança, mas para lidar com a própria infraestrutura. Isso exigirá processos dedicados, fluxos de trabalho e talvez uma infraestrutura de IA OPS.
Orquestrando agentes MCP
Os MCPs são ótimos para consultas de plataforma única, como a extração de transcrições de vídeo, mas quebram para fluxos de trabalho de IA complexos e com várias fontes. Você só pode usar um MCP de cada vez, o que significa que o LLMS luta para combinar várias fontes de dados. Os caras da Suada.ai atingiram esse problema exato ao tentar extrair dados de várias fontes ao mesmo tempo, onde o MCP não permitiu que eles consultassem com segurança a folga, linear, noção juntos. Então eles criaram uma solução personalizada que permite que a IA seja dinamicamente de várias integrações.
Passei algumas centenas de horas avaliando o que faz um bom agente de IA e multi-agenteAssim, Arquiteturas e agentes de orquestrador eram alguns itens de alto bilhete.
A N8N e seus colegas têm uma boa oportunidade aqui para lidar com vários agentes, chamadas MCP e fontes de dados.
O que esperamos:
O MCP por si só não faz um agente. Você precisa de lógica adicional para lidar com tarefas complexas adequadas para casos de uso multi-agente.
Futuro do MCP
A probabilidade de a encarnação do MCP atual usada na produção em dois anos é muito baixa.
O MCP está estabelecendo uma expectativa de experiência no usuário final, a saber, quão bem e facilmente o LLM pode interagir com serviços de terceiros. Espero que a indústria tenha todas as lições aprendidas com o exercício do MCP e forneça uma alternativa mais segura e baseada em API.
Um candidato provável a fazer isso será o Google, considerando o pedigree de definir protocolos como GRPC e QIC. O trabalho A2A do Google, que está posicionado para ser complementar ao MCP, é já mais seguro. Adicionar recursos semelhantes ao MCP em A2A é de se esperar.