Instrumenta la ruta antigua antes de eliminarla

MCP es un protocolo abierto para que las aplicaciones de LLM llamen a herramientas mediante JSON-RPC.

La tarea de Kent: tienes una ruta heredada todavía conectada, y no has contado si alguien la sigue usando. Mide antes de eliminar.

Este repositorio ejecuta un servidor MCP de doble era y un registro SQLite que sobrevive a un reinicio. Mantienes la alternativa mientras quede alguna operación heredada.

La página de versionado nombra los dos carriles. Legacy es 2025-11-25 y anteriores: la sesión comienza con initialize. Modern es 2026-07-28 y posteriores: cada solicitud lleva versión e identidad en _meta.

Cuenta el trabajo completado

Un cliente que se reconecta cambia el recuento de solicitudes. Cinco llamadas a herramientas heredadas cuestan quince solicitudes si el cliente abre una conexión nueva cada vez, y siete si mantiene una sola conexión. El protocolo de saludo heredado gasta initialize y notifications/initialized una vez por conexión, así que un cliente que se reconecta parece tráfico heredado intenso. Cada fila son las mismas cinco llamadas a herramientas por carril:

Cuentas 5 y 5 en la fila de operaciones. Las filas de solicitudes difieren en seis puntos porque el cliente decidió reconectarse. recommend() lee la fila de operaciones. Cuenta la unidad que sigue coincidiendo después de una reescritura del transporte o de un cliente que cambie cómo se conecta.

Related MCP server: mcpstat

Ejecútalo

Node 24 o superior. Almacenas el registro con node:sqlite.

Inicia primero el recopilador, luego el servidor, y después genera tráfico:

pnpm install

pnpm collector   # http://127.0.0.1:3000, OTLP (the metric export format) and agent tools
pnpm server      # http://127.0.0.1:8787, dual-era MCP server
pnpm traffic     # legacy and modern tool calls, plus DCR and CIMD hits

DCR es Dynamic Client Registration: el cliente envía metadatos por POST a /register en cada conexión. Obsoleto en 2026-07-28. CIMD es Client ID Metadata Documents: el id de cliente es una URL HTTPS a metadatos estáticos, el reemplazo de DCR.

Después lee los dos almacenes:

pnpm report      # verdict from .data/migration-evidence.db
pnpm proof       # lane series from the collector

Espera seis segundos después de pnpm traffic antes de pnpm proof para que el raspado se complete.

La primera ejecución imprime esto:

Migration readiness: MCP protocol lanes
=======================================
window            : 7 days
active days       : 1/7 required
legacy operations : 5
modern operations : 3
total operations  : 8/100 required
legacy %          : 62.50%
raw requests      : 15 legacy / 6 modern
legacy methods    : initialize x5, notifications/initialized x5, tools/call x5
legacy clients    : legacy-dashboard@0.9.4
modern clients    : modern-agent@2.1.0
auth DCR          : 2 attempts (1 success, 1 failure)
auth CIMD         : 3 attempts (2 success, 1 failure)

recommendation    : keep_both

A legacy client completed an operation. Keep the fallback and check next week.
Ask these clients to upgrade: legacy-dashboard@0.9.4.

pnpm traffic envía cinco clientes legacy y tres modernos, la mezcla que Kent describe unas semanas después del lanzamiento de una especificación. Cada cliente se reconecta para su única llamada, así que la fila de solicitudes muestra 15 contra 6. El informe nombra a legacy-dashboard@0.9.4, así que sabes a quién enviar el correo.

La política

Valores predeterminados: una ventana de siete días, siete días de tráfico activo, 100 operaciones completadas.

recommend() devuelve keep_both después de una operación legacy, incluso contra doscientas modernas. Esa llamada todavía pertenece a un cliente. El volumen moderno no te dice si alguien sigue necesitando la ruta antigua.

Ventana de obsolescencia

El registro de funciones obsoletas lista DCR, roots, sampling y logging como obsoletos en 2026-07-28. La eliminación más temprana es la primera revisión en o después de 2027-07-28. Un informe local limpio no mueve esa fecha. Los clientes que siguen la especificación todavía tienen la ventana prometida.

Pregunta a tu agente

Deja el recopilador y el servidor en ejecución. .mcp.json apunta autotel a http://127.0.0.1:3000/mcp y migration a http://127.0.0.1:8787/mcp. migrationStatus lee la ventana persistente.

Lista mcp.protocol.lane.operations en autotel y compara las series lane=legacy y lane=modern. Llama a migrationStatus en el servidor de migración. ¿Podemos eliminar la alternativa de 2025-11-25? Cita los recuentos de operaciones, los días activos y los límites de la política.

Ejecuta ese prompt en un cron semanal y obtienes la respuesta de Kent.

Señales

list_metrics devuelve una serie por conjunto de atributos, así que el agente agrupa por lane. Necesitas autotel-mcp 0.5.1 o superior para que esos atributos sobrevivan a la ingesta.

Kent promedia 125 registros DCR por usuario porque cada reconexión escribe otro registro. Un cliente CIMD no escribe ninguno. Cuenta ambos modos y puedes ver cuándo DCR se ha quedado en silencio.

Decisiones a copiar

Cuenta el volumen, luego mide el silencio. Lee los contadores para saber cuánto tráfico legacy llegó. Necesitas la última llegada para decidir sobre la eliminación. mcp.protocol.legacy.days_since_last_operation lee el registro cuando el recopilador hace el raspado, así que no lo recalculas en la ruta de solicitudes. Alerta cuando el indicador supere 30.

Pon los nombres de método en la métrica. Pon los nombres de cliente en el registro. mcp_method es una etiqueta, así que cada valor nuevo crea otra serie, y un llamador no autenticado elige el valor. STANDARD_METHODS en factory.ts es una lista de permitidos: cualquier cosa no reconocida se registra como unknown. Los nombres de cliente no tienen límite, así que van a SQLite. Un nombre más cuesta una fila.

Mantén ambos límites. Una muestra mínima evita que apruebes la eliminación en una tarde tranquila. Un mínimo de días activos evita que la apruebes en un martes ajetreado que se perdió el trabajo por lotes semanal.

Sirve ambas eras sin sesión. createMcpHandler se ejecuta con legacy: 'stateless'. Una fábrica sirve ambas eras y ctx.era nombra el carril. Cualquier instancia puede responder a cualquier solicitud, así que escribes el contador. No necesitas una tabla de sesiones ni enrutamiento fijo. Una alternativa con estado te obligaría a instrumentar sesiones. El informe dependería entonces del balanceador de carga.

Nombres de cliente por era

Una solicitud moderna nombra a su llamador. Una solicitud legacy nombra al llamador una vez, durante initialize.

El sobre moderno repite clientInfo en params._meta en cada solicitud, así que cualquier instancia puede servirlo. El carril legacy pone el nombre en el protocolo de saludo. Un servidor sin estado no tiene dónde guardarlo para la llamada a herramienta que sigue. factory.ts lee ambos. El informe puede nombrar a legacy-dashboard@0.9.4 porque ese nombre llegó en initialize, no en la llamada a herramienta que se cuenta.

Puedes enrutar una puerta de enlace por MCP-Method porque la solicitud se describe a sí misma. Atribuyes el tráfico sin sesión por esa misma razón.

activeDays agrupa por fecha UTC, así que un cliente cuyos usuarios trabajan por las tardes en EE. UU. puede caer en dos grupos. Las rutas de autenticación escriben los intentos de DCR y CIMD. No acuñan tokens ni recuperan documentos CIMD.

Configuración

GET /metrics/lanes?windowDays=30 acepta la misma ventana, hasta 90 días.

Para ver que el registro sobrevive a un reinicio: ejecuta traffic, detén el servidor, vuelve a iniciarlo, ejecuta pnpm report. Los recuentos permanecen.

pnpm collector mantiene la telemetría en autotel.db durante 30 días. El servidor mantiene la evidencia en .data/migration-evidence.db durante 90. Git ignora ambos.

Servidor de doble era

El servidor es de doble era porque createMcpHandler se ejecuta con legacy: 'stateless', y ctx.era nombra el carril que cuentas. Consulta el registro de cambios para el resto del conjunto de cambios de 2026-07-28.

autotel-mcp-instrumentation añade tramos e histogramas de duración en ambos lados. Respondes a la pregunta de eliminación desde los contadores y el registro.

Mapa de código

Verificación

pnpm typecheck
pnpm test

Trece pruebas cubren el sesgo de proporción, el filtrado por ventana, la persistencia tras reinicio, los resultados de autenticación, la atribución de clientes, los recuentos de métodos legacy y ambos límites de eliminación.