Cursor avisa por encima de 40 herramientas MCP, VS Code rechaza las solicitudes por encima de 128 y Claude Code aplaza las definiciones con la búsqueda de herramientas. Este artículo explica cada límite, el costo en tokens por herramienta y las soluciones para mantener una configuración cargada por debajo del techo.
Conectas un servidor MCP más y, de repente, tu agente deja de saber leer un archivo. Sin error, sin aviso rojo, solo una herramienta que ayer estaba y hoy falta. Eso es el límite de herramientas MCP en acción, y cada editor lo gestiona de forma distinta. Cursor te avisa cuando superas las 40 herramientas, VS Code rechaza las solicitudes por encima de 128 y Claude Code aplaza en silencio la mayoría de las definiciones de herramientas hasta que el modelo las pide.
Este artículo te da las cifras reales de cada cliente, los mensajes que verás al cruzar el límite, las cuentas de tokens que hay detrás de los límites y una lista corta de soluciones para mantener una configuración cargada por debajo del techo.
💡 Resumen rápido: planifica con 40 herramientas en Cursor, 128 en VS Code y 100 en Windsurf. Trata a Claude Code como "sin cifra fija, pero cada definición sigue costando contexto mientras la búsqueda de herramientas esté desactivada". Los límites cambian entre versiones, así que confírmalos con la versión que tengas instalada.
Esto es lo que recogen la documentación oficial y los hilos de la comunidad a fecha de octubre de 2026.
| Cliente | Límite de herramientas | Qué pasa al superarlo |
|---|---|---|
| Cursor | 40 herramientas entre todos los servidores MCP activados | Aparece un aviso y solo las primeras 40 herramientas llegan al agente |
| VS Code (Copilot Chat) | 128 herramientas por solicitud de chat | Error: "Cannot have more than 128 tools per request" |
| Windsurf (Cascade) | 100 herramientas entre todos los servidores | Las herramientas sobrantes no están disponibles hasta que desactivas algunas |
| Claude Code | Sin cifra fija | La búsqueda de herramientas aplaza las definiciones por defecto; desactivarla carga todo desde el principio |
| Claude Desktop | Sin tope máximo publicado | Cada definición de herramienta activada entra en el contexto de la conversación |
Hay dos cosas que destacan. Primero, VS Code es el único cliente de esta tabla cuyo número aparece en la documentación oficial. Los 40 de Cursor y los 100 de Windsurf proceden de hilos de foros y de artículos de terceros, por eso merecen la nota de "revisa tu versión". Segundo, el tope máximo rara vez es tu primer problema. Las respuestas más lentas, las elecciones incorrectas de herramientas y una ventana de contexto que se llena antes de que escribas un prompt aparecen mucho antes de que se alcance cualquier tope.
Un servidor MCP describe cada herramienta con un nombre, una descripción en lenguaje natural y un esquema JSON para sus argumentos. El cliente envía ese paquete completo al modelo con cada solicitud, antes de tu prompt y antes de cualquier contenido de archivo. Diez herramientas pequeñas apenas se notan. Ochenta herramientas verbosas pueden devorar una buena parte de la ventana que querías para el código.
Esa es la razón real por la que los clientes fijan topes. Un límite es una forma burda de proteger el presupuesto de contexto, mantener baja la latencia y evitar que el modelo se ahogue entre opciones. Los hilos del foro de Cursor describen el tope de 40 herramientas en esos mismos términos: reenviar decenas de herramientas en bruto hace que el modelo gaste contexto en evaluarlas, así que la latencia sube y la precisión baja.
El contexto es solo la mitad de la historia. La otra mitad es la elección. Cuando un modelo se enfrenta a decenas de herramientas con nombres que se solapan, como search_issues, search_repos y search_code, tiene que adivinar cuál encaja, y las adivinanzas fallan con más frecuencia a medida que crece la lista.
La documentación de llamadas a funciones de OpenAI sugiere apuntar a menos de 20 funciones disponibles al inicio de un turno, y la etiqueta como una sugerencia flexible. GitHub llegó a un resultado parecido dentro de Copilot: redujo el conjunto de herramientas integradas por defecto de 40 a 13 herramientas básicas y amplió el resto según se necesitaban. En los propios benchmarks de GitHub, ese enfoque mejoró las tasas de éxito entre 2 y 5 puntos porcentuales y redujo la latencia media en 400 milisegundos.
Así que el límite práctico queda por debajo del tope impreso. Un servidor con 12 herramientas con nombres muy precisos suele superar a uno con 90 herramientas que suenan todas igual.
Puedes medir tú mismo la confusión de herramientas en unos diez minutos, sin tocar la configuración de tu editor.
Repite el mismo experimento con varios modelos en paralelo. Claude Sonnet 5, GPT 5.4 y Gemini 3.1 Pro están disponibles como modelos de chat en PicassoIA, así que puedes comparar cómo maneja cada uno una lista abarrotada. Si las elecciones incorrectas caen con fuerza cuando la lista se reduce, tendrás la respuesta sobre cuántas herramientas puede cargar realmente tu flujo de trabajo.
💡 Advertencia: esta prueba evalúa la elección del modelo a partir de texto plano. Los clientes reales añaden su propio enrutamiento, así que trata el resultado como una señal, no como una garantía.
Cursor muestra un aviso cuando las herramientas de tus servidores activados superan las 40. La redacción que se ha publicado en el foro de Cursor viene a decir: tienes 50 herramientas de servidores activados, el límite es 40 y algunas herramientas podrían no estar disponibles para el agente. En versiones anteriores, las sobrantes simplemente se ignoraban. Si conectabas servidores que exponían 45 herramientas en total, el agente usaba 40, sin ningún diagnóstico detallado sobre cuáles cinco desaparecían.
Algunos artículos recientes dicen que las versiones nuevas de Cursor registran las herramientas de forma más flexible y cargan algunas bajo demanda. La página de documentación de MCP que revisamos no publica un número de herramientas, así que 40 sigue siendo la cifra segura para planificar.
💡 Ojo con la cuenta: el tope es total, no por servidor. Tres servidores con 15 herramientas cada uno ya te dejan en 45, cinco por encima del límite, aunque ningún servidor por separado parezca grande.
Cuatro movimientos, ordenados de menor a mayor esfuerzo:
.cursor/mcp.json y deja solo los de uso diario en el ~/.cursor/mcp.json global.Los interruptores por herramienta son una petición repetida en el foro de Cursor, así que si necesitas ese nivel de detalle hoy, tendrás que podar a nivel de servidor.
VS Code es el más explícito de los tres. Su documentación indica que una solicitud de chat puede tener un máximo de 128 herramientas activadas a la vez. Si lo superas, Copilot Chat falla con: "Cannot have more than 128 tools per request".
El recuento se aplica a todo lo activado en el selector de herramientas, no solo a las herramientas MCP, así que se llena más rápido de lo que esperas. Bastan dos o tres servidores grandes.
La solución rápida está en el selector de herramientas vista Chat. Desmarca herramientas individuales o servidores MCP completos hasta que el recuento baje de 128 y vuelve a enviar la solicitud.
Si quieres superar 128, VS Code ofrece herramientas virtuales. Configura github.copilot.chat.virtualTools.threshold y VS Code agrupa herramientas similares bajo una única herramienta virtual. El modelo ve primero los grupos y solo expande uno cuando el prompt lo necesita, lo que permite que una solicitud de chat supere el límite de 128.
Piénsalo como un índice: el modelo lee los títulos de los capítulos y luego abre uno. La contrapartida es un paso extra de expansión la primera vez que hace falta un grupo, a cambio de una lista inicial mucho más corta.
Las pruebas de GitHub con enrutamiento basado en embeddings muestran por qué agrupar compensa. La herramienta necesaria estaba lista en el 94,5 por ciento de los casos, frente al 87,5 por ciento de la selección basada en LLM y el 69,0 por ciento de una lista estática de herramientas.
Claude Code sigue otro camino. En lugar de fijar un tope de cantidad, evita pagar por cada definición desde el principio. Con la búsqueda de herramientas, las definiciones de herramientas MCP se retienen de la solicitud y el modelo recibe una única herramienta de búsqueda para cargar las que necesita. La documentación MCP de Anthropic enumera las excepciones: la búsqueda de herramientas está desactivada con un ANTHROPIC_BASE_URL personalizado, con ENABLE_TOOL_SEARCH=false y con modelos anteriores a la generación Claude 4.5.
Los artículos de la comunidad describen más valores para la misma variable, como auto, que aplaza solo cuando las definiciones superan el 10 por ciento de la ventana de contexto, y auto:5 para un umbral del 5 por ciento. Consulta la documentación de tu versión instalada antes de fiarte de esos valores. Un artículo midió 147 definiciones de herramientas en unos 90.000 tokens cuando se cargaban desde el principio, frente a unos 15.000 con la búsqueda de herramientas activada.
El tamaño de la salida también importa. Claude Code avisa cuando un único resultado de herramienta MCP supera los 10.000 tokens y limita la salida a 25.000 por defecto. Auméntalo con MAX_MCP_OUTPUT_TOKENS solo cuando una tarea lo necesite de verdad.
No encontramos un número fijo de herramientas para Claude Desktop en la documentación de Anthropic. Los artículos de terceros describen un mecanismo más simple: cada herramienta que expone cada servidor conectado se inyecta en el contexto de la conversación en cada mensaje, sin recuperación dinámica. Su consejo práctico es mantenerse entre 30 y 50 herramientas activas antes de que llegue la saturación y la confusión. Considera ese rango como experiencia de la comunidad, no como un límite oficial.
La conclusión para los usuarios de Claude es que el límite es un presupuesto, no un número. Activa solo los conectores que necesite la conversación actual y desactiva el resto.
Las cifras publicadas varían mucho porque varía el detalle de los esquemas. Estos datos proceden de listados públicos de costo en tokens y del artículo mencionado antes:
| Servidor o configuración | Definiciones de herramientas | Tokens por adelantado | Por herramienta (aprox.) |
|---|---|---|---|
| Servidor MCP de GitHub | 86 | 14.406 | unos 170 |
| Variante más pequeña del servidor de GitHub | 36 | 11.430 | unos 320 |
| Servidor de GitHub Projects | 19 | 2.316 | unos 120 |
| Configuración mixta de un artículo | 147 | unos 90.000 | unos 610 |
Lo que importa es la dispersión. Una herramienta cuesta entre unos 120 y 610 tokens según la cantidad de descripción y de esquema que lleve. Cuenta las herramientas, pero pésalas también.
Úsala para verificar cualquier configuración:
herramientas × tokens por herramienta ÷ ventana de contexto = parte gastada antes de que escribas
| Herramientas | Tokens cada una | Total | Parte de una ventana de 200.000 |
|---|---|---|---|
| 10 | 300 | 3.000 | 1,5 % |
| 40 | 300 | 12.000 | 6 % |
| 86 | 170 | 14.620 | 7,3 % |
| 128 | 600 | 76.800 | 38,4 % |
La ventana de 200.000 es solo un ejemplo, y tu modelo puede ofrecer más o menos. El patrón se mantiene: 40 herramientas ligeras cuestan alrededor del 6 por ciento, mientras que 128 pesadas pueden devorar más de un tercio. El peso de los esquemas importa más que el número impreso en el tope.
Clasifica cada herramienta en tres o cuatro tareas, por ejemplo código, datos, documentación y medios. Después activa una tarea cada vez. En Cursor eso significa la configuración por proyecto, en VS Code el selector de herramientas y en Claude los interruptores de conectores.
Agrupar también resuelve las colisiones de nombres. Cuando las herramientas de documentación y las de código nunca comparten una conversación, search solo puede significar una cosa.
La mayoría de las configuraciones arrastran peso muerto. Repasa esta lista una vez:
💡 Regla general: si una herramienta no se ha usado en un mes, está gastando tokens y no aporta nada.
Si escribes tu propio servidor MCP, diséñalo pensando en el presupuesto: una sola tarea, descripciones cortas, nombres que nunca se solapen y esquemas de argumentos ajustados. El conector de PicassoIA para Claude es un buen ejemplo del enfoque ligero. Expone nueve herramientas: generate_image, edit_image, dos generadores de video, get_generation, list_generations, list_models, get_account y cancel_generation. Todas sirven a una sola tarea: crear imágenes y videos.
Un servidor de ese tamaño cabe con holgura por debajo de las 40 herramientas de Cursor y las 100 de Windsurf, y deja espacio para media docena de servidores más antes de que notes presión.
La forma más fácil de notar lo que te da un presupuesto de herramientas ordenado es ejecutar un flujo de trabajo real con él. Pide una imagen en lenguaje natural, revisa el resultado, ajusta un detalle y vuelve a pedirla. Una configuración enfocada mantiene ese ciclo rápido, porque el modelo no tiene que abrirse paso entre sesenta herramientas sin relación para encontrar la que necesita.
Las fotos de este artículo salieron de P-Image y de prompts cortos y concretos. Puedes probar el mismo tipo de prompts en PicassoIA ahora mismo:
PicassoIA también convierte una imagen fija en un video corto, así que la misma foto puede convertirse en un clip con un paso más. Explora todos los modelos en picassoia.com/en/all-models, elige uno, escribe un prompt sobre tu propio proyecto y mira qué obtienes. Cambia una palabra, vuelve a generarlo y compara. Ese hábito pequeño de probar una variable a la vez es el mismo que mantiene sana una configuración MCP.
Elige tu idioma
