78trust / 100

Zero-Trust Physics

by zerotrustphysics.com in Onchain & crypto

MCP serverPassing, checked 7 h ago

A physics verifier for Super Intelligence. Every answer comes with a cryptographic proof.

https://mcp.zerotrustphysics.com/mcp
Tools
18
open to any client
Uptime
100%
last 30 days
Response time
619 ms
830 ms slowest 5%
Last check
Passed
7 h ago, next any minute now

Scan it nowHow to connect

Reliability

All checks passedSome failedAll failedNot checked

Status and outage history · Atom feed · Watch with other listings

How to connect

Add it to any MCP client that supports remote servers.

{
  "mcpServers": {
    "zero-trust-physics": {
      "type": "http",
      "url": "https://mcp.zerotrustphysics.com/mcp"
    }
  }
}

18 tools

  • list_cards

    Lists every domain and card this connection serves, each with one sentence, and count, how many there are. against_measurement says in one of six words how the model stands against measurement. "met", "met in part" and "missed" say how it did against the pass marks its record…

  • 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, how it did against measurement…

  • 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 (sha256_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…

  • 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…

  • 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 when it had them (the answer's inputs holds neither), and run_seal is the seal its answer gave. The run is computed again…

  • list_solvers

    Lists every field solver this connection serves, each with one sentence, and count, how many there are. against_measurement says in one of six words how the model stands against measurement. "met", "met in part" and "missed" say how it did against the pass marks its record…

  • 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, how it did against measurement…

  • 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…

  • 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…

  • 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…

  • 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…

  • 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. A response that…

  • 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…

  • 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.23305697), then the people whose measurements the model stands on (authors, title, year, address, and what each asks of…

  • 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 then accuracy…

  • 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…

  • 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…

  • 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…

Security scan

No findings

We scan names, descriptions and tool definitions for hidden instructions and other prompt-injection patterns.

Recent checks

WhenResultHTTPTime
7 h agoPassed200604 ms
17 h agoPassed200662 ms
27 h agoPassed200674 ms
37 h agoPassed200595 ms
46 h agoPassed200607 ms
Show 6 older checks
2 days agoPassed200329 ms
3 days agoPassed200691 ms
3 days agoPassed200572 ms
4 days agoPassed200619 ms
4 days agoPassed200625 ms
4 days agoPassed200830 ms