Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

Zero-Trust Physics

REMOTE · MCP.ZEROTRUSTPHYSICS.COM

Deterministic physics runtime with a proof on every answer: 61 models, open and keyless over MCP.

+3 this week 72 Trust /100

Last scanned (12 hours ago)

Scores higher than 58% of remote servers

Reachable. Last reached 5 Nov 2026.

Category Health and Science

Trust breakdown (7 categories)

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →

Endpoint Security63
Transport & Reachability100
Schema Quality & AI Usability48
  • AI-judged instruction clarity (good).Pass
  • Context-footprint check failed: tool/resource definitions use about 11637 tokens (~646/item across 18 items; 18 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
  • Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management77
  • Stability observed for 23 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage92
  • 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
  • 77% of tool parameters carry a description.Partial
Tool Safety100
  • No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
  • We read all 18 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
  • An AI judge read all 19 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
  • Implements a current MCP spec version (2026-07-28).Pass
Changelog

Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.

  • 5 Nov 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 73 to 77. That category is still filling its 30-day observation window: 22 days of observed history at the previous scan, 23 at this one. The score rises as the window fills, whether or not the server changes.

  • 2 Nov 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 63 to 67. That category is still filling its 30-day observation window: 19 days of observed history at the previous scan, 20 at this one. The score rises as the window fills, whether or not the server changes.

  • 31 Oct 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 57 to 60. That category is still filling its 30-day observation window: 17 days of observed history at the previous scan, 18 at this one. The score rises as the window fills, whether or not the server changes.

  • 30 Oct 26 0
    • HTTPS: unverified → fail ▼ security
    • Server version: 0.15.2 → 0.15.3 functional
  • 29 Oct 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 50 to 53. That category is still filling its 30-day observation window: 15 days of observed history at the previous scan, 16 at this one. The score rises as the window fills, whether or not the server changes.

  • 27 Oct 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 43 to 47. That category is still filling its 30-day observation window: 13 days of observed history at the previous scan, 14 at this one. The score rises as the window fills, whether or not the server changes.

  • 25 Oct 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 37 to 40. That category is still filling its 30-day observation window: 11 days of observed history at the previous scan, 12 at this one. The score rises as the window fills, whether or not the server changes.

  • 23 Oct 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 30 to 33. That category is still filling its 30-day observation window: 9 days of observed history at the previous scan, 10 at this one. The score rises as the window fills, whether or not the server changes.

Diagnostics

Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.

Captured 5 Nov 2026 · Probed https://mcp.zerotrustphysics.com/mcp

TLS valid

Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .

Subject Issuer Valid from Valid until Key Signature Serial
CN=zerotrustphysics.com CN=WE1,O=Google Trust Services,C=US 4 Oct 2026 2 Jan 2027 ECDSA 256 ECDSA-SHA256 c9bfbf5f9b8409990e36a0709441b747
SANs: zerotrustphysics.com, *.zerotrustphysics.com
CN=WE1,O=Google Trust Services,C=US (CA) CN=GTS Root R4,O=Google Trust Services LLC,C=US 13 Dec 2023 20 Feb 2029 ECDSA 256 ECDSA-SHA384 7ff31977972c224a76155d13b6d685e3
CN=GTS Root R4,O=Google Trust Services LLC,C=US (CA) CN=GlobalSign Root CA,OU=Root CA,O=GlobalSign nv-sa,C=BE 15 Nov 2023 28 Jan 2028 ECDSA 384 SHA256-RSA 7fe530bf331343bedd821610493d8a1b

Background: What to check on a remote MCP endpoint →

DNSSEC insecure

Validation of mcp.zerotrustphysics.com. — Not signed

Zone DS Keys Algorithms Outcome
. trust_anchor 20326, 38696 8, 8 Verified
com. present 19718 13 Verified
zerotrustphysics.com. absent Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation
Authentication No authorisation required

The endpoint answered without asking for a token. Anyone who knows the URL can reach it.

Result No authorisation required
HTTP status 200

Background: How OAuth 2.1 works in the 2026 MCP spec →

Transports 2 probes
Transport URL Outcome Status Location
streamable-http https://mcp.zerotrustphysics.com/mcp Verified 200
http (plaintext) http://mcp.zerotrustphysics.com/mcp Served over HTTP 200
MCP tools · 18 exposed · ~11,407 tokens

The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →

Tool Tokens
cite ~194

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, title, year, address, and what each asks of those who use its data), each as text and BibTeX. With domain and card, or solver, the answer is for that model; with neither, it is how to cite the service itself: its name, who made it, its address and the paper.

NameTypeReqDescription
cardstring––
domainstring–With card: a card, by the name find_model or list_cards gives; the two give the same names.
solverstring–In place of domain and card: a solver, by the name find_model or list_solvers gives.

No output schema declared.

No examples provided.

compute_step ~381

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 describe_card gives them. A step whose request or whose landing state is outside the card is refused in one sentence, with the refusal's name in round brackets when it has one, and no proof is issued for that state. With from, the step starts from a sealed run, which is computed again first. On this open connection one address holds at most 1 physics permit at a time, and long work (a solve, a plan of runs or of solves, a run of more than 10000 steps, or a verification that computes one again) runs 1 at a time. A call that finds no permit or no place is answered "Too many concurrent physics tasks." and nothing waits: the same call sent later is answered once one is free. An answer is waited for 60 seconds, and long work is stopped there.

NameTypeReqDescription
cardstringyesThe card of the pair, as list_cards names it.
domainstringyesThe domain of the pair, as list_cards names it.
fromobject–Optional: a sealed run to start from, as run_trajectory takes it.
parametersobjectyesThe step's inputs: the card's phase fields, its load fields and dt_s, each a number (a vector field is an array of three numbers), and no other key. describe_card gives the fields of the pair, with e…

No output schema declared.

No examples provided.

describe_card ~188

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 is of, the evidence behind it in numbers, each input with its unit and range, the names of its stops, and a worked request. The full form, the answer when form is left out, adds each bound's reason, the validation record and each stop's meaning.

NameTypeReqDescription
cardstringyesThe card of the pair, as list_cards names it.
domainstringyesThe domain of the pair, as list_cards names it.
formstring–Leave this key out, or "full", for the whole description; "short" for a page that is enough to write a first request.

No output schema declared.

No examples provided.

describe_solver ~226

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 model is of, the evidence behind it in numbers, each input with its unit and range, the names of its stops, and a worked request. The full form, the answer when form is left out, adds each bound's reason, the validation record and each stop's meaning.

NameTypeReqDescription
formstring–Leave this key out, or "full", for the whole description; "short" for a page that is enough to write a first request.
partstring–Leave this key out to get the solver's whole description. Some long descriptions name, under 'more', parts kept back for asking: set part to one of the names listed there for that part alone. Only a…
solverstringyesThe solver, as list_solvers names it.

No output schema declared.

No examples provided.

design_run ~679

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 names are the start, and vary gives each load's span inside the card's bounds. target is a number of the final state, a value and a tolerance. Every candidate is an ordinary run with its run_seal; one that crosses a limit is recorded refused by its name, and no value is moved back. The answer gives the timeline, its run_trajectory request and run_seal, the value reached and the miss, every candidate in order as a run_dataset plan with its dataset_seal, and a design_seal. Outcome reached; not_reached, meaning this search found none inside its caps, which is not a limit of the physics; or refused: TargetOutsideCard for a target outside the card's range, TargetBeyondReach where the card's map is monotone and a corner of the loads allowed falls short. The search is coordinate bisection, capped at 64 candidates (DESIGN_MAX_CANDIDATES), 1000000 steps (DESIGN_MAX_STEPS) and 10000 recorded frames (DESIGN_MAX_FRAMES) in all, and 4 sweeps (DESIGN_MAX_SWEEPS). verify_tape, given this whole answer as it came, designs it again and compares the two, byte for byte (the long form). On this open connection a design is long work whenever its candidates may take more than 10000 steps together. One address holds at most 1 physics permit at a time, and long work (a solve, a plan of runs or of solves, a run of more than 10000 steps, or a verification that computes one again) runs 1 at a time. A call that finds no permit or no place is answered "Too many concurrent physics tasks." and nothing waits: the same call sent later is answered once one is free. An answer is waited for 60 seconds, and long work is stopped there.

NameTypeReqDescription
requestobjectyesA run_trajectory request as that tool takes it, with no from or readout, and a number at every place vary names: the search's start. Nothing is filled in.
targetobjectyesThe end state to reach: the quantity of the run's final state within value plus or minus tolerance, after its last step, or, for a run that ends at an end its card declares (a reactor past its first…
varyarrayyesFrom 1 to 8 loads the search sets, in the order a sweep takes them. The search sets loads only, never a start value, the step or the steps, and each load is held constant through its segment. low and…

No output schema declared.

No examples provided.

find_flip ~767

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 is the place of the one number to change, such as "segments[0].load.current_a", "initial.soc", "dt_s" or "parameters.load_n"; low and high are the two ends of the span, in either order: the smaller is taken as low. The span is halved to the place where the outcome or the stop name changes or, with level, where a published quantity of the final state (of a solve: of result) crosses a value or a flag turns. When both ends give the same, 7 values between them (3 for solves) are run to find a band, and the answer says so. The answer gives the run on each side as a request ready to send again, with its outcome, its stop name and sentence and the run_seal or solution_seal that request has when sent alone, the two values in decimals and exact hex, and the width between them. A side that stops before computing has no proof. The same request gives the same pair. A search is bounded, and names the bound that stops it: 64 runs (FLIP_MAX_RUNS), 1000000 steps in all (FLIP_MAX_STEPS), or 64 solves (FLIP_MAX_SOLVES), the ends included, and no new solve once those made are counted at 20 s (FLIP_MAX_SECONDS); the pair it gives, sent back as the span, narrows it further. On this open connection a search is long work whenever it varies a solve or its runs may take more than 10000 steps together. One address holds at most 1 physics permit at a time, and long work (a solve, a plan of runs or of solves, a run of more than 10000 steps, or a verification that computes one again) runs 1 at a time. A call that finds no permit or no place is answered "Too many concurrent physics tasks." and nothing waits: the same call sent later is answered once one is free. An answer is waited for 60 seconds, and long work is stopped there.

NameTypeReqDescription
highnumberyesThe other end.
levelobject–Optional. {"quantity": <a published quantity>, "value": <number>}: the span is halved to where that quantity of the final state (of a solve: of result) crosses the value. {"quantity": <a flag>}: to w…
lownumberyesOne end of the span. low and high may come in either order; the smaller is taken as low.
requestobjectyesA run_trajectory or solve request as that tool takes it. A search of solves makes no new solve once those made are counted at 20 s (FLIP_MAX_SECONDS), each at the time describe_solver states for one…
varystringyesThe place of the one number to vary: "segments[0].load.current_a", "segments[*].load.current_a" for every segment, "initial.soc", "dt_s", "segments[0].steps", "parameters.load_n". A count is varied i…

No output schema declared.

No examples provided.

find_model ~348

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 it is a model of, and its range) and then accuracy: against_measurement, the evidence behind it in one of three words, as list_cards and list_solvers give it ("compared with measurement", "held to a reference calculation" or "company specimen"); compared_with, what it was fitted on; and accuracy_against_measurement, what it was compared with outside the fit, within what, and the gap, in numbers. Fit and accuracy are separate: a model with a gap is still the served model of its thing. The names it gives (domain and card, or solver) are the names list_cards and list_solvers give and the names describe_card, describe_solver, cite and every other tool take; describe_card or describe_solver gives the range and every refusal. When nothing served fits it says so, having compared every card and solver, names the nearest by words and why they are not it, or says that there is no near one, and says where requests for a model go. A model is set aside when the description names another thing of its kind (another gas, another maker's cell, another planet's probe). It is matched against a fixed list of terms with no model call: the same words give the same answer.

NameTypeReqDescription
descriptionstringyesThe real thing, in plain words.
limitinteger–How many models to return; 3 when left out.

No output schema declared.

No examples provided.

list_cards ~125

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 description says what it was fitted on, what it was compared with outside the fit and within what, the gap, and where it refuses), "held to a reference calculation" (compared with a published calculation), or "company specimen" (an object the company specified, every constant stated). The numbers say how good it is.

Input schema present but exposes no named parameters.

No output schema declared.

No examples provided.

list_solvers ~125

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 description says what it was fitted on, what it was compared with outside the fit and within what, the gap, and where it refuses), "held to a reference calculation" (compared with a published calculation), or "company specimen" (an object the company specified, every constant stated). The numbers say how good it is.

Input schema present but exposes no named parameters.

No output schema declared.

No examples provided.

run_dataset ~1,748

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 domain and card. A plan of solves names solver in place of domain and card and is a list or a grid of solve requests. The answer is small by default: the head, which holds the request, the counts and the dataset_seal, and one summary row per run; answer "states" adds each final state in decimals and "full" gives every row whole, under the same dataset_seal. A row is completed, ended, refused or unadmitted: an ended or a refused row is a run sealed up to its last landed step, and an unadmitted row is a request turned away before computing, with no seal. The seal shows the dataset was not altered after it was sealed. It does not show the engine made it: a row's request sent to run_trajectory gives the run seal to compare. The input schema says how each input is written, with a worked plan of each kind. On this open connection a dataset is returned inline and holds at most 300 runs (OPEN_MAX_DATASET_ROWS), 1000000 steps in all (OPEN_MAX_DATASET_STEPS), 10000 frames and an answer counted from the plan at 4194304 bytes (OPEN_MAX_DATASET_ANSWER_BYTES) and 42500 characters, up to about 150 summary rows; a plan of solves holds the engine's own 64 and at most 15 s of them, or one, at each solver's measured time, which describe_solver states with the count (OPEN_PLAN_SECONDS). One address holds at most 1 physics permit at a time, and long work (a solve, a plan of runs or of solves, a run of more than 10000 steps, or a verification that computes one again) runs 1 at a time. A call that finds no permit or no place is answered "Too many concurrent physics tasks." and nothing waits: the same call sent later is answered once one is free. An answer is waited for 60 seconds, and long work is stopped there.

NameTypeReqDescription
answerstring–Leave out, or "summary", for the head and one short summary row per row: the values it sets, outcome, steps landed, refusal name and seal; "states" adds each run's final state in decimals; "full" giv…
cardstring––
domainstring––
plan–yesA path names one number: initial.<field>, dt_s, or segments[0].load.<field>, with the segment's number in square brackets and [0], [1] or [2] after a 3-vector field for one of its components. steps a…
returnstring––
solverstring–A plan of solves: the solver, in place of domain and card. It takes no store and no return. A plan of solves is answered inline: a list, {"kind":"list","solves":[{"parameters":{...}}]}, or a grid, {"…
storestring––

No output schema declared.

No examples provided.

run_trajectory ~1,541

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. record_every sets which steps are recorded, about 262 characters each; the final state comes back in full whatever is recorded. readout gives named quantities in decimals without the frames, with each one's minimum and maximum over every landed step and the first step past a level; it is not part of the sealed request. from starts the run from a sealed run, which is computed again first. A run comes back in one of four ways. outcome "completed": every step landed. outcome "ended": the run reached an end its card declares, which describe_card lists under declared_ends; reject holds the end's name. outcome "refused": a step part way was refused; reject holds the name (null when the cause has none) and reject_detail the sentence. An ended or a refused run is sealed up to its last landed step, steps_landed. An error, not a result: the request was turned away before computing, in one sentence with the refusal's name in round brackets when it has one, and nothing is sealed. A sentence that begins "Physical Failure" says the state asked for or reached is outside the card; one that begins "Physical Violation" says the request, or a number in it or computed from it, is not one the engine takes. A load may be signed; load_source says by whom. The input schema says each of these in full. On this open connection one address holds at most 1 physics permit at a time, and long work (a solve, a plan of runs or of solves, a run of more than 10000 steps, or a verification that computes one again) runs 1 at a time. A call that finds no permit or no place is answered "Too many concurrent physics tasks." and nothing waits: the same call sent later is answered once one is free. An answer is waited for 60 seconds, and long work is stopped there.

NameTypeReqDescription
cardstringyesThe card of the pair, as list_cards names it.
domainstringyesThe domain of the pair, as list_cards names it.
dt_snumberyesStep, in seconds. Held for the whole run.
fromobject–Optional: start from a sealed run. request: that run_trajectory request as sent, less its readout if it had one: a readout is not part of a run's seal, and a request here that carries one is refused…
initialobjectyesThe phase fields of the card at the start of the run, each a number (a vector field is an array of three numbers), and no other key but signed: an instrument's signature over the rest of initial, und…
readoutobject–Optional. Reads quantities without the frames: {"quantities": [names the card publishes], "first_past": {"quantity": <one of them>, "above" or "below": <level>}}. The answer then holds the named quan…
record_everyintegeryesA state is recorded at each multiple of record_every and at the last landed step. The size of the answer follows from the request: about 262 characters for each recorded state, plus the request as it…
segmentsarrayyesA segment may carry signed beside its load: an instrument's signature over the load. signed holds alg "ed25519"; key, the instrument's public key as 64 hex digits, its identity; instrument, the name…

No output schema declared.

No examples provided.

solve ~778

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. example, in their place, is the name of a worked example describe_solver lists (example_solve, or a key beginning example_solve_), so a long worked input need not be typed again; the request is filled with that example's parameters, and the filled request is the one solved, sealed and returned as inputs. The receipt covers the request as it was written, number spellings included, while a seal covers its values: a request sent with 310 and the same request sent with 310.0 give different receipts and the same seal, so a receipt that differs between two such answers is not a sign of tampering. A chained solve, from a sealed card run through a coupling (from), takes each handed value in parameters bit for bit: decode it from the run's frame_hex or a _hex value, not a decimal readout, or it is refused as CouplingLedgerBreach. verify_solution verifies a solution later from this request, or its inputs, and its solution_seal. On this open connection one address holds at most 1 physics permit at a time, and long work (a solve, a plan of runs or of solves, a run of more than 10000 steps, or a verification that computes one again) runs 1 at a time. A call that finds no permit or no place is answered "Too many concurrent physics tasks." and nothing waits: the same call sent later is answered once one is free. An answer is waited for 60 seconds, and long work is stopped there.

NameTypeReqDescription
examplestring–In place of parameters: the name of one of the solver's worked examples as describe_solver keys it (example_solve, or a key that begins example_solve_). The request is filled with that example's para…
fromobject–Optional: a sealed card run handed in through a coupling, as run_trajectory takes it. Each handed value goes into parameters bit for bit, read from the run's frame_hex or a _hex value, not a decimal…
parametersobject–The inputs of the solver named in 'solver', each a number, a whole number, a word, a flag or an array as describe_solver gives it, and no other key but signed. Every number of a solve request must be…
solverstringyesThe solver, as list_solvers names it.

No output schema declared.

No examples provided.

validate_series ~1,027

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, each with its exact hex), the model value at every compared step in decimals (model_values) and exact (model_values_hex), and a hash of the measurements, under one seal. It sets no threshold: the numbers are the answer. The seal has no key, so it does not show who measured or who computed. commitment, optional, opens a salted SHA-384 the measurements were locked with before the comparison: data that are not the committed ones are refused before computing (CommitmentDoesNotMatch), and the seal covers it. genesis_seal verify-validation rebuilds the seal, the statistics and the commitment from the answer alone. In place of run, solves takes a plan of solves as run_dataset takes it (solver and plan, at most 64 solves), each measurement at a row of the plan: the solves are sealed under one dataset_seal, and the comparison by the same rules with the dataset_seal in the place of the run seal and the row in the place of the step; a measured row whose solve did not converge is counted in not_reached. The same request sent again gives the same seal. On this open connection a plan of solves holds the engine's own 64 and at most 15 s of them, or one, at each solver's measured time, which describe_solver states with the count (OPEN_PLAN_SECONDS). One address holds at most 1 physics permit at a time, and long work (a solve, a plan of runs or of solves, a run of more than 10000 steps, or a verification that computes one again) runs 1 at a time. A call that finds no permit or no place is answered "Too many concurrent physics tasks." and nothing waits: the same call sent later is answered once one is free. An answer is waited for 60 seconds, and long work is stopped there.

NameTypeReqDescription
commitmentobject–Optional: a commitment the measurements were locked with before this comparison, opened by this request. sha384 is the SHA-384 of these bytes: the line zero-trust-physics/measurement-commitment/v2 an…
componentinteger–0, 1 or 2: which of the three components of a 3-vector quantity is compared. Required when the quantity is a 3-vector, and refused when it is not. Any other value is refused.
measurementsarrayyesAt most 10000. A measurement is compared with the state after landed step k. There is no interpolation and no time matching: a measurement is placed by its step, its time since the start divided by d…
quantitystringyesThe name of one number the card publishes in its state, a plain name that has a '_hex' sibling in the state. A flag is refused.
runobject–One anchored run. Total steps must be <= 1000000. Recorded frames must be <= 10000. The shape of initial and of each segment's load depends on the pair: describe_card gives it.
solvesobject–In place of run: a plan of solves as run_dataset takes it (solver and plan, a list or a grid, at most 64 solves). quantity is then one number the solver publishes in its result, and each measurement…

No output schema declared.

No examples provided.

verify_dataset ~875

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 ("dataset_seal" when the seal given is not the seal the plan runs to), recomputed_dataset_seal when it holds (else no seal: run_dataset gives the true one), compared, and text_not_compared: no rows the agent holds are compared. A plan of solves is verified by this short form only. Long form: head, rows and frames_hex, the three parts a full answer carries (answer "full"), together, as they came. The rows, the root and the seal are recomputed, and row and fault name the first row changed, swapped, dropped or repeated; then the plan is run again under run_dataset's permits and limits and the engine's answer compared with it, value by value and byte for byte (cause answer_text, with differs_at and row): holds is true only when every byte is the engine's, values_hold when every value is. On this open connection a dataset is returned inline and holds at most 300 runs (OPEN_MAX_DATASET_ROWS), 1000000 steps in all (OPEN_MAX_DATASET_STEPS), 10000 frames and an answer counted from the plan at 4194304 bytes (OPEN_MAX_DATASET_ANSWER_BYTES) and 42500 characters, up to about 150 summary rows; a plan of solves holds the engine's own 64 and at most 15 s of them, or one, at each solver's measured time, which describe_solver states with the count (OPEN_PLAN_SECONDS). One address holds at most 1 physics permit at a time, and long work (a solve, a plan of runs or of solves, a run of more than 10000 steps, or a verification that computes one again) runs 1 at a time. A call that finds no permit or no place is answered "Too many concurrent physics tasks." and nothing waits: the same call sent later is answered once one is free. An answer is waited for 60 seconds, and long work is stopped there.

NameTypeReqDescription
dataset_sealstring–With request: the dataset_seal of the run_dataset answer, compared with the seal the plan runs to. Alone: the seal of a dataset stored as files (return "file"), read from the connection's own folder…
frames_hexstring|null–With head and rows: the frames a run_dataset answer carries, or null.
headobject–With rows and frames_hex: the head a run_dataset answer carries.
public_keystring–The base64 of the ML-DSA-87 public key (2,592 bytes) to verify the answer's signature with; without it, this engine's own.
requestobject–With dataset_seal alone: the run_dataset request as it was sent (the head's request). The plan is run again, under the permits and the limits of run_dataset, and its seal is compared with dataset_sea…
rowsarray–With head and frames_hex: the rows a full run_dataset answer (answer "full") carries.
seen_noncesarray–Nonces of signatures already seen: one of them again is SignatureNonceReplayed.

No output schema declared.

No examples provided.

verify_receipt ~349

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 no way: it has no key. matches true proves only that those bytes are unchanged since the receipt was written; anyone can write a matching receipt for any text, so it is not a verification of the answer. A response that names an engine_version has it said beside matches, with whether it is this engine's; origin needs engine_version_is_this_engines true and a replay. match_proves says this in each answer. The receipt covers the request as it was written, number spellings included, while a seal covers its values: a request sent with 310 and the same request sent with 310.0 give different receipts and the same seal, so a receipt that differs between two such answers is not a sign of tampering. Replaying the request through run_trajectory, solve or compute_step shows the engine produced it; verify_tape, verify_solution and verify_dataset with the request and its seal do that replay and compare the seals.

NameTypeReqDescription
public_keystring–The base64 of the ML-DSA-87 public key (2,592 bytes) to verify the answer's signature with; without it, this engine's own.
response_textstringyesThe exact text of a response as it was received, ending with the receipt, and the engine's signature after it when it carries one.
seen_noncesarray–Nonces of signatures already seen: one of them again is SignatureNonceReplayed.

No output schema declared.

No examples provided.

verify_solution ~805

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 permit and the limits and refusals of solve, and the answer is holds, cause ("solution_seal" when the seal given is not the seal the request solves to), recomputed_solution_seal and recomputed_receipt_sha384 when it holds (else no seal: solve gives the true one), compared, and text_not_compared: no answer text the agent holds is compared. Long form: the whole solve answer sent back as it came, without request. Its solution seal is recomputed from its exact hex values and the part that fails is named, then its request is solved again under a physics permit and the engine's answer compared with it, value by value and byte for byte, receipt included: holds is true only when every byte is the engine's, values_hold when every value is, else cause names the part, solution_seal (the request solves to another seal), answer_text (with differs_at, the first field that differs) or engine_version (an answer of another version). A chained solve: its whole answer with from beside it; the upstream run is computed again and the chain held too (cause chain), with recomputed_chain_seal. Alone it is refused (AnswerCarriesNoRequest). Nothing is stored, so each form answers the same on every connection. On this open connection one address holds at most 1 physics permit at a time, and long work (a solve, a plan of runs or of solves, a run of more than 10000 steps, or a verification that computes one again) runs 1 at a time. A call that finds no permit or no place is answered "Too many concurrent physics tasks." and nothing waits: the same call sent later is answered once one is free. An answer is waited for 60 seconds, and long work is stopped there.

NameTypeReqDescription
engine_versionstring––
field_sha384string|null––
fromobject–Beside the whole answer of a chained solve: the from solve took (request, run_seal, coupling). The upstream run is computed again and held to its seal, each handed value to it, and the request solved…
inputsobject–The inputs of the solve answer, sent back as returned: the request that was solved. It is hashed, and solved again under a physics permit and the limits of solve.
invariantsobject|null––
iterationsinteger|null––
outcomestring––
public_keystring–The base64 of the ML-DSA-87 public key (2,592 bytes) to verify the answer's signature with; without it, this engine's own.
rejectstring|null––
requestobject–With solution_seal alone: the solve request as it was sent (the answer's inputs). It is solved again, under a physics permit and the limits of solve, and its seal is compared with solution_seal. Its…
resultobject|null––
seal_partsobject––
seen_noncesarray–Nonces of signatures already seen: one of them again is SignatureNonceReplayed.
solution_sealstring–The solution_seal of the solve answer: with request, or as part of the whole answer.

No output schema declared.

No examples provided.

verify_step ~323

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 compute_step is the one that stays. On this open connection one address holds at most 1 physics permit at a time, and long work (a solve, a plan of runs or of solves, a run of more than 10000 steps, or a verification that computes one again) runs 1 at a time. A call that finds no permit or no place is answered "Too many concurrent physics tasks." and nothing waits: the same call sent later is answered once one is free. An answer is waited for 60 seconds, and long work is stopped there.

NameTypeReqDescription
cardstringyesThe card of the pair, as list_cards names it.
domainstringyesThe domain of the pair, as list_cards names it.
fromobject–Optional: a sealed run to start from, as run_trajectory takes it.
parametersobjectyesThe step's inputs: the card's phase fields, its load fields and dt_s, each a number (a vector field is an array of three numbers), and no other key. describe_card gives the fields of the pair, with e…

No output schema declared.

No examples provided.

verify_tape ~928

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 run_seal is the seal its answer gave. The run is computed again, under a physics permit and the limits and refusals of run_trajectory, and the answer is holds (the seal given is the seal the request runs to), cause ("run_seal" when it is not), recomputed_run_seal and recomputed_receipt_sha384 when it holds (else no seal: run_trajectory gives the true one), compared, and text_not_compared: no answer text the agent holds is compared. Long form: the whole run_trajectory answer sent back as it came, without request. Its state digest and run seal are recomputed from its exact hex values, then its request is computed again under a physics permit and the engine's answer compared with it, value by value and byte for byte, receipt included: holds is true only when every byte is the engine's, values_hold when every value is, else cause names the seal, load_signature (a signed load that does not verify), answer_text (with differs_at, the first field that differs) or engine_version (an answer of another version). A chain is verified by its request with from, run_seal and chain_seal, or by links, its answers in order, each computed again from the links before it; a chained answer alone is refused (AnswerCarriesNoRequest). Nothing is stored, so each form answers the same on every connection. On this open connection one address holds at most 1 physics permit at a time, and long work (a solve, a plan of runs or of solves, a run of more than 10000 steps, or a verification that computes one again) runs 1 at a time. A call that finds no permit or no place is answered "Too many concurrent physics tasks." and nothing waits: the same call sent later is answered once one is free. An answer is waited for 60 seconds, and long work is stopped there.

NameTypeReqDescription
chain_sealstring–With request and run_seal: a chained answer's chain_seal.
final_residual_conservation_error_hexstring|null––
final_state–––
framesarray––
inputsobject–The inputs of the run_trajectory answer, sent back as returned: the request that was run. It is hashed, and run again, with the answer's readout when it has one, under a physics permit and the limits…
linksarray–Alone: a chain's answers in order.
max_residual_conservation_error_hexstring|null––
outcomestring––
public_keystring–The base64 of the ML-DSA-87 public key (2,592 bytes) to verify the answer's signature with; without it, this engine's own.
rejectstring|null––
requestobject–With run_seal alone: the run_trajectory request as it was sent, with its readout and its from when it had them (the answer's inputs holds neither; the upstream request in that from goes without a rea…
run_sealstring–The run_seal of the run_trajectory answer: with request, or as part of the whole answer.
seen_noncesarray–Nonces of signatures already seen: one of them again is SignatureNonceReplayed.
state_digeststring|null––
steps_landedinteger––

No output schema declared.

No examples provided.

Install

How do I install the Zero-Trust Physics MCP server?

Zero-Trust Physics is a hosted endpoint at https://mcp.zerotrustphysics.com/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

remote · mcp.zerotrustphysics.com

# add to Claude Code
claude mcp add --transport http com-zerotrustphysics-verifier 'https://mcp.zerotrustphysics.com/mcp'
Common questions

What is the Zero-Trust Physics MCP server?

Zero-Trust Physics is an MCP server listed in the public MCP registry as com.zerotrustphysics/verifier. Deterministic physics runtime with a proof on every answer: 61 models, open and keyless over MCP. This page covers its hosted endpoint (https://mcp.zerotrustphysics.com/mcp).

Is the Zero-Trust Physics MCP server safe to use?

Zero-Trust Physics scores 72 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

What tools does the Zero-Trust Physics MCP server expose?

Zero-Trust Physics exposes 18 tools: list_cards, describe_card, compute_step, run_trajectory, verify_tape, and 13 more. Their descriptions and schemas cost roughly 11,407 tokens of context every time the server is loaded.

Does the Zero-Trust Physics MCP server require authentication?

No. We connected to Zero-Trust Physics without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.

Is the Zero-Trust Physics MCP server still maintained?

Zero-Trust Physics is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.