MCP ha muerto en silencio. Corsair muestra qué lo reemplaza.
Tenía cuarenta y tres herramientas conectadas a un solo agente y lo observaba perder la cabeza en tiempo real.
La tarea era estúpidamente simple. "Extraiga los últimos diez correos electrónicos de mi Gmail y resuma todo lo relacionado con la propuesta que envié el martes". Un trabajo de dos pasos. Leer correo electrónico. Resumir. Eso es todo. En cambio, el agente llamó a una herramienta de búsqueda de Slack. Luego, una herramienta de calendario que había conectado para un proyecto diferente. Luego intentó invocar gmail_get_messages, excepto que ese no era el nombre de la función. La herramienta real era read_gmail_inbox. El agente había alucinado una llamada API que parecía plausible a partir de un esquema que recordaba a medias a través de 38.000 tokens de definiciones iniciales de herramientas.
Terminé la ejecución, abrí el registro de entrada y conté. Antes de que mi mensaje llegara al modelo, MCP había inyectado más de 40.000 tokens de esquemas de herramientas en la ventana contextual. Cuarenta mil fichas. Para responder una pregunta sobre diez correos electrónicos. El agente nunca tuvo ninguna oportunidad.
Ese fue el momento en que dejé de defender MCP y comencé a buscar lo que vendría después. Voy a repasar lo que encontré, incluido un pequeño proyecto de código abierto llamado Corsair que creo que apunta a la arquitectura real para el uso de herramientas en 2026. Pero primero, es necesario comprender qué es lo que realmente falló. Porque "MCP está muerto" no es una exageración. Es lo que dicen las matemáticas cuando llevas el protocolo más allá de las demostraciones de juguetes.
Qué se suponía que debía hacer MCP
Anthropic lanzó el Protocolo de contexto modelo a finales de 2024 con un discurso claro y ambicioso. Los LLM son cerebros sin manos ni piernas. Pueden razonar brillantemente sobre código, lenguaje y estrategia, pero no pueden publicar un tweet, leer su bandeja de entrada o actualizar una hoja de cálculo sin un sistema externo. Se suponía que MCP era esa plomería: estandarizada, neutral respecto al proveedor y universal.
El mecánico fue sencillo. Expones una herramienta. La herramienta anuncia un esquema JSON que describe su nombre, parámetros y lo que hace. El cliente MCP inyecta el esquema de cada herramienta disponible en la ventana contextual del modelo al inicio de la conversación. El modelo elige la herramienta adecuada, genera una llamada estructurada y el tiempo de ejecución la ejecuta. Agregar herramienta. Obtenga capacidad. Repetir.
Lo compré por completo. El año pasado escribí sobre los tres MCP que convirtieron a Claude en mi centro de operaciones: Canva, Zapier y Stripe conectados cambiaron mi forma de trabajar durante aproximadamente seis meses. Con tres o cuatro herramientas, MCP parece mágico. El protocolo desaparece. Pides cosas en un inglés sencillo y suceden.
Pero tres o cuatro herramientas es la versión de juguete. En el momento en que se amplía, en el momento en que se intenta conectar la pila real que utiliza un profesional, la arquitectura se abre de tres maneras específicas.
El problema de la hinchazón de la ventana contextual
Aquí está el número que puso fin al romance para mí.
Según un punto de referencia de 2025 de Scalekit, la misma operación que tomó 1.365 tokens a través de una CLI costó 44.026 tokens a través de MCP. Eso es aproximadamente 32 veces la sobrecarga del token, y casi todo fue inyección de esquema: 43 definiciones de herramientas empaquetadas en contexto antes de que el agente hubiera leído un solo carácter de la pregunta real del usuario. Todos los demás análisis acreditados que he leído desde entonces aterrizan en el mismo vecindario. El equipo de ingeniería de CodeRabbit midió servidores MCP individuales que consumían más de 55.000 tokens de esquema por adelantado. La investigación de Cyclr encontró que con más de 50 herramientas, los esquemas pueden consumir entre el 5% y el 7% de una ventana de contexto de 200K antes de que comience la conversación.
Lea esos números con atención. Del cinco al siete por ciento de su contexto (desaparecido) antes de que alguien haya escrito algo.
El problema es arquitectónico, no a nivel de implementación. MCP se diseñó basándose en la suposición de que el modelo necesita ver cada herramienta para usar cada herramienta. Esa suposición era razonable cuando los agentes tenían cuatro o cinco herramientas. Es catastrófico cuando tienen cuarenta. Y cuarenta no es el límite superior: eso es aproximadamente lo que un desarrollador en activo acumula entre GitHub, Slack, Linear, Sentry, su base de datos, su correo electrónico, su calendario y su CMS.
He visto mis propias configuraciones superar las sesenta herramientas sin intentarlo. Cada uno parece "gratuito" cuando lo agregas. Cada uno grava cada solicitud futura, ya sea que la use o no.
Cuando comienzan las alucinaciones
Aquí está la parte que la mayoría de los artículos entierran. El costo del token es el problema aburrido. El problema interesante es qué sucede con el razonamiento del modelo cuando su atención tiene que distribuirse entre docenas de esquemas de herramientas.
Hay un patrón que he visto repetidamente tanto en mis propios registros como en la investigación publicada. Una vez que la utilización del contexto supera aproximadamente el 70%, la precisión de la selección de herramientas del modelo colapsa. Comienza a combinar parámetros entre herramientas similares. Llama a la herramienta correcta con argumentos del esquema de una herramienta diferente. Inventa herramientas que no existen pero que suenan como deberían. Y (este es realmente desconcertante) hace todo esto con plena confianza. Las llamadas alucinadas se parecen exactamente a las reales.
Los puntos de referencia estilo Scalekit también se alinean con el trabajo académico. El artículo RAG-MCP de arXiv (2505.03275) ejecutó una prueba de estrés en la que alimentaron a un LLM con un conjunto creciente de descripciones de herramientas MCP y observaron cómo la precisión de la selección caía por un precipicio. Con el enfoque de volcado de esquema completo (la forma en que funciona MCP hoy en día), midieron una precisión de selección de herramientas del 13,62 %. Con la selección basada en la recuperación, el mismo modelo en las mismas consultas alcanzó el 43,13%. Más del triple de precisión con menos de la mitad de las fichas de aviso.
Eso no es un problema de sintonización. Ése es un problema de "todo el enfoque es incorrecto".
Les daré el ejemplo más concreto de mis propias pruebas. Tenía dos herramientas conectadas: send_email (a través de Gmail MCP) y send_message (a través de Slack MCP). Misma estructura verbal. Diferentes plataformas. Diferentes formas de parámetros. Aproximadamente en una de cada siete ejecuciones, el agente generaría una llamada a send_email con los parámetros channel y text de Slack. El tiempo de ejecución lo rechazaría. El agente se disculpaba, volvía a intentarlo y, a veces, tenía éxito y otras fallaba de una manera diferente. Cada reintento quemó tokens. Cada modo de falla era único. Depurarlo fue como perseguir fantasmas.
Cuando volví a recortar a doce herramientas, la tasa de fallas cayó a casi cero. Doce herramientas, para un agente que realiza un trabajo. Ése es el práctico techo que MCP le ofrece en producción.
El impuesto a la fragmentación de esquemas
Si bien las especificaciones de MCP están técnicamente estandarizadas, la realidad de ejecutarlo entre proveedores en 2026 es más complicada de lo que sugiere el marketing.
Ahora he conectado servidores MCP de al menos ocho proveedores diferentes y puedo decirles con absoluta certeza que el "esquema JSON" esconde un océano de inconsistencia. Algunos servidores devuelven errores como objetos estructurados. Algunos devuelven errores como cadenas insertadas dentro de respuestas exitosas. Algunos servidores paginan. Algunos no lo hacen y lo truncan silenciosamente. Algunos servidores respetan la distinción de campo opcional /required. Algunos tratan todo como es necesario y se rompen si omiten algo. La autenticación varía desde OAuth limpio hasta "pegar este token en un archivo de configuración y rezar".
Cada una de estas inconsistencias obliga al modelo o al desarrollador a escribir una lógica defensiva. Multiplique eso por la cantidad de servidores MCP que está ejecutando y la promesa del "protocolo unificado" se convierte en "sopa de esquema JSON con código de adaptador en el medio".
El problema más profundo es que MCP estandarizó el transporte pero no la semántica. Dos servidores pueden ser MCP válido y no comportarse en nada parecido entre sí. Está bien cuando tienes uno o dos. Es un impuesto de integración cuando tienes veinte.
Más constructores que usuarios
Esta es la señal de la que nadie en los materiales de marketing de MCP quiere hablar. Mira los registros. Pulse MCP. Directorio de conectores de Anthropic. Herrería. Glama. Ahora hay miles de servidores MCP. La mayoría de ellos tienen un puñado de estrellas de GitHub y casi ningún usuario real.
La comunidad está llena de gente construyendo servidores MCP. Está sorprendentemente vacío de gente que los ejecute en producción a escala. La razón no es un misterio: son los tres problemas que acabo de atravesar. La primera vez que intentas conectar quince de estas cosas en un solo agente, te golpeas contra la pared. Te retiras silenciosamente a tres o cuatro herramientas, o abandonas MCP por completo y vuelves a las llamadas API directas, o comienzas a escribir código agresivo de gestión de contexto para comprimir lo que inyecta MCP.
Escribí exactamente sobre este patrón en mi artículo sobre cómo el Modo Contexto solucionó mi problema de memoria de Claude Code. El modo contexto es una solución inteligente para el síntoma: elimina las salidas de la herramienta MCP del contexto después de consumirlas. Pero no soluciona el problema ascendente de que cada esquema se inyecte al inicio. Simplemente evita que el sangrado mate al paciente.
Cuando el ecosistema de solución se vuelve más grande que el protocolo mismo, el protocolo está en problemas.
El cambio de modelo mental: del carné de biblioteca a la enciclopedia
Aquí está el encuadre que finalmente me hizo clic. MCP trata las herramientas como libros que lleva consigo. Cada vez que inicias una conversación, cargas todos los libros que puedas necesitar en tu mochila y luego razonas mientras estás aplastado por su peso. El modelo tiene que considerarlos todos, todo el tiempo, por si acaso.
Hay una manera mejor y obvia. No cargues con los libros. Llevar un índice. Cuando necesite información, busque qué libro la contiene, busque solo ese libro y lea.
Este es el modelo de enciclopedia. El modelo sabe qué libros existen (sus títulos, una descripción de una línea, el dominio aproximado) y recupera el esquema completo sólo cuando una consulta realmente lo requiere. Esta es exactamente la arquitectura que RAG (generación de recuperación aumentada) trajo al documento de preguntas y respuestas hace varios años. Simplemente no lo aplicamos a la selección de herramientas porque el diseño original de MCP no anticipó la escala.
Aplique RAG a herramientas en lugar de documentos y inversiones matemáticas. En lugar de que cada conversación comience con 40.000 tokens de esquema, comienza quizás con 200 tokens de herramienta índice. Cuando el usuario pide algo, una búsqueda vectorial recupera los dos o tres esquemas de herramientas relevantes, se inyectan en contexto y el modelo elige uno. Las tasas de alucinaciones disminuyen porque el modelo no se ahoga en opciones de sonido similar. Los costos de los tokens caen porque estás pagando por lo que usas, no por lo que podrías usar. El número de herramientas se vuelve efectivamente ilimitado.
Karpathy ha estado señalando ideas relacionadas durante un tiempo: cubrí algunas de sus ideas sobre la arquitectura RAG cuando escribí sobre [la construcción de una base de conocimiento personal RAG en Obsidian] (https://www.mejba.me/blog/karpathy-obsidian-rag-knowledge-base). Las herramientas son simplemente otro tipo de artefacto recuperable. Deberíamos tratarlos de esa manera.
Introduzca Corsair
Corsair es un proyecto de código abierto en GitHub (github.com/corsairdev/corsair) que implementa exactamente este patrón. No voy a fingir todavía que es un producto pulido; no lo es. El repositorio es joven, los documentos son escasos y la comunidad es pequeña. Pero la arquitectura es la respuesta más honesta que he visto a las preguntas que MCP no puede responder.
Así es como funciona a nivel mecánico.
Instala Corsair como una capa entre su agente y sus herramientas. Se entrega con un catálogo de definiciones de complementos para servicios comunes: Slack, Gmail, GitHub, Google Calendar y más que se están agregando. Los metadatos de cada complemento se encuentran en un índice vectorial. Cuando su agente recibe una consulta, Corsair primero ejecuta una búsqueda semántica en el catálogo de complementos, recupera solo los esquemas de herramientas del complemento relevante y los expone al modelo. Todo lo demás queda fuera de contexto.
Para el agente, Corsair parece una pequeña cantidad de metaherramientas: buscar en el catálogo, buscar un complemento, ejecutar una llamada. Para usted, como desarrollador, exponer veinte integraciones es aproximadamente una línea de código. La complejidad se encuentra dentro del tiempo de ejecución de Corsair, donde pertenece.
El modelo de credencial es la parte que más aprecié. Corsair almacena la autenticación localmente en una base de datos archivada. No hay retransmisión obligatoria en la nube. No hay un panel de terceros que administre sus tokens OAuth. Si desea conectar su Gmail personal y el GitHub de su cliente al mismo agente, los secretos permanecen en su máquina. Para cualquiera que haya creado agentes que toquen sistemas sensibles, esto es más importante que cualquier línea de especificaciones de funciones.
La diferencia en la experiencia del desarrollador
Permítanme concretar el contraste con cómo se siente un trabajo de cableado típico bajo cada enfoque.
Bajo MCP, agregar un servicio es una ceremonia de varios pasos. Encuentre el servidor MCP adecuado. Lea su LÉAME. Configúrelo en su cliente (Claude Desktop, Cursor, tiempo de ejecución personalizado; todos difieren ligeramente). Autenticar. Reinicie su cliente. Prueba. Tenga en cuenta que un parámetro tiene un nombre ligeramente diferente al que dicen los documentos. Depurar. Date cuenta de que el formato de respuesta del servidor no coincide con el estándar. Escribe análisis defensivo. Reinicie de nuevo. Ahora haga esto para el próximo servicio. Y el siguiente.
Según el patrón de recuperación de estilo Corsair, agregar un servicio se acerca más a "registrar el complemento, almacenar la credencial y listo". No es necesario reconfigurar el agente. La ventana de contexto no crece. Nada más en el sistema tiene que saberlo.
Quiero ser preciso aquí porque realmente estoy tratando de no exagerar. Corsair específicamente es temprano. El catálogo de complementos es pequeño. Te toparás con asperezas si intentas usarlo para algo específico hoy. Pero el patrón (recuperación de herramientas impulsada por RAG) es en lo que convergen todos los proyectos serios de infraestructura de agentes que he analizado. La propia Anthropic publicó recientemente una investigación sobre la carga diferida de esquemas y la activación dinámica de herramientas. El artículo de arXiv "La atención a las herramientas es todo lo que necesita" (2604.21816) presenta el mismo argumento arquitectónico desde un ángulo diferente. La dirección está fijada, incluso si la implementación principal aún no ha cristalizado por completo.
Dónde MCP todavía tiene sentido
Quiero ser justo, porque creo que muchas publicaciones de "X está muerto" exageran su caso y pierden credibilidad. MCP no es inútil. Simplemente no se adapta bien a la escala hacia la que la mayoría de nosotros lo estamos empujando.
MCP es realmente bueno cuando tienes un conjunto pequeño, fijo y seleccionado de herramientas (digamos, de tres a siete) al que deseas que todas las conversaciones tengan acceso. El modelo de esquema inicial está bien a esa escala. La latencia es baja. La atención del modelo tiene espacio para extenderse sin romperse. Las ventajas de estandarización del protocolo superan sus gastos generales. Si está creando un agente enfocado que hace una cosa (un revisor de código con tres herramientas, un asistente de escritura con cuatro), MCP está bien. Posiblemente sea la respuesta correcta.
MCP también tiene sentido como backend. Puede imaginar sistemas de recuperación como Corsair hablando MCP bajo el capó para la invocación de la herramienta real, mientras que la capa de descubrimiento superior opera según principios de recuperación. El protocolo se convierte en infraestructura en lugar de un modelo orientado al usuario. Probablemente ahí es donde todo esto aterrice a largo plazo.
Para lo que MCP no sirve es para el trabajo real que los agentes más ambiciosos deben hacer: coordinar docenas de servicios, determinar dinámicamente qué herramientas son relevantes para cada tarea y mantenerse por debajo del umbral de utilización del contexto donde el razonamiento colapsa. Para esa carga de trabajo, el modelo de inyección de esquemas es estructuralmente incorrecto y ninguna compresión de contexto lo salva.
Qué estoy haciendo ahora
He dividido mi propia infraestructura de agentes en dos vías. Para los agentes de propósito único y de alcance limitado (mi robot de revisión de código, mi conversor de captura de pantalla a CSS, mi agente de clasificación de correo electrónico), me quedaré en MCP. De tres a cinco herramientas cada uno. No es necesario recuperarlo. El protocolo funciona.
Para mi agente de operaciones de uso general (el que necesita tocar el correo electrónico, el calendario, GitHub, mi CMS, mis análisis, mi CRM y una docena de otros sistemas) he pasado a una arquitectura basada en la recuperación. Al estilo Corsair de hoy, posiblemente algo más maduro en seis meses. El billete simbólico por sí solo justificaba la migración. La fuerte caída en las llamadas de herramientas alucinadas lo justificó dos veces.
El modelo mental que ahora aplico a cada nuevo agente es el siguiente: ¿cuántas herramientas necesitará? Si la respuesta es "cinco o menos, alguna vez", MCP está bien. Si la respuesta es "Realmente no lo sé y probablemente más de diez", busco recuperarlo. En mi experiencia, el punto de cruce se encuentra alrededor de ocho herramientas, y no es elegante: el rendimiento se degrada rápidamente una vez que lo cruzas.
Ese único punto de decisión me ha ahorrado horas de depurar llamadas alucinadas y colapsos del razonamiento. Ojalá alguien me lo hubiera entregado hace un año.
Preguntas frecuentes
¿MCP está realmente muerto o simplemente está luchando a escala?
MCP no está muerto para agentes pequeños y enfocados con tres a siete herramientas; funciona bien allí. Está funcionalmente muerto para los agentes de propósito general que necesitan acceso a docenas de servicios, porque la inyección de esquemas provoca un aumento del contexto y alucinaciones en la selección de herramientas que los enfoques basados en la recuperación resuelven limpiamente. La mayoría de los equipos de producción se están hibridando silenciosamente.
¿Qué es Corsair? ¿Está listo para producción?
Corsair es una capa de integración de código abierto para agentes AI (github.com/corsairdev/corsair) que utiliza RAG para recuperar dinámicamente solo esquemas de herramientas relevantes por consulta en lugar de inyectarlos todos por adelantado. Es temprano (pequeño catálogo de complementos, documentos en evolución), pero el patrón arquitectónico que representa es en lo que está convergiendo la infraestructura de agentes seria.
¿Por qué agregar más herramientas MCP empeora a los agentes?
Cada herramienta MCP inyecta entre 550 y 1400 tokens de esquema en contexto al inicio de la conversación. Más allá de 50 herramientas, esto consume entre el 5% y el 7% de una ventana de contexto de 200K incluso antes de que llegue la pregunta del usuario. Una vez que la utilización del contexto supera aproximadamente el 70%, la atención del modelo se fragmenta entre herramientas de apariencia similar, las tasas de alucinaciones aumentan y la precisión de la selección de herramientas colapsa.
¿Cómo mejora RAG-MCP la precisión de la selección de herramientas?
El artículo RAG-MCP (arXiv 2505.03275) mostró que la selección de herramientas basada en la recuperación logró una precisión del 43,13 % frente al 13,62 % para la línea base de inyección de esquemas en el mismo punto de referencia: más del triple de precisión con menos de la mitad de los tokens de solicitud. El modelo solo ve las herramientas relevantes para la consulta actual, por lo que su atención no está fragmentada.
¿Debería migrar de MCP a un enfoque basado en recuperación ahora mismo?
Si su agente utiliza menos de ocho herramientas y funciona bien, quédese. Si está teniendo alucinaciones, aumentando los costos de los tokens o planea escalar más de diez herramientas, comience a crear prototipos de una capa de recuperación como Corsair ahora. El punto de cruce no es elegante: el rendimiento se degrada rápidamente una vez que se cruza y la migración es más fácil antes de tener tráfico de producción dependiendo de la arquitectura anterior.
Trabajemos juntos
¿Quiere crear sistemas AI, automatizar flujos de trabajo o ampliar su infraestructura tecnológica? Me encantaría ayudar.
- Fiverr (compilaciones e integraciones personalizadas): fiverr.com/s/EgxYmWD
- Cartera: mejba.me
- Ramlit Limited (soluciones empresariales): ramlit.com
- ColorPark (diseño y marca): colorpark.io
- xCyberSecurity (servicios de seguridad): xcybersecurity.io
