Los desarrolladores que utilizan modelos de lenguaje extensos (LLM) locales descubren que un único servidor de Protocolo Multicanal (MCP) puede consumir toda la ventana de contexto incluso antes de que un usuario escriba un prompt. Deben elegir entre descripciones de herramientas limitadas o un flujo de conversación interrumpido.

Por qué el exceso de tokens es importante para los LLM locales

MCP permite que un LLM llame a herramientas externas —APIs, scripts o utilidades del sistema de archivos— proporcionando al modelo una descripción de cada herramienta. Los modelos alojados en la nube con ventanas de 128 k tokens pueden absorber muchas definiciones de herramientas y aún dejar espacio para el diálogo del usuario. Un modelo de 7 mil millones de parámetros que se ejecuta localmente con una ventana de 8 k tokens se queda sin espacio tras cargar solo unas pocas herramientas. El dilema es evidente: las descripciones cortas y económicas desvían las llamadas; las descripciones largas y detalladas consumen el presupuesto necesario para el chat.

La cadena de eventos que nos ha traído hasta aquí

MCP fue creado para reemplazar el código de integración personalizado con una única interfaz impulsada por el modelo para múltiples fuentes de datos. La mayoría de los servidores MCP actúan como envoltorios (wrappers) ligeros alrededor de endpoints REST diseñados para operadores humanos, no para máquinas. Cuando esos envoltorios se integran en una sesión de un LLM local, el modelo debe leer el nombre, los parámetros y las notas de uso de cada herramienta antes de poder decidir cuál invocar. Las ventanas de contexto diminutas convierten este "exceso de descripción" en un cuello de botella estructural.

Quién gana y quién pierde

  • Los desarrolladores que crean asistentes en el dispositivo pierden flexibilidad. O bien podan los catálogos de herramientas, arriesgándose a fallos frecuentes, o aceptan un prompt inflado que trunca la entrada del usuario.
  • Los usuarios finales experimentan un comportamiento errático cuando el asistente selecciona la herramienta incorrecta o se niega a actuar porque el contexto está lleno.
  • Los proveedores de herramientas obtienen un punto de entrada uniforme.

El coste no es solo una peor experiencia; también plantea preocupaciones de seguridad. Cuando un agente MCP puede leer cualquier archivo local, el modelo de permisos colapsa a un esquema de "todo o nada". Sin un entorno de pruebas (sandbox), una herramienta mal configurada puede exponer todo el sistema de archivos.

Qué están haciendo los desarrolladores al respecto

Tres soluciones alternativas dominan la comunidad:

  • Recortar descripciones – Eliminar los metadatos de las herramientas hasta lo mínimo indispensable. Esto libera tokens pero aumenta la probabilidad de que el modelo elija el endpoint incorrecto, lo que provoca errores que los desarrolladores deben detectar y reintentar.
  • Carga dinámica – Cargar solo el subconjunto de herramientas relevantes para la conversación actual. Un despachador (dispatcher) ligero decide, basándose en la intención del usuario, qué conjunto de herramientas inyectar. Esto reduce el uso de tokens inactivos, pero añade latencia y complejidad al código.
  • Limitar servidores activos – Establecer un límite al número de servidores MCP por sesión, obligando a los desarrolladores a priorizar las integraciones más esenciales. Esto mantiene el tamaño del prompt manejable, pero sacrifica la amplitud de las capacidades.

Ninguna de estas soluciones es una solución mágica. Eliminar descripciones perjudica la fiabilidad; la carga dinámica añade una capa de decisión que ralentiza las respuestas; limitar los servidores obliga a tomar decisiones difíciles sobre qué fuentes de datos admitir.

Riesgos de seguridad derivados del problema de los tokens

Los agentes locales suelen ejecutarse con acceso sin restricciones al sistema de archivos. El protocolo MCP no ofrece granularidad entre "leer esta carpeta" y "leerlo todo". Algunos equipos han construido capas de puerta de enlace (gateways) para solucionar el problema del acceso total, añadiendo más complejidad. Esas puertas de enlace mitigan el problema del "control total", pero también aumentan la base de código.

Diseño de herramientas para modelos pequeños

Los modelos grandes en la nube pueden recuperarse de descripciones deficientes, por lo que los desarrolladores a veces pasan por alto la necesidad de definiciones de herramientas precisas. Para los modelos locales, siga estos principios:

  • Funcionalidad estrecha – Cada herramienta debe hacer una sola cosa. Una herramienta de "búsqueda" que también escriba archivos confundirá a un modelo que no puede gestionar responsabilidades superpuestas.
  • Nomenclatura inequívoca – Evite nombres genéricos como "process" o "handle". Los nombres deben transmitir la operación exacta, reduciendo la carga cognitiva del modelo.
  • Descripciones claras y concisas – Incluya solo los parámetros que el modelo realmente necesita para decidir. Utilice un formato consistente para que el modelo pueda reconocer patrones rápidamente.

Contrapunto: el protocolo sigue teniendo valor

A pesar de las dificultades, MCP sigue siendo atractivo porque abstrae el código repetitivo (boilerplate). Una única interfaz impulsada por el modelo puede conectarse a docenas de servicios sin necesidad de escribir adaptadores personalizados para cada uno. Los equipos que pueden permitirse modelos a escala de la nube ven el exceso de tokens como algo irrelevante, y la conveniencia compensa la sobrecarga. El desafío consiste en trasladar esa conveniencia al mundo restringido de los LLM en el dispositivo.

Conclusión

Si estás construyendo un asistente en el dispositivo, trata las descripciones de las herramientas MCP como un recurso escaso. Recorta, carga dinámicamente y diseña herramientas de alcance limitado para mantener viva la ventana de contexto para la conversación real. Al mismo tiempo, protégete contra el modelo de seguridad implícito de "acceso total" insertando una capa de permisos, incluso si esto cuesta unos pocos tokens adicionales. El equilibrio que logres determinará si tu LLM local se siente como un compañero útil o como un chatbot defectuoso.