AI Observabilidade do Agente para MCP Mudanças de Ferramentas: Prove Discovery Converged

Um agente AI que utiliza ferramentas MCP não é saudável simplesmente porque o seu processo está vivo, a sua conexão com o servidor está aberta ou recebeu uma notificação de alteração da lista de ferramentas. A verificação prática é mais rigorosa: após uma alteração relevante, o cliente completou uma nova travessia tools/list , seguiu a paginação até o fim e substituiu o seu registo com as definições exatas da ferramenta que descobriu? Trata isso como um teste de convergência. Registre a versão negociada do protocolo MCP e a capacidade de tools.listChanged , o último tempo de notifications/tools/list changed , os tempos de início e conclusão da descoberta, cada cursor e digestões canônicas dos registros descobertos e instalados. Retorno converged , stale , incomplete ou unverifiable . Não transforme a falta de provas num resultado verde. Defina a convergência na fronteira do protocolo O Especificação do ciclo de vida do MCP requer inicialização antes da operação normal. O cliente e o servidor negociam uma versão de protocolo e capacidades, e ambos os lados devem respeitar essa negociação. Uma inicialização bem sucedida prova que uma sessão começou sob um contrato acordado. Não prova que uma alteração posterior da ferramenta tenha atingido o cliente. O Especificação das ferramentas MCP fornece as seguintes peças: Um servidor que suporta ferramentas declara a capacidade tools ; A listChanged indica se emitirá notificações de alteração da lista de ferramentas; Os clientes descobrem definições através do tools/list ; a descoberta pode ser paginada através do nextCursor ; Uma definição de ferramenta inclui mais do que o seu nome, nomeadamente o inputSchema e o opcional outputSchema , anotações e metadados de execução. Isto cria três acontecimentos separados que o controlo não deve desmoronar: 1. Câmbio de sinal: O cliente recebe notifications/tools/list changed . 2. Descoberta: inicia uma nova travessia tools/list e atinge uma resposta cujo nextCursor está ausente ou nula. 3. Registry install: As definições usadas pelo cliente correspondem ao instantâneo de descoberta concluído. A notificação é uma indicação para atualizar, não um recibo para atualizar completado. A primeira página é uma atividade, não um registo completo. Os nomes correspondentes não são contratos correspondentes quando um argumento, esquema de saída ou propriedade de execução exigidos são alterados. Mantenha as provas pequenas, mas decisivas Um histórico de saúde útil não precisa de instruções, argumentos de ferramentas, credenciais ou resultados de ferramentas. Precisa de metadados seguros suficientes para responder se o cliente e o servidor ainda concordam: Campo O que estabelece O que não estabelece protocolVersion A versão do MCP negociada para a sessão Que uma versão posterior do servidor permaneceu compatível tools.listChanged Se foram negociadas as notificações de alteração Que qualquer notificação foi entregue ou tratada notificationAt Foi preciso um refresco . A descoberta começou. discoveryStartedAt e discoveryCompletedAt Uma atualização limitada correu após o sinal Que todas as páginas foram recolhidas cadeia de cursores A paginação terminou sem um espaço . Que o cliente instalou o resultado Digest de registro descoberto Identidade do conjunto completo de definições Que uma chamada de ferramenta terá sucesso Digest do registo de clientes Identidade do que o cliente expõe atualmente ao agente Que o agente escolha corretamente Construa o digesto a partir de uma projeção estável: name , title , description , inputSchema , outputSchema , annotations e execution . Ordenar as ferramentas por nome e canonizar o JSON aninhado antes do hashing. Os ícones decorativos podem ser excluídos se não afetarem a seleção ou execução, mas a própria projeção deve ser versão. RFC 8785 explica por que o hashing repetível requer serialização invariante JSON e triagem de propriedades recorrentes. O ordenador recursivo compacto utilizado neste experimento é adequado para os valores ordinários JSON da fixação; não é apresentado como uma implementação completa do JCS. O código de produção deve utilizar uma biblioteca de canonização revisada, especialmente quando os casos de borda numérica ou as assinaturas importam. Não armazenar segredos crus no instantâneo do registo. Os esquemas de ferramentas devem descrever as formas dos argumentos e não os valores de credenciais. Se uma descrição contém dados de inquilinos ou caminhos internos, redigir antes de coletar e registrar qual versão de projeção produziu o digesto. Reproduzir uma auditoria do registo de seis casos A fixação conservada utiliza seis observações sintéticas: Uma linha de base completa de duas páginas; uma remoção da ferramenta seguida de uma atualização completa; Uma notificação de alteração seguida de nenhuma nova descoberta; a primeira página com um nextCursor restante; o mesmo nome da ferramenta com um esquema de entrada obrigatória alterado; um servidor que não tenha anunciado o listChanged , sem provas de atualização limitadas. A ordem de decisão central é importante: Execute o dispositivo com Node.js: A reprodução exacta voltou: Os contraexemplos são mais úteis do que os dois casos verdes. O notification without refresh tem identico descoberto e digestação do cliente, mas a sua descoberta foi concluída antes do sinal de mudança. Uma coincidência digestiva com uma imagem antiga ainda está ultrapassada. O unfinished pagination também tem digestões correspondentes para a página observada, mas o nextCursor permanece. Uma coincidência plausível da primeira página é uma evidência incompleta. O caso do mesmo nome altera o read ticket de exigir apenas o ticketId para exigir tanto o projectId quanto o ticketId . Um inventário apenas de nome declararia o registo inalterado. A definição canônica de digest muda de c42521a2412558ca para c3837b93f14b688f , então a definição antiga do cliente é classificada como obsoleta. Transforme o veredicto em uma decisão operacional . Use o converged de forma estreita. Significa que o registo de clientes observado corresponde a uma descoberta totalmente atravessada concluída após o sinal de mudança relevante. Não demonstra a acessibilidade do transporte para a próxima chamada, autorização válida, comportamento correto da ferramenta, um efeito externo bem sucedido ou o resultado da tarefa pretendida. Manter os outros estados sem automação agressiva: O veredicto Evidências Seguro, próximo passo. stale A atualização é mais antiga do que o sinal, ou os registos diferem Pare de selecionar a definição afectada; solicite uma atualização limitada; inspecione antes de retomar o trabalho consecutivo incomplete A descoberta iniciada , mas falta evidência de percorrência ou conclusão do cursor . Resume do cursor esperado se o cliente o suportar, caso contrário reinicie a descoberta uma vez unverifiable Não há evidências de descobertas limitadas . Relatar o sinal como indisponível; reconnectar ou programar uma atualização controlada de acordo com a política de tempo de execução converged Descoberta completa após a mudança e correspondência exata da digestão Continuar, mantendo as verificações separadas de chamada, efeito e resultado Se o servidor não anunciar o listChanged , o silêncio é esperado e não pode estabelecer a frescura. Definir uma alternativa limitada: atualizar na reconexão, antes de uma corrida de alto impacto, ou em um intervalo medido que corresponda aos limites de custo e taxa do servidor. Registrar essa política para que no notification não seja confundido com no change. Também separar a saúde do registo da saúde da tarefa. Uma ferramenta pode estar presente e ser descrita corretamente enquanto a sua credencial tiver expirado. Pode devolver o isError: false enquanto o bilhete, arquivo ou implantação prometido estiver ausente. Após qualquer recuperação aprovada, verifique o efeito externo ou o resultado da tarefa em vez de declarar sucesso porque a descoberta ou um comando foram concluídos. Preservar o limite do produto e da autoridade Esta verificação pertence à observabilidade do agente AI porque a disponibilidade da ferramenta e a deriva de permissão podem bloquear o progresso útil enquanto o agente permanece ativo. É um sinal de saúde, não uma autorização para reiniciar um tempo de execução, rotar credenciais, invocar ferramentas ou repetir gastos. A intervenção consequente deve permanecer limitada, visível e sujeita à aprovação humana. A direcção prevista do Sidewisp é uma camada de saúde em torno dos tempos de execução dos agentes existentes: mostrar evidências, frescura, gravidade, incerteza e a próxima ação mais segura. O registo de convergência do MCP neste artigo é um padrão operacional e um experimento, não uma alegação de que o Sidewisp o recolha atualmente. A Sidewisp está atualmente em prévia privada. O site público e o sistema de artigos estão em directo. A coleta de agentes de produção saúde, adaptadores de tempo de execução MCP, recuperação automatizada, gerenciamento de cron e análise de custos de token geralmente não são enviados. Junte se à prévia privada se quiser ajudar a moldar contratos de evidências, como negociação de protocolo, convergência de registro, disponibilidade de ferramentas e resultados verificados, mantendo a autoridade humana explícita.