Crítica da Abstração de Limites e Abordagem de Integração de Serviços do MCP

Uma discussão no Reddit no r/ClaudeAI examina onde o MCP traça seu limite de abstração e argumenta que ele erra nisso de uma forma que vai além das críticas típicas de implementação, como segurança, inchaço de tokens ou problemas de transporte.

Argumento Principal Sobre Integração de Serviços

A postagem identifica três preocupações separadas quando um agente precisa trabalhar com um serviço: acesso à API, ferramentas eficientes que a envolvem e conhecimento de domínio sobre como usá-la bem. De acordo com a fonte, o MCP agrupa todos os três em uma única camada, resultando em um subconjunto limitado do que a API subjacente pode realmente fazer.

Lattice como Exemplo Concreto

A discussão usa o Lattice como um exemplo específico. Seu cliente web é alimentado por uma API GraphQL completa que cobre tudo o que um funcionário gostaria de fazer. No entanto, sua API pública cobre apenas fluxos de trabalho de administração de RH. A postagem argumenta que o MCP incentiva os serviços a construir mais uma interface limitada, em vez de simplesmente abrir as APIs que já possuem.

Abordagem Alternativa Proposta

O autor sugere um caminho melhor: os serviços tornam suas APIs principais universalmente acessíveis, observando que o problema de autenticação já foi resolvido pelo OAuth 2.0 com PKCE. O conhecimento de domínio deve ser distribuído como habilidades do agente, em vez de ser incorporado às definições de ferramentas do MCP.

A postagem completa está disponível em tomyandell.dev/blog/my-problem-with-mcp, e a discussão no Reddit convida outros a compartilharem seus pensamentos sobre se essa crítica do limite de abstração está correta.