Observabilidade do MCP: Construir um contrato de saúde de cinco camadas

A observabilidade do MCP deve responder a uma pergunta mais difícil do que ou a solicitação retornar? Para cada sessão do Protocolo de Contexto Modelo, preservar uma cadeia de evidências correlacionadas da autorização e inicialização através da descoberta de ferramentas, invocação, efeito externo e resultado esperado do usuário. Uma resposta verde tools/call é apenas um elo nessa cadeia. O incumprimento razoável é um contrato de saúde de cinco camadas: 1. Session: O cliente e o servidor negociaram uma versão de protocolo suportada e as capacidades que esta execução usará? 2. Catalog: O cliente leu a lista completa de ferramentas atuais e reagiu a um sinal de mudança de lista posterior? 3. Request: Você pode participar do pedido JSON RPC, notificações de progresso, cancelamento, resposta e prazo? 4. EEffect: Se a ferramenta alterar um sistema externo, há evidências de destino para o que realmente aconteceu? 5. Ooutcome: fez o artefato, mudança de estado, ou decisão que o agente deveria produzir passar seu verificador? Este contrato separa deliberadamente a actividade do protocolo do progresso útil. Além disso, dá ao operador um estado concreto para encaminhar: needs auth , incompatible session , stale catalog , working , protocol error , tool failed , effect unknown , false success , ou healthy . Comece com uma cadeia de evidências, não um número de painel. Os novos resultados dos EUA para mcp observabilidade enfatizam sessões, conexões, análise de ferramentas, latência de transporte, throughput e erros. São úteis. O Documentação de observabilidade do MCP atual da Grafana lista o estabelecimento de sessões, a estabilidade da conexão, o cumprimento do protocolo, o desempenho das ferramentas e a confiabilidade do transporte. A diferença não é que estes sinais sejam errados. A diferença é que nenhum deles, sozinho, prova que o trabalho pretendido do agente atingiu o seu destino. Um registo de saúde pode ficar compacto: Os hashes são identificadores, não permissão para carregar esquemas de ferramentas, argumentos, instruções, tokens ou conteúdo devolvido. Mantenha valores sensíveis no anfitrião. Registrar os menores campos necessários para correlacionar o estado e provar a decisão. O contrato deve igualmente ter uma regra de prioridade. A falha de autorização ocorre antes da saúde da sessão; uma sessão incompatível ocorre antes da frescura do catálogo; um catálogo não resolvido ocorre antes da interpretação da solicitação; um tempo de transporte em um limite de efeitos colaterais torna se effect unknown , não uma retomada automática; e uma chamada bem sucedida com um produto faltante torna se false success , não saudável. Tornar o estado do protocolo observável antes de medir a latência da ferramenta O MCP especificação do ciclo de vida faz com que a inicialização seja a primeira interação cliente servidor. Os dois lados acordam numa versão de protocolo, trocam capacidades e entram em operação normal. O mesmo documento diz que a comunicação posterior deve respeitar a versão negociada e as capacidades. Isso dá à observabilidade um primeiro ponto de controle limpo: armazenar a versão solicitada, versão aceita, conjunto de capacidades e o momento em que o cliente enviou o notifications/initialized . Não colapse cada falha antes desse ponto em server down. Para os transportes HTTP, a autorização é um portal separado. A atual Especificação da autorização do MCP define a descoberta de recursos protegidos e exige que os clientes lidem com um desafio 401 Unauthorized . Um servidor pode ser acessível e correto enquanto o cliente não tem um token, tem o escopo errado ou não pode descobrir o servidor de autorização. Route que como needs auth ; não o pague como uma interrupção de transporte. A descoberta de ferramentas precisa de sua própria prova de integridade. O especificação das ferramentas diz que o tools/list está paginado e que os servidores que declaram o listChanged podem emitir o notifications/tools/list changed . Portanto, recebemos uma página não é um catálogo novo. Registo: A capacidade de inicialização que anuncia as ferramentas; Cada cursor de paginamento até que não permaneça nenhum nextCursor ; Um hash canônico de nomes e esquemas de entrada/saída; O último período de atualização bem sucedido; Qualquer notificação tools/list changed e a atualização que lhe tenha seguido. Isto é mais estreito do que registrar todos os esquemas. Um cliente pode calcular o hash localmente e reter apenas o hash, contagem de ferramentas, contagem de páginas e atualização de evidências. Classificar a sessão stale catalog se for recebida uma notificação de alteração e a atualização não for efetuada. O servidor ainda pode responder a pings, mas o modelo pode estar a escolher entre um contrato de ferramentas obsoleto. Chamadas de longa duração introduzem outra armadilha. O MCP Notificações de progresso utiliza um token fornecido por pedido que deve ser único entre os pedidos ativos; os valores de progresso devem aumentar e as notificações devem parar após a conclusão. Essa evidência pode justificar o working enquanto a chamada estiver dentro do prazo máximo. Não prova que o trabalho seja útil e nunca deve prolongar o prazo para sempre. Uma mensagem repetida sem valor de aumento, um token anexado ao pedido errado, ou o progresso após uma resposta terminal são evidências inconsistentes. Use dois relógios: Uma janela de inatividade, que pode ser reiniciada para um progresso monótono válido; um prazo máximo absoluto, que não é reiniciado. Esta distinção impede dois erros opostos: matar o trabalho longo legítimo porque ainda não voltou, e aceitar um fluxo interminável de notificações de progresso como saúde. Uma chamada de ferramenta bem sucedida não é o resultado O MCP distingue os erros de protocolo dos erros de execução da ferramenta. De acordo com a especificação das ferramentas, pedidos mal formados e ferramentas desconhecidas usam erros JSON RPC, enquanto falhas de negócios ou de entrada podem retornar um resultado da ferramenta com isError: true . Mantenha esses estados separados porque a ação seguinte é diferente: fixar o contrato do cliente para protocol error ; ajustar entradas, permissões ou a dependência a jusante para tool failed . O caso mais perigoso é a ausência de resposta depois de um efeito colateral ter ocorrido. Suponha que publish report vezes fora. A repetição imediata pode criar um relatório duplicado porque a incerteza do transporte não diz nada sobre o destino. Marque a chamada effect unknown , conciliar usando uma chave de operação estável ou consulta de destino e tentar novamente somente depois que as evidências comprovam que a primeira tentativa não foi cometida. Mesmo um resultado normal não é suficiente. O servidor pode devolver isError: false enquanto o arquivo prometido estiver ausente, o registro remoto ainda seja um rascunho, ou o URL seja privado. Adicione um verificador de resultados escolhido antes da chamada: hash de arquivo, linha de banco de dados mais versão, status público HTTP, resultado do teste ou outro recibo determinista. Use um juiz LLM apenas quando o resultado não puder ser verificado diretamente, e etiquete essa evidência mais fraca. Isto cria três estados distintos de aparência terminal: Resultado do protocolo Efeito de destino Resultados esperados Estado de saúde tempo de descanso desconhecido desconhecido effect unknown sucesso verificado falhou ou desapareceu false success sucesso verificado verificado healthy A fila do meio é a mais importante. Isso impede que uma troca de protocolo bem sucedida se torne uma alegação falsa de que o agente completou a tarefa do usuário. Repete o contrato contra casos inconvenientes O artefacto que acompanha é uma fixação ilustrativa de nove casos e um classificador determinista. Não contém telemetria de produção. Faça isso com: A fixação abrange uma exportação saudável e oito limites inconvenientes: um desafio de autorização, versão de protocolo não suportada, alteração não reconciliada da lista de ferramentas, chamada de longa duração com progresso válido, chamada malformada, erro de execução da ferramenta, prazo após um possível efeito colateral e sucesso com um produto faltante. O classificador devolveu um caso em cada estado esperado: Esta é a parte falsificável do método: alterar a evidência e o estado deve mudar de forma previsível. Se a tools/list changed for seguida de uma atualização completa, o caso de catálogo obsoleto deve avançar. Se a chamada com prazo expirado receber um recibo de destino, mas o seu verificador de entrega falhar, ele deve passar de effect unknown para false success . Ele chega a healthy somente quando a sessão, o catálogo, a solicitação, o efeito e a evidência do resultado estão todos de acordo. O artefacto não valida se a semântica empresarial de uma ferramenta é correta. Não descobre um efeito colateral não documentado, não prova que um emissor de OAuth é digno de confiança nem decide quanto tempo o seu prazo deve ser. Estas são revisões específicas de implantação. O seu trabalho é menor: evitar que as provas faltantes sejam silenciosamente tornadas verdes. Alerta sobre o estado que precisa de ação Não envie todos os estados não saudáveis para o mesmo canal. O needs auth vai ao proprietário da credencial ou autorização com o recurso contestado e o escopo exigido, nunca o valor do token. incompatible session vai para o proprietário da integração com versão do cliente, versão do servidor e recursos negociados. stale catalog desencadeia uma tentativa de redescoberta limitada; falha repetida se torna um incidente de integração. A working permanece em silêncio enquanto o progresso é válido e o prazo absoluto permanece. O protocol error vai para o implementador do cliente com o método, o identificador de solicitação e a classe de erro desinfetada. O tool failed segue a política de retestamento da ferramenta apenas quando se sabe que a falha é reversível. O effect unknown bloqueia automaticamente a retestada na fronteira do efeito colateral e inicia a reconciliação. O false success abre um incidente de resultado, mesmo que o próprio MCP tenha concluído. Este roteamento mantém o waiting distinto do stuck. Um prompt de autorização atribuído a uma pessoa pode ser uma espera legítima; um token de progresso avançando dentro de um pedido limitado pode ser trabalho; um catálogo inalterado após um sinal de mudança de lista não é nenhum. Comece com uma única ferramenta de alto valor e um verdadeiro verificador de resultados. Capturar a cadeia durante uma semana, inspecionar todos os estados desconhecidos, depois adicionar cobertura. Um painel perfeito para toda a frota construído em eventos não correlacionados é menos útil do que uma chamada de ferramenta cuja sessão, efeito e resultado podem ser explicados de ponta a ponta. Quando este contrato cessar A observabilidade do MCP pode estabelecer protocolos e evidências operacionais, mas não pode inferir toda a intenção do usuário do fio. Um esquema de saída válido prova forma, não verdade. Um recibo de destino prova um efeito, não que o efeito foi sábio. Um sinal de progresso monótono prova o movimento relatado pelo servidor, não um progresso útil para o objetivo do usuário. Esses limites exigem controles de aplicação e, às vezes, julgamento humano. A Sidewisp está atualmente em prévia privada. Os seus adaptadores de monitorização da produção e sistemas de recuperação não são geralmente enviados. O contrato referido no presente artigo é um método de operação e um artefato local inspecionável, não uma alegação de que a Sidewisp já recolha ou repara sessões de MCP. A direcção do produto pretendida é facilitar a visualização das evidências de saúde, incertezas e limites de aprovação ao lado dos tempos de execução existentes. Se você está projetando uma integração de MCP agora, mantenha o registro de cinco camadas local, redigir o conteúdo e recusar se a chamar uma corrida saudável até que o resultado esperado tenha seu próprio recebimento. Essa única regra transforma a telemetria do protocolo numa decisão operacional em vez de outro gráfico verde.