O MCP virou o protocolo padrão pra conectar agentes de IA a ferramentas externas. OpenAI adotou, Google adotou, Microsoft adotou. A Anthropic doou o projeto pra Linux Foundation. Todo mundo embarcou.
Aí na Ask 2026, o CTO da Perplexity, Denis Yarats, disse que internamente eles estão abandonando MCP em favor de APIs tradicionais e CLIs.
O motivo: overhead de contexto. Cada ferramenta que você conecta via MCP precisa enviar pro modelo a descrição completa do schema, parâmetros, formatos de resposta. Tudo isso consome tokens da janela de contexto. Segundo dados que circularam depois do anúncio, o overhead chega a 72% da janela de contexto consumida antes do agente processar qualquer input do usuário.
Pensa nisso. Você conecta 15 ferramentas via MCP, e o modelo já gastou a maior parte da capacidade de raciocínio só entendendo o que tem disponível. Sobra pouco espaço pro problema real.
É um trade-off que pouca gente discute. MCP resolve elegantemente o problema de padronização, mas cria um problema de escalabilidade em produção. Quanto mais ferramentas, mais contexto desperdiçado. E em agentes que fazem muitas chamadas em conversas longas, isso se acumula.
A Perplexity lançou uma Agent API própria como alternativa. Um endpoint único que roteia pra múltiplos modelos com ferramentas embutidas. Menos flexível, mais eficiente.
Eu não acho que MCP vai morrer. Pra a maioria dos casos de uso com poucas ferramentas, funciona bem. Mas o ponto da Perplexity é válido: quando você escala pra produção com dezenas de integrações, o custo de contexto vira um gargalo real.
Se você está planejando arquitetura de agentes internos, vale medir. Quantas ferramentas MCP seu agente precisa? Qual o overhead real no seu caso? A resposta pode mudar a decisão entre protocolo padronizado e integração direta.
Conte os tokens do schema antes de copiar o protocolo
O número de 72% que circulou depois da Ask 2026 não veio como métrica oficial da Perplexity. Relatos posteriores apontam configurações em que três servidores MCP ocuparam 143 mil de 200 mil tokens, cerca de 72% da janela, antes da mensagem da pessoa. Cada ferramenta leva nome, descrição e JSON Schema. Dezenas de definições chegam a dezenas de milhares de tokens. O mecanismo é esse, independente do percentual exato no seu deploy.
A medição local é simples e quase ninguém faz. Monte o agente com o conjunto que vocês pretendem ir a produção. Extraia o prefixo enviado ao modelo (system, tools, recursos). Conte tokens desse prefixo e da primeira resposta vazia, sem arquivo de repositório. Repita com metade das ferramentas. A diferença é o custo de catálogo. Se o prefixo já come 40% da janela, o protocolo padronizado está cobrando um pedágio que a API estreita não cobra.
Não use o 72% como constante de arquitetura. Um agente com três tools de deploy não é o caso da Perplexity. Um agente interno com Jira, GitHub, Datadog, Salesforce, Drive e mais dez MCP servers talvez seja. A decisão muda com a conta, não com o recuo de um CTO em palco.
Ferramenta ociosa ainda ocupa janela se estiver anunciada
MCP descobre e anuncia o que está ligado. O modelo precisa ver o schema para decidir se chama. Ferramenta instalada e nunca usada ainda paga o anúncio a cada turno, a menos que o cliente faça carregamento progressivo de verdade: só nome curto no início, corpo sob demanda, ou um gateway que escolhe o subset por tarefa.
Conjunto ativo é o desenho. Catálogo disponível é o desejo. Separe os dois num arquivo de configuração por tipo de trabalho: agente de incidente com logs e deploy; agente de produto com issue tracker e docs; agente de dados com warehouse. Ligar os três perfis no mesmo processo é o caminho mais curto para o prefixo inchado.
Sessão longa piora o quadro. Além do schema, entram resultados de tool, trechos de arquivo e o histórico da conversa. O overhead inicial de 15 tools se soma ao lixo útil das chamadas anteriores. Compactação de histórico ajuda. Não devolve a fatia que o schema come em todo turno se as definições continuam no prompt.
Eu pediria um teto explícito: tokens de ferramenta abaixo de X% da janela, medido no ambiente real, com alarme se alguém ligar mais um server no perfil compartilhado. Sem teto, o conjunto só cresce.
CLI e API empurram descrição para fora do contexto
A alternativa que a Perplexity descreveu é antiga de propósito. REST com autenticação, limite, log e contrato versionado. CLI com uma linha de ajuda curta e a documentação fora do prompt. O modelo chama um endpoint ou escreve um comando. O schema detalhado mora no servidor, no --help ou num SDK, não em 40 mil tokens permanentes.
Cobranças extras aparecem nessa troca. Você perde descoberta dinâmica de qualquer tool de qualquer server. Ganha previsibilidade de auth (OAuth, papel, auditoria) que o transporte stdio do MCP local nunca resolveu bem em multi-tenant. Relatos da própria mudança citam isso ao lado do custo de token: empresa pede log e permissão granular; o protocolo ainda é mais maduro em desktop do que em plataforma.
A Agent API da Perplexity é o extremo gerenciado: um endpoint, ferramentas embutidas, roteamento entre modelos. Serve a quem aceita o cardápio deles. Para agente interno, o equivalente é um gateway próprio com 4 ou 5 tools estáveis, documentadas em OpenAPI, chamadas por HTTP. MCP pode continuar na borda, no editor da pessoa desenvolvedora, onde o catálogo rico vale o custo.
MCP continua útil quando o conjunto cabe
Desktop, Claude, Cursor, um server stdio com o repositório local: o overhead cabe e a descoberta ajuda. Produção com dezenas de integrações, conversa longa e custo por token visível no P&L: o recuo da Perplexity é um aviso mensurável, não um obituário do protocolo.
O rollout interno pode ser misto sem drama. Mantenha MCP no IDE. No serviço que atende usuário final ou fila interna, exponha poucas tools, meça o prefixo, e mova o restante para API ou CLI. A pergunta de arquitetura não é "MCP sim ou não". É quantas definições o modelo precisa ver agora para fazer o trabalho desta sessão.
