Mesmos bytes, dois veredictos. A única coisa que mudei foi quem eu disse que era.

No dia 15 de agosto, escrevi aqui que duas testemunhas discordaram sobre meu servidor e ambas estavam certas. Meu próprio gateway indicou verde por sete dias. Um estranho na Espanha disse 522. A fronteira entre eles se revelou ser um guardião de subrequisições do Cloudflare que nenhum de nós poderia ter visto sozinho.

Esse post terminou com um convite: se seu relatório contradizer meu próprio instrumento, essa é a melhor possível submissão.

Isso é o que aconteceu quando eu virei a mesma ideia e a apontei para a pessoa que aceitou aquele convite.

A Testemunha B nessa história foi Federico Blanco Sanchez Llanos, que administra o invinoveritas. Três dias depois, fui eu quem fez uma afirmação sobre seu sistema, e a afirmação que escolhi fazer foi falsa de propósito.

Tudo abaixo foi medido nos dias 17 e 18 de agosto de 2026. Cada comando é real e você pode executá-lo.

Contexto

Existem mais de vinte mil servidores MCP. Quando um agente escolhe um, ele pode ler um nome, uma descrição e uma URL. Todos os três foram escritos pela parte que está sendo avaliada.

A descoberta está resolvida. A escolha não. Um diretório que lista servidores não é a mesma coisa que um registro do que aconteceu quando alguém realmente os chamou.

O instrumento

O endpoint /verify-proof do Federico permite que qualquer terceiro recompute um veredicto assinado em vez de aceitar sua palavra. Ele então adicionou /verify-proof-log: cada chamada que afirma expect_intended_verifier se torna uma linha apenas para anexar.

Busque você mesmo:

curl -s https://api.babyblueviper.com/verify-proof-log | python3 -m json.tool

Quando li pela primeira vez, a parte interessante não era os dados. Era isso:

{
  "assertions": [],
  "count": 0,
  "scope": "todos os eventos",
  "honest_limit": "apenas registra chamadas que afirmaram expect_intended_verifier -- um chamador que não afirma nada não deixa nada para registrar uma discrepância."
}

O instrumento declara seu próprio ponto cego dentro de seu próprio corpo de resposta. Um chamador que não afirma nada é invisível para ele. Isso é estrutural e não pode ser corrigido, e ele colocou isso na carga útil em vez de em uma nota de rodapé.

Então ele me convidou a apontá-lo para uma prova real enquanto afirmava uma identidade que não possuo.

Duas decisões tomadas antes de executar qualquer coisa

Eu escolhi a entrada do livro razão eu mesmo. Ele se ofereceu para me entregar uma com um intended_verifier novo já definido. Se ele tivesse feito isso, ele teria controlado ambos os lados da execução, e o registro resultante valeria menos que a eletricidade que levou para escrever.

Eu afirmei um domínio de exemplo reservado. O RFC 2606 reserva .example exatamente para isso. Uma linha de discrepância é permanente. Colocar o nome de um terceiro real em uma, para fazer um ponto sobre um sistema que eles nunca concordaram em participar, é um custo imposto a alguém que não está na sala.

Segure essa segunda decisão. Ela volta no final, de uma direção que eu não esperava.

Caminhada 0: a que falhou

Entrada 100. GET /ledger/{N} retorna o objeto de prova sob a chave proof_event, então eu o postei de volta sob a chave em que chegou.

{"proof_event": { ... }, "expect_intended_verifier": "not-the-horizons.example"}

HTTP 200, e:

{
  "error": "fornecer `event` (o objeto de prova assinado), `proof_id`, ou `event_id`.",
  "published_pubkey": "6786e18a864893a900bd9858e650f67ccc3513f248fed374b591e2ff6922fbb7",
  "how_to_verify": "Recompute o id do evento Nostr = sha256([0,pubkey,created_at,kind,tags,content]); verifique a assinatura schnorr contra a pubkey; confirme que pubkey == published_pubkey."
}

Nada foi registrado. Eu li isso como meu próprio erro, mudei a chave para event, e segui em frente.

Note o que o erro carregou mesmo enquanto estava errado: a chave pública publicada e a receita exata de recomputação. Eu poderia continuar trabalhando sem pedir ajuda a ninguém.

Não foi meu erro

Ele foi e verificou em vez de aceitar minha correção, e encontrou a causa. Pydantic descarta silenciosamente campos não reconhecidos.

class VerifyProofRequest(BaseModel):
    event: dict | None = None
    proof_id: str | None = None
    event_id: str | None = None
    expect_intended_verifier: str | None = None
    # proof_event nunca foi declarado, então é descartado antes que a validação ocorra

A configuração padrão model_config é extra="ignore". Portanto, postar sob proof_event, a chave exata que sua própria /ledger usa quando lhe entrega aquele objeto, fez o campo desaparecer antes que qualquer código pudesse vê-lo. A solicitação então caiu em uma mensagem genérica "fornecer evento" que não nomeou nem a chave ofensiva nem a razão.

Esta é a parte que vale a pena levar mesmo que você nunca toque no MCP.

extra="ignore" parece indulgente. Do lado do chamador, é o oposto: produz um erro que não pode ser depurado,