Observabilidad del MCP: Construir un contrato de salud de cinco capas

La observabilidad de MCP debe responder a una pregunta más difícil que ha devuelto la solicitud? Para cada sesión del Protocolo de Contexto Modelo, preserva una cadena de pruebas correlacionadas desde la autorización e inicialización a través del descubrimiento de herramientas, la invocación, el efecto externo y el resultado esperado del usuario. Una respuesta verde tools/call es sólo un eslabón en esa cadena. El incumplimiento razonable es un contrato de salud de cinco capas: 1. Session: ¿El cliente y el servidor negocian una versión de protocolo compatible y las capacidades que utilizará esta ejecución? 2. Catalog: ¿El cliente leyó la lista completa de herramientas actuales y reaccionó a una señal posterior de cambio de lista? 3. Request: ¿Puede unirse a la solicitud JSON RPC, notificaciones de progreso, cancelación, respuesta y fecha límite? 4. EEffect: si la herramienta cambia un sistema externo, ¿hay evidencia de destino para lo que realmente sucedió? 5. O Resultado: ¿El artefacto, el cambio de estado o la decisión que se suponía que el agente producía pasaron su verificador? Este contrato separa deliberadamente la actividad del protocolo del progreso útil. También proporciona al operador un estado de concreto para el enrutamiento: needs auth , incompatible session , stale catalog , working , protocol error , tool failed , effect unknown , false success o healthy . Comience con una cadena de pruebas, no un número de tablero Los nuevos resultados de EE.UU. para mcp observabilidad enfatizan sesiones, conexiones, análisis de herramientas, latencia de transporte, rendimiento y errores. Esos son útiles. El Documentación de observabilidad del MCP actual de Grafana incluye el establecimiento de la sesión, la estabilidad de la conexión, el cumplimiento del protocolo, el rendimiento de la herramienta y la confiabilidad del transporte. La brecha no es que estas señales estén equivocadas. La brecha es que ninguno de ellos, por sí solo, prueba que el trabajo previsto por el agente haya alcanzado su destino. Un expediente médico puede mantenerse compacto: Los hashes son identificadores, no permiso para subir esquemas de herramientas, argumentos, instrucciones, tokens o contenido devuelto. Mantenga valores sensibles en el anfitrión. Registrar los campos más pequeños necesarios para correlacionar el estado y probar la decisión. El contrato también debe tener una regla de prioridad. El fallo de autorización se produce antes de la salud de la sesión; una sesión incompatible se produce antes de la frescura del catálogo; un catálogo no resuelto se produce antes de la interpretación de la solicitud; un tiempo de transporte en un límite de efectos secundarios se convierte en effect unknown , no en un retiro automático; y una llamada exitosa con un entregable faltante se convierte en false success , no saludable. Hacer que el estado del protocolo sea observable antes de medir la latencia de la herramienta El MCP especificación del ciclo de vida hace que la inicialización sea la primera interacción cliente servidor. Las dos partes acuerdan una versión del protocolo, intercambian capacidades y luego entran en funcionamiento normal. El mismo documento dice que la comunicación posterior debe respetar la versión y las capacidades negociadas. Eso da a la observabilidad un primer punto de control limpio: almacenar la versión solicitada, la versión aceptada, el conjunto de capacidades y el momento en que el cliente envió notifications/initialized . No derrumbe cada falla antes de ese punto en server down. Para los transportes HTTP, la autorización es una puerta separada. La actual Especificación de la autorización del MCP define el descubrimiento de recursos protegidos y requiere que los clientes manejen un desafío 401 Unauthorized . Un servidor puede ser accesible y correcto mientras que el cliente carece de un token, tiene el alcance equivocado o no puede descubrir el servidor de autorización. Ruta que como needs auth ; no lo pague como una interrupción de transporte. El descubrimiento de herramientas necesita su propia prueba de integridad. El especificación de las herramientas dice que tools/list está paginado y que los servidores que declaran listChanged pueden emitir notifications/tools/list changed . Por lo tanto, recibimos una página no es un catálogo nuevo. Registro: la capacidad de inicialización de las herramientas anunciadas; cada cursor de paginado hasta que no quede nextCursor ; un hash canónico de nombres y esquemas de entrada/salida; el último tiempo de actualización exitoso; cualquier notificación tools/list changed y la actualización que la siguiera. Esto es más estrecho que registrar todos los esquemas. Un cliente puede calcular el hash localmente y conservar solo el hash, el conteo de herramientas, el conteo de páginas y la actualización de la evidencia. Si llega una notificación de cambio y la actualización falla, clasifique la sesión stale catalog . El servidor puede seguir respondiendo pings, pero el modelo podría estar escogiendo de un contrato de herramientas obsoleto. Las llamadas de larga duración introducen otra trampa. El MCP Notificaciones de progreso utiliza un token proporcionado por solicitud que debe ser único entre las solicitudes activas; los valores de progreso deben aumentar y las notificaciones deben detenerse después de su finalización. Dichas pruebas pueden justificar a working mientras la llamada esté dentro de su plazo máximo. No demuestra que el trabajo sea útil, y nunca debe extender el plazo para siempre. Un mensaje repetido sin valor creciente, un token adjunto a la solicitud incorrecta o el progreso después de una respuesta terminal son pruebas inconsistentes. Utilice dos relojes: una ventana de inactividad, que puede reiniciar el progreso monótono válido; un plazo máximo absoluto, que no se restablece. Esta distinción evita dos errores opuestos: matar el trabajo legítimo de larga duración porque aún no ha regresado, y aceptar una corriente interminable de notificaciones de progreso como salud. Una llamada de herramienta exitosa no es el resultado El MCP distingue los errores de protocolo de los errores de ejecución de la herramienta. De acuerdo con la especificación de las herramientas, las solicitudes malformadas y las herramientas desconocidas utilizan errores JSON RPC, mientras que las fallas de negocio o de entrada pueden devolver un resultado de la herramienta con isError: true . Mantenga esos estados separados porque la siguiente acción es diferente: fijar el contrato de cliente para protocol error ; ajustar las entradas, permisos o la dependencia descendente para tool failed . El caso más peligroso es la falta de respuesta después de que pueda haber ocurrido un efecto secundario. Supongamos que publish report veces fuera. Intentar de nuevo inmediatamente puede crear un informe duplicado porque la incertidumbre del transporte no dice nada sobre el destino. Marque la llamada effect unknown , conciliar utilizando una clave de operación estable o una consulta de destino, y volver a intentarlo solo después de que la evidencia demuestre que el primer intento no se comprometió. Incluso un resultado normal no es suficiente. El servidor puede devolver isError: false mientras el archivo prometido está ausente, el registro remoto sigue siendo un borrador, o la URL es privada. Agregue un verificador de resultados elegido antes de la llamada: hash de archivo, fila de base de datos más versión, estado HTTP público, resultado de prueba u otro recibo determinista. Utilice un juez LLM sólo cuando el resultado no pueda ser verificado directamente, y etiquete la evidencia más débil. Esto crea tres estados de aspecto terminal distintos: Resultado del protocolo Efecto de destino Resultados esperados Estado de salud tiempo de descanso desconocido desconocido effect unknown el éxito verificado fallido o desaparecido false success el éxito verificado verificado healthy La fila media es lo más importante. Impide que un intercambio de protocolos exitoso se convierta en una afirmación falsa de que el agente completó la tarea del usuario. Repite el contrato contra casos incómodos El artefacto que acompaña es una fijación ilustrativa de nueve casos y un clasificador determinista. No contiene telemetría de producción. Ejecutar con: La fijación cubre una exportación saludable y ocho límites inconvenientes: un desafío de autorización, una versión de protocolo no compatible, un cambio no reconciliado de la lista de herramientas, una llamada de larga duración con un progreso válido, una llamada malformada, un error de ejecución de la herramienta, un tiempo de espera después de un posible efecto secundario y un éxito con un producto faltante. El clasificador devolvió un caso en cada estado esperado: Esta es la parte falsificable del método: cambiar la evidencia y el estado debe cambiar de manera predecible. Si a tools/list changed le sigue una actualización completa, el caso de catálogo obsoleto debe avanzar. Si la llamada terminada obtiene un recibo de destino pero su verificador de entrega falla, debe pasar de effect unknown a false success . Llega a healthy solo cuando la sesión, el catálogo, la solicitud, el efecto y la evidencia de resultado coinciden. El artefacto no valida si la semántica empresarial de una herramienta es correcta. No descubre un efecto secundario no documentado, prueba que un emisor de OAuth es confiable, ni decide cuánto tiempo debe ser su plazo. Esas son revisiones específicas del despliegue. Su tarea es menor: evitar que las pruebas faltantes sean silenciosamente verdes. Alerta sobre el estado que necesita acción No envíe todos los estados no saludables al mismo canal. needs auth va al titular de la credencial o autorización con el recurso desafiado y el alcance requerido, nunca el valor del token. incompatible session va al propietario de la integración con la versión del cliente, la versión del servidor y las capacidades negociadas. stale catalog desencadena un intento de redescubrimiento limitado; el fracaso repetido se convierte en un incidente de integración. working permanece en silencio mientras el progreso sea válido y el plazo absoluto permanezca. protocol error va al implementador del cliente con el método, el identificador de solicitud y la clase de error desinfectado. tool failed sólo sigue la política de retoma de la herramienta cuando se sabe que el fallo es reversible. effect unknown bloquea automáticamente el retiro en el límite del efecto secundario y inicia la reconciliación. false success abre un incidente final a pesar de que el MCP mismo se haya completado. Este enrutamiento mantiene waiting distinto de stuck. Un prompt de autorización asignado a una persona puede ser una espera legítima; un token de progreso que avance dentro de una solicitud limitada puede ser un trabajo; un catálogo sin cambios después de una señal de cambio de lista no es ninguna. Comience con una sola herramienta de alto valor y un verificador de resultados real. Captura la cadena durante una semana, inspeccione todos los estados desconocidos, luego añade cobertura. Un panel de control perfecto para toda la flota construido sobre eventos no correlacionados es menos útil que una llamada de herramienta cuya sesión, efecto y resultado se pueden explicar de extremo a extremo. Cuando este contrato cese La observabilidad de MCP puede establecer el protocolo y la evidencia operativa, pero no puede inferir toda la intención del usuario del cable. Un esquema de salida válido prueba la forma, no la verdad. Un recibo de destino demuestra un efecto, no que el efecto fue sabio. Una señal de progreso monótona demuestra el movimiento reportado por el servidor, no un progreso útil hacia el objetivo del usuario. Esos límites requieren controles de aplicación y, a veces, juicio humano. Sidewisp se encuentra actualmente en versión preliminar privada. Por lo general, no se envían sus adaptadores de monitoreo de producción y sus sistemas de recuperación. El contrato en este artículo es un método de operación y un artefacto local inspectable, no una afirmación de que Sidewisp ya recoge sesiones de MCP o las repara. La dirección del producto se pretende hacer que las pruebas de salud, la incertidumbre y los límites de aprobación sean más fáciles de ver junto con los tiempos de ejecución existentes. Si está diseñando una integración de MCP ahora, mantenga el registro de cinco capas local, redacte el contenido y se niegue a llamar una carrera saludable hasta que el resultado esperado tenga su propio recibo. Esa regla única convierte la telemetría del protocolo en una decisión operativa en lugar de otra tabla verde.