Servidor MCP de Protocol Company

• Nome no registrocom.zerotrustphysics/verifierverificado no registro MCP

O nome no registro fica sob zerotrustphysics.com. O registro só libera esse espaço de nomes para quem prova controle do domínio por DNS ou HTTP.

• Estadorespondeverificado em 2026-10-27
• Ferramentas18
• O servidor se chamaZero-Trust Physics
• Versão do servidor0.15.2
• Versão do protocolo2025-06-18

Em 2026-10-27 o servidor respondeu a initialize e tools/list sem login. Primeira resposta em 72 ms.

• Ainda não avaliamos se as ferramentas fazem o trabalho do produto.

Dito por regras a partir das medições acima. A primeira chamada provável é a escolha de um modelo na lista de ferramentas; leia a descrição antes de confiar nela.

• Nota INITE MCP91 de 100responde 100 · definições 95 · contexto 51 · conexão 100
• Respondeuem 100% dos dias8 de 8 verificações diárias
• Mediana da primeira resposta72 ms
• Espaço no contexto do agente≈ 18.295 tokensas definições de todas as ferramentas (18), que o agente carrega a cada turno
• Definições das ferramentasA · 95 de 100
• Resultados tipados0 de 18 ferramentasdeclaram outputSchema: o resultado chega tipado e é lido de uma vez

• Parâmetros sem tipo: em 1 de 18
• Parâmetros sem descrição: em 4 de 18

Um programa verifica o servidor uma vez por dia: initialize e tools/list, sem modelo. Os tokens são o tamanho das definições, a cerca de quatro caracteres por token. A nota é a média de seis verificações do nome, da descrição, do esquema e das anotações de cada ferramenta; diz se as ferramentas estão bem descritas, não se funcionam. A nota pesa só o que foi medido: se responde (25%), se faz o trabalho do produto (25%), definições (20%), contexto (10%), uso (10%) e a facilidade de conectar (10%). Uma parte não medida fica de fora, e uma instrução oculta limita a nota a 40. O estado dos servidores MCP dos fornecedores: método e números →

• list_cards

  Lists every domain and card this connection serves, each with one sentence, and count, how many there are. against_measurement names the evidence behind the model, in one of three words: "compared with measurement" (a real object; its…

• describe_card

  Describes one domain and card pair: inputs, units, bounds, step limits, reject names and meanings, advisory flags, frame slots, and worked examples. With form "short" the answer is a page, enough to write a first request: what the model…

• compute_step

  Computes one anchored step of one card and returns the state it lands on, in decimals and exact hex, with its cryptographic proof (sha384_seal) and a receipt. parameters holds the card's phase fields, its load fields and dt_s, as…

• run_trajectory

  Runs one card from a start state through segments of steps, each under its own load, and seals the run. The answer holds the outcome, the final state in decimals and exact hex, a frame for each recorded step, the run_seal and a receipt…

• verify_tape

  Verifies the seal of a run. Short form, which needs only what is short: request is the run_trajectory request as it was sent, with its readout and its from, whose request has none, when it had them (the answer's inputs holds neither), and…

• list_solvers

  Lists every field solver this connection serves, each with one sentence, and count, how many there are. against_measurement names the evidence behind the model, in one of three words: "compared with measurement" (a real object; its…

• describe_solver

  Describes one solver: inputs and bounds, outputs, invariants and tolerances, refusal names and meanings, the published reference, and a worked example. With form "short" the answer is a page, enough to write a first request: what the…

• solve

  Solves one field problem with one solver and seals the solution: the outcome, the result in decimals and exact hex, its invariants, the solution_seal and a receipt. parameters holds the solver's inputs as describe_solver gives them…

• verify_solution

  Verifies the seal of a solution. Short form, which needs only what is short: request is the solve request as it was sent (the answer's inputs), and solution_seal is the seal its answer gave. The request is solved again, under a physics…

• run_dataset

  Runs a declared plan of runs on one card, or of solves of one solver, and seals the rows under one root. A plan is a list of runs, a grid over a base run, or a seeded sample over a base run; a run is a run_trajectory request without…

• verify_dataset

  Verifies the seal of a dataset. Short form: request is the run_dataset request as it was sent, and dataset_seal is the seal its answer gave. The plan is run again under run_dataset's permits and limits; the answer is holds, cause…

• verify_receipt

  Verifies the receipt at the end of one response against the text before it. It takes no physics permit. The receipt covers every byte of the response before it, the decimal values included, and shows who produced the response or when in…

• validate_series

  Runs a run_trajectory request (without a readout) and compares one published quantity with the agent's measurements, each at a landed step. The answer is the error in numbers (rms, mean signed, greatest absolute, model minus measurement…

• cite

  Gives how to cite a card or a solver: the service itself first (Zero-Trust Physics, its maker and its address) and the paper (https://doi.org/10.5281/zenodo.23517223), then the people whose measurements the model stands on (authors…

• find_model

  Finds the served model for a real thing described in plain words, such as "a lithium cell discharging in the cold". It returns the best few cards and solvers, each with fit first (the words that matched, and model_of: the one real thing…

• find_flip

  Finds where an outcome changes, and gives the run on each side. request is a run_trajectory or solve request written out, its domain and card or its solver by the name find_model or the lists give, with no from, readout or example; vary…

• design_run

  Designs a run: from a target end state to the loads of each segment that reach it, computed by the engine with no randomness, so the same request gives the same bits. request is a run_trajectory request; its numbers at the places vary…

• verify_step

  Computes one anchored step of one card, as compute_step does: verify_step is the earlier name of compute_step, served for this one version beside it, and takes the same arguments and gives the same answer, byte for byte. The name…