# Zero-Trust Physics (remote · mcp.zerotrustphysics.com)

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

- Trust score: 72/100 (medium)
- Change this week: +3
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-11-05

## Components

- remote · `mcp.zerotrustphysics.com`: 72/100 (this document), [markdown](https://verifymcp.io/servers/com-zerotrustphysics-verifier/mcp.md), [page](https://verifymcp.io/servers/com-zerotrustphysics-verifier/mcp)

## Channel facts

- Endpoint: `https://mcp.zerotrustphysics.com/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `0.15.3`

## Trust breakdown

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. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-11-05.

- **Endpoint Security**: 63/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - No authorisation is required to call this server. Every tool declares its destructiveHint and none is destructive, so open access doesn't expose one.
  - HTTPS check failed: the endpoint is reachable over plaintext HTTP.
  - HSTS check failed: the Strict-Transport-Security header is absent.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 48/100
  - AI-judged instruction clarity (good).
  - 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.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 77/100
  - Stability observed for 23 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 92/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 77% of tool parameters carry a description.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - We read all 18 captured tool definition(s), and no name or description among them implies an irreversible operation.
  - An AI judge read all 19 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a current MCP spec version (2026-07-28).

## 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.

### Claude

```bash
claude mcp add --transport http com-zerotrustphysics-verifier 'https://mcp.zerotrustphysics.com/mcp'
```

### Cursor

```json
{
  "mcpServers": {
    "com-zerotrustphysics-verifier": {
      "url": "https://mcp.zerotrustphysics.com/mcp"
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "com-zerotrustphysics-verifier": {
      "type": "http",
      "url": "https://mcp.zerotrustphysics.com/mcp"
    }
  }
}
```

### Codex

```toml
[mcp_servers.com-zerotrustphysics-verifier]
url = "https://mcp.zerotrustphysics.com/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "com-zerotrustphysics-verifier": {
      "type": "remote",
      "url": "https://mcp.zerotrustphysics.com/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add com-zerotrustphysics-verifier --url 'https://mcp.zerotrustphysics.com/mcp' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  com-zerotrustphysics-verifier:
    url: "https://mcp.zerotrustphysics.com/mcp"
```

### Netclaw

```json
{
  "McpServers": {
    "com-zerotrustphysics-verifier": {
      "Transport": "http",
      "Url": "https://mcp.zerotrustphysics.com/mcp"
    }
  }
}
```

### Vellum

```bash
assistant mcp add com-zerotrustphysics-verifier -t streamable-http -u 'https://mcp.zerotrustphysics.com/mcp'
```

### Other

```json
{
  "mcpServers": {
    "com-zerotrustphysics-verifier": {
      "type": "http",
      "url": "https://mcp.zerotrustphysics.com/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-11-05 (score 72, +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.

### 2026-11-02 (score 71, +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.

### 2026-10-31 (score 70, +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.

### 2026-10-30 (score 69, 0)

- [security regression] HTTPS: unverified → fail
- [functional] Server version: 0.15.2 → 0.15.3

### 2026-10-29 (score 69, +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.

### 2026-10-27 (score 68, +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.

### 2026-10-25 (score 67, +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.

### 2026-10-23 (score 66, +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.

## MCP tools (18)

### `list_cards` (~125 tokens)

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 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.

### `describe_card` (~188 tokens)

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 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.

Input parameters:

- `card` (string, required): The card of the pair, as list_cards names it.
- `domain` (string, required): The domain of the pair, as list_cards names it.
- `form` (string): Leave this key out, or "full", for the whole description; "short" for a page that is enough to write a first request.

### `compute_step` (~381 tokens)

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 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.

Input parameters:

- `card` (string, required): The card of the pair, as list_cards names it.
- `domain` (string, required): The domain of the pair, as list_cards names it.
- `from` (object): Optional: a sealed run to start from, as run_trajectory takes it.
- `parameters` (object, required): The 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…

### `run_trajectory` (~1541 tokens)

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. 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.

Input parameters:

- `card` (string, required): The card of the pair, as list_cards names it.
- `domain` (string, required): The domain of the pair, as list_cards names it.
- `dt_s` (number, required): Step, in seconds. Held for the whole run.
- `from` (object): 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…
- `initial` (object, required): The 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…
- `readout` (object): 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_every` (integer, required): A 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…
- `segments` (array, required): A 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…

### `verify_tape` (~928 tokens)

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 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.

Input parameters:

- `chain_seal` (string): With request and run_seal: a chained answer's chain_seal.
- `final_residual_conservation_error_hex` (string|null)
- `final_state`
- `frames` (array)
- `inputs` (object): 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…
- `links` (array): Alone: a chain's answers in order.
- `max_residual_conservation_error_hex` (string|null)
- `outcome` (string)
- `public_key` (string): 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.
- `reject` (string|null)
- `request` (object): 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_seal` (string): The run_seal of the run_trajectory answer: with request, or as part of the whole answer.
- `seen_nonces` (array): Nonces of signatures already seen: one of them again is SignatureNonceReplayed.
- `state_digest` (string|null)
- `steps_landed` (integer)

### `list_solvers` (~125 tokens)

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 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.

### `describe_solver` (~226 tokens)

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 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.

Input parameters:

- `form` (string): Leave this key out, or "full", for the whole description; "short" for a page that is enough to write a first request.
- `part` (string): 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…
- `solver` (string, required): The solver, as list_solvers names it.

### `solve` (~778 tokens)

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. 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.

Input parameters:

- `example` (string): 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…
- `from` (object): 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…
- `parameters` (object): 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…
- `solver` (string, required): The solver, as list_solvers names it.

### `verify_solution` (~805 tokens)

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 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.

Input parameters:

- `engine_version` (string)
- `field_sha384` (string|null)
- `from` (object): 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…
- `inputs` (object): 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.
- `invariants` (object|null)
- `iterations` (integer|null)
- `outcome` (string)
- `public_key` (string): 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.
- `reject` (string|null)
- `request` (object): 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…
- `result` (object|null)
- `seal_parts` (object)
- `seen_nonces` (array): Nonces of signatures already seen: one of them again is SignatureNonceReplayed.
- `solution_seal` (string): The solution_seal of the solve answer: with request, or as part of the whole answer.

### `run_dataset` (~1748 tokens)

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 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.

Input parameters:

- `answer` (string): 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…
- `card` (string)
- `domain` (string)
- `plan` (required): A 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…
- `return` (string)
- `solver` (string): 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, {"…
- `store` (string)

### `verify_dataset` (~875 tokens)

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 ("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.

Input parameters:

- `dataset_seal` (string): 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_hex` (string|null): With head and rows: the frames a run_dataset answer carries, or null.
- `head` (object): With rows and frames_hex: the head a run_dataset answer carries.
- `public_key` (string): 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.
- `request` (object): 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…
- `rows` (array): With head and frames_hex: the rows a full run_dataset answer (answer "full") carries.
- `seen_nonces` (array): Nonces of signatures already seen: one of them again is SignatureNonceReplayed.

### `verify_receipt` (~349 tokens)

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 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.

Input parameters:

- `public_key` (string): 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_text` (string, required): The 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_nonces` (array): Nonces of signatures already seen: one of them again is SignatureNonceReplayed.

### `validate_series` (~1027 tokens)

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, 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.

Input parameters:

- `commitment` (object): 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…
- `component` (integer): 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.
- `measurements` (array, required): At 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…
- `quantity` (string, required): The 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.
- `run` (object): 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.
- `solves` (object): 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…

### `cite` (~194 tokens)

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, 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.

Input parameters:

- `card` (string)
- `domain` (string): With card: a card, by the name find_model or list_cards gives; the two give the same names.
- `solver` (string): In place of domain and card: a solver, by the name find_model or list_solvers gives.

### `find_model` (~348 tokens)

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 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.

Input parameters:

- `description` (string, required): The real thing, in plain words.
- `limit` (integer): How many models to return; 3 when left out.

### `find_flip` (~767 tokens)

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 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.

Input parameters:

- `high` (number, required): The other end.
- `level` (object): 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…
- `low` (number, required): One end of the span. low and high may come in either order; the smaller is taken as low.
- `request` (object, required): A 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…
- `vary` (string, required): The 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…

### `design_run` (~679 tokens)

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 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.

Input parameters:

- `request` (object, required): A 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.
- `target` (object, required): The 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…
- `vary` (array, required): From 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…

### `verify_step` (~323 tokens)

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 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.

Input parameters:

- `card` (string, required): The card of the pair, as list_cards names it.
- `domain` (string, required): The domain of the pair, as list_cards names it.
- `from` (object): Optional: a sealed run to start from, as run_trajectory takes it.
- `parameters` (object, required): The 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…

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/com-zerotrustphysics-verifier/mcp#diagnostics

## Score history

- 2026-11-05: 72
- 2026-11-04: 71
- 2026-11-03: 71
- 2026-11-02: 71
- 2026-11-01: 70
- 2026-10-31: 70
- 2026-10-30: 69
- 2026-10-29: 69
- 2026-10-28: 68
- 2026-10-27: 68
- 2026-10-26: 67
- 2026-10-25: 67
- 2026-10-24: 66
- 2026-10-23: 66
- 2026-10-22: 65
- 2026-10-21: 65
- 2026-10-20: 64
- 2026-10-19: 64
- 2026-10-18: 63
- 2026-10-17: 63
- 2026-10-16: 63
- 2026-10-15: 62
- 2026-10-14: 61
- 2026-10-13: 60

## 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.

## Links

- Remote endpoint: https://mcp.zerotrustphysics.com/mcp
- Website: https://zerotrustphysics.com/
- Changelog RSS feed: https://verifymcp.io/servers/com-zerotrustphysics-verifier/mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/com-zerotrustphysics-verifier/mcp.json
- HTML version of this page: https://verifymcp.io/servers/com-zerotrustphysics-verifier/mcp