Roots, Sampling y Logging de MCP: vías de migración tras su obsolescencia en 2026-07-28

Qué es

Estado al 25 de octubre de 2026. La revisión 2026-07-28 declara obsoletos Roots, Sampling y Logging. Volver a consultar sus avisos individuales, el registro de funciones obsoletas y la política de ciclo de vida antes de retirar el código de compatibilidad. El registro sitúa su posible eliminación, como muy pronto, en la primera revisión publicada a partir del 2027-07-28. Esto permite un cambio futuro de la especificación; no fija una fecha de desactivación automática.

Las funciones obsoletas siguen formando parte de la especificación. Las implementaciones nuevas deberían evitar adoptarlas; las existentes deberían migrar. Los calendarios de retirada de estas funciones en los SDK se rigen por separado. La política general también permite un procedimiento acelerado documentado para los riesgos de seguridad que cumplan los criterios, por lo que el plazo habitual de doce meses no es una garantía incondicional para cualquier circunstancia.

Por qué importa

Las tres funciones tienen propósitos distintos. Roots comunica ubicaciones relevantes del sistema de archivos, Sampling delega en el cliente una solicitud a un modelo y Logging entrega notificaciones de registro del protocolo. Sustituirlas puede trasladar responsabilidades entre el cliente, el servidor y el operador. Una migración que se limite a eliminar los indicadores de capacidad puede dejar funciones necesarias sin implementar.

Roots tiene un carácter expresamente informativo: MCP no impone límites de acceso al sistema de archivos. Sampling actualmente permite al cliente controlar el acceso al modelo y los permisos. Logging del protocolo es distinto de los registros operativos del servidor. Conservar estas distinciones al elegir las alternativas.

Cómo aplicarlo

• Sustituir Roots por contexto explícito. Las opciones documentadas son parámetros de herramientas, URI de recursos o una configuración del servidor que describa directorios y archivos. Validar las rutas y los permisos en el componente que acceda a ellos. Conservar el consentimiento del usuario y los controles de acceso adecuados; proporcionar un directorio no demuestra que quien hace la llamada pueda leerlo. Mientras se conserve Roots en esta revisión, anunciar la capacidad en cada solicitud e intercambiar roots/list mediante el mecanismo de solicitud de entradas.
• Sustituir Sampling por una integración directa con el proveedor. La especificación recomienda integrarse directamente con las API de los proveedores de modelos de lenguaje. Tratarlo como un cambio de responsabilidades, no como un simple cambio de nombre transparente: documentar qué componente obtiene acceso al modelo y qué datos envía. La antigua interfaz de Sampling proporcionaba control en el cliente y recomendaba la revisión humana. Mantener una revisión equivalente donde la aplicación la necesite y probar la vía de rechazo. Durante la transición, declarar las capacidades de Sampling por solicitud y evitar las opciones obsoletas de contexto entre servidores.
• Enviar los registros operativos a un destino adecuado. Las vías documentadas son stderr para transportes stdio y OpenTelemetry para observabilidad estructurada. Excluir secretos y datos personales de los mensajes de registro y controlar el acceso a los registros recopilados. Si la compatibilidad sigue requiriendo Logging del protocolo, el servidor declara logging; los clientes solicitan un nivel mediante io.modelcontextprotocol/logLevel en _meta.
• Probar el registro limitado a cada solicitud. Un servidor no debe emitir notifications/message cuando esa solicitud no incluya el nivel. Los mensajes permitidos pertenecen al flujo de respuesta de esa solicitud, nunca al flujo de suscripción. Verificar que el nivel de detalle seleccionado por un cliente no pueda afectar a la solicitud de otro.
• Retirar cada dependencia por separado. Como procedimiento de despliegue propuesto, inventariar los consumidores, introducir la alternativa, verificar el mismo flujo de trabajo permitido y, solo entonces, dejar de anunciar la capacidad obsoleta. Conservar pruebas de qué clientes siguen necesitándola.

Trampas

La integración directa con un modelo no hereda automáticamente la interfaz de consentimiento del cliente anterior. Un destino de registros alternativo no conserva automáticamente la ocultación de datos sensibles. Un parámetro de ruta no crea un entorno aislado. La declaración de obsolescencia es una razón para planificar estos cambios con cuidado, no un permiso para debilitar sus controles.