Perplexity se aleja de MCP — y no se equivocan

MCP — el Model Context Protocol — ganó. En cosa de un año pasó de ser un proyecto paralelo de Anthropic a la forma por defecto en que todo framework conecta herramientas a los agentes: más de 97M de descargas mensuales del SDK y más de 10.000 servidores MCP públicos para marzo de 2026. Ganó tan rápido que la industria se saltó una pregunta: ¿de verdad es bueno en producción?

Perplexity acaba de responder. En su evento Ask 2026, el CTO Denis Yarats dijo que internamente están dejando MCP — señalando el hinchazón del contexto y una autenticación torpe. Cuando una empresa que vive y muere por la calidad de sus agentes se aleja en silencio del estándar ganador, vale la pena entender por qué.

La cuenta se paga en contexto

Aquí está la parte que se saltan las demos de «enchúfalo todo». Cada herramienta MCP que enganchas trae su descripción — nombre, parámetros, notas de uso — y ese texto se instala en la ventana de contexto del modelo antes de que el agente haga nada. Con un puñado de servidores, todo bien. Conecta una caja de herramientas de verdad y, según algunos análisis de 2026, los metadatos de las herramientas pueden consumir el 40–50% de la ventana de contexto disponible antes del primer token útil.

Cada herramienta que «solo enchufas» es alquiler que pagas por la ventana de contexto, en cada turno, la use el agente o no.

Y no es solo cuestión de coste. Una ventana medio llena de definiciones de herramientas es una ventana con menos sitio para la tarea real — la conversación, los hechos recuperados, el plan. Es el mismo problema de context rot que hace que los agentes de largo alcance se desmoronen, solo que lo importaste a propósito, al arrancar, antes de que empezara el trabajo.

El villano no es MCP — es la mentalidad de «buffet»

No estoy en contra de MCP. Un protocolo compartido para herramientas es genuinamente bueno; el problema es la proliferación de 10.000 servidores sin un registro real ni una capa de confianza, y también el reflejo de atornillar cada servidor que concebiblemente podrías necesitar. MCP hizo que añadir herramientas fuera sin fricción, y sin fricción es exactamente como acabas pagando media ventana en alquiler.

El arreglo es tratar las herramientas como tratas las dependencias en cualquier base de código seria:

• Cura, no acumules. Cada herramienta de la ventana se gana su sitio o se va. Un conjunto ajustado que el agente de verdad usa le gana a un buffet que quizá use.
• Carga bajo demanda. El agente no necesita las 50 definiciones de herramientas para una tarea de reserva. Ajusta el conjunto de herramientas al trabajo — de forma dinámica — en vez de cargarlo todo por adelantado.
• Presupuesta la ventana. Sabe qué fracción del contexto consumen tus herramientas antes de que empiece la tarea. Si ronda la mitad, ya has perdido.
• La confianza también es un problema de dependencias. La descripción de una herramienta es texto bajo la influencia del atacante que tu agente lee. Diez mil servidores sin verificar son una cadena de suministro, no una librería.

En resumen

Que Perplexity deje MCP no significa «MCP está muerto». Es el primer gran jugador diciendo la parte incómoda: un protocolo que hace que añadir herramientas sea gratis hace que añadirlas sea demasiado fácil, y el coste aterriza en el único sitio donde no te lo puedes permitir — la ventana de contexto.

Trata las herramientas como dependencias, no como un buffet. Cúralas, cárgalas bajo demanda y presupuesta la ventana antes de que el agente siquiera arranque.