Run your generated design through DELPHI validation

Three inputs, one call, five named results. Hand the validator your generated design, the base organism it came from, and the desired phenotype in plain English — the same prompt your generator was given. Nothing is summed: each result keeps its own gate, and a result that could not be assessed says so instead of passing.

The one call

validate_generation {
  "generated":         "winged-zebrafish",
  "base":              "zebrafish-adult",
  "desired_phenotype": "a zebrafish that glides at least 5 m from a 1 m launch and survives 10-30 C as an adult"
}

generated and base each take a design id, an inline organism document, a path to an organism-document JSON, or FASTA / plain sequence. desired_phenotype is your generator's prompt, verbatim. Whatever the parser cannot read comes back word for word under verdict.unparsed_desired_phenotype, because an unparsed requirement is an unchecked requirement.

Five named results, each with its own gate

Three statuses, and the third is the point: pass fail cannot-assess. A cannot-assess is not a pass. The verdict object withholds the word “validated” whenever a gate failed, a gate could not be assessed, a biological scale could not be assessed, or no sequence was compared:

verdict.word_validated_withheld  true
verdict.withheld_because         ["2 gate(s) failed", "2 gate(s) could not be assessed",
                                  "3 biological scale(s) could not be assessed",
                                  "no sequence was compared at any locus"]

The scorer's own composite arrives beside them, carried for reference and explicitly not the verdict:

composite_score_from_the_scorer  {"value": 0.878, "plausible": true, "version": "1.0.0",
  "components_that_ran": "P+L+G+S+E",
  "depends_on_the_desired_phenotype_text": true,
  "evaluation": {"blind_evaluated": true, "score_verdict": "FAIL", "warning": true,
                 "label": "scorer v1.0.0: blind-evaluated (168 held-out families,
                 family-out). The blind verdict on this composite is FAIL -- P1, P2
                 and P3 all fail ..."},
  "note": "the scorer thread's own frozen number, carried through for reference.
           It is NOT this report's verdict, and no gate above feeds it. ..."}

Three ways in

claude mcp add --transport http delphisci \
  https://delphisci-mcp.fly.dev/mcp

curl -s -X POST https://delphisci-mcp.fly.dev/mcp \
  -H 'content-type: application/json' \
  -H 'accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

curl -s https://delphisci-mcp.fly.dev/healthz
# {"ok":true,"files":4266,"built":"2026-11-01 05:47"}

git clone https://github.com/fractastical/delphisci
cd delphisci
npm install
(cd sim-engine && npm install)

claude mcp add delphi-sim-engine -- \
  node "$PWD/sim-engine/server.mjs"   # 54 tools
claude mcp add delphisci-local -- \
  node "$PWD/mcp/server.mjs"          # 21 tools

{ "mcpServers": { "delphi-sim-engine": {
  "type": "stdio", "command": "node",
  "args": ["sim-engine/server.mjs"] } } }

node sim-engine/validate-cli.mjs \
  "a zebrafish that glides at least 5 m from a 1 m
   launch and survives 10-30 C as an adult" \
  --base zebrafish-adult \
  --generated winged-zebrafish

node sim-engine/http.mjs   # 127.0.0.1:7341, loopback only

curl -s -X POST 127.0.0.1:7341/tool/validate_generation \
  -H 'content-type: application/json' -d '{
  "generated": "winged-zebrafish",
  "base": "zebrafish-adult",
  "desired_phenotype": "...as above..."
}' | jq '.result.results | map_values(.status)'

import { validateGeneration }
  from './sim-engine/validate/pipeline/index.mjs';
const report = await validateGeneration(
  { generated, base, desired_phenotype });

Which tools are hosted, and which are local-only

Three reasons a tool is local-only, and they are the whole rule:

1. It runs a Lean build. lean_propose compiles a submitted file. It is marked local_only in the contract, the bridge serves it only while bound to loopback, and it is never hosted.
2. It writes. organism_create, session_open, session_post, session_decide and the swarm_* tools append under sim-engine/sessions/. A hosted, unauthenticated server has nowhere honest to put that.
3. It reads repository data that is not in the deployed image. The validators read the five omics layers (about 914,000 rows), the FishShapes reference set, the captured exons and the GRCz11 coordinate tables. The hosted image packs about 2 MB of claims, unsigned TriG files and Lean law sources, and nothing else.

Read this before you trust any number above

Not an appendix. A collaborator who takes these five results at face value will be misled in six specific ways. Each one is measured, and each links to the page that proves it.

The worked example, and why five results beat one number

Re-run it yourself; it takes about four seconds. Base zebrafish-adult, generated winged-zebrafish — the same fish with its pectoral fins scaled up, length and span ×2.26, planform area ×4.45, and nothing else changed.

node sim-engine/validate-cli.mjs \
  "a zebrafish that glides at least 5 m from a 1 m launch and survives 10-30 C as an adult" \
  --base zebrafish-adult --generated winged-zebrafish

NAMED RESULTS (five, never summed)
  genotype_similarity    CANNOT-ASSESS  the generated design carries no gene-level edit ... This is not a pass
  phenotype_similarity   PASS           inside the calibrated shape distribution (body p 1)
  lean_check             CANNOT-ASSESS  no Lean law could be evaluated on this design
                                        (25 cannot-evaluate, 10 out of scope)
  functional_resolution  FAIL           19 difference(s) from the closest functional analogue are UNRESOLVED
  physics_check          FAIL           cannot glide: the reachable launch speed 0.67 m/s is below v_min
                                        8.64 m/s, so lift cannot carry the weight [achieved in 0.0 % of
                                        200 draws; median 0 m, 5-95 % 0 to 0]
                                        lifting_area_supports_mass@adult -- the lifting area is 166.37x
                                        too small: 1.91 cm2 against 317.76 cm2 needed to carry 0.007 N
                                        at 0.67 m/s

  [the scorer thread's own composite, for reference only, NOT this verdict: 0.878 (plausible), v1.0.0]

  The word "validated" is WITHHELD: 2 gate(s) failed; 2 gate(s) could not be assessed;
  3 biological scale(s) could not be assessed; no sequence was compared at any locus.

A single number would have shipped this design. Five named results show exactly where it fails, and the report names the reason at the tissue scale in a line of its own: the design grew the wing and never touched the pectoral muscle that would have to move it. The 166× lifting-area shortfall and that tissue gap are one fact seen at two scales.

The control: the real flying fish as generated

node sim-engine/validate-cli.mjs \
  "a zebrafish that glides at least 5 m from a 1 m launch and survives 10-30 C as an adult" \
  --base zebrafish-adult --generated flying-fish     # exit 2

  phenotype_similarity   PASS
  functional_resolution  PASS           every difference has a demonstrated resolution
  physics_check          CANNOT-ASSESS  INCOMPLETE: 2 of 3 hard criteria have NO MODEL and were NOT
                                        checked (temperature/survives, temperature/survives)
  [... composite: 0.933 (plausible), v1.0.0]
  The word "validated" is WITHHELD: 3 gate(s) could not be assessed; ...

The glide criterion the winged zebrafish misses, the real animal meets — so the physics separates a real glider from a design that merely has bigger fins, which is what a control is for. But its overall physics gate is cannot-assess, not a pass, and the reason is worth having: scenarios/temperature.mjs holds CT limits for zebrafish only and refuses to substitute them for another species, and no flying-fish thermal measurement was found. “Survives 10–30 °C” is unanswerable for the real flying fish from the data on hand, and the report says that rather than borrowing a constant.

Hand your agent the Claude Code skill at sim-engine/skill/delphi-studio/SKILL.md — copy it into .claude/skills/delphi-studio/ — and it has the tool sequence, what each named result means, and the refusal rules below.

Two servers, two jobs

https://delphisci-mcp.fly.dev/mcp

node sim-engine/server.mjs   # MCP over stdio
node sim-engine/http.mjs     # HTTP on 127.0.0.1:7341

Connect

claude mcp add --transport http delphisci https://delphisci-mcp.fly.dev/mcp

{
  "mcpServers": {
    "delphi-sim-engine": {
      "type": "stdio",
      "command": "node",
      "args": ["sim-engine/server.mjs"]
    }
  }
}

{
  "mcpServers": {
    "delphi-sim-engine": {
      "command": "node",
      "args": ["/absolute/path/to/delphisci/sim-engine/server.mjs"]
    }
  }
}

node sim-engine/http.mjs
curl -s 127.0.0.1:7341/contract
curl -s -X POST 127.0.0.1:7341/tool/morphogen_diffusion \
  -H 'content-type: application/json' \
  -d '{"morphogen":"shh","dims":[40,40]}'

The envelope: read it before the number

Every sim-engine tool returns a result together with where each input came from and what the result does not establish.

{
  "result":        { ... },
  "provenance":    [ { "quantity": "D", "value": 56, "kind": "measured", "source": "..." } ],
  "scope":         "what this result does NOT establish",
  "weakest_input": "assumed",
  "counts":        { "measured": 1, "assumed": 3 }
}

The co-design workflow

1. Open a session: session_open under a role label such as agent:claude-code.
2. Create or load the organism: organism_create from weighted parents, or organism_get for a reference organism such as flying-fish. It is morphological interpolation, not genetic hybridisation: a shape, not a viable animal.
3. See what can be edited: organism_list_parts, body to gene.
4. Write the spec: the brief becomes criteria (scenario, metric, comparator, threshold), passed to optimize as hard constraints. There is no text-to-spec tool yet.
5. Try an edit: organism_edit returns the new state and the Lean verdicts. A typed value is assumed unless you cite a primary source.
6. Perturb: scenario_list, scenario_run, scenario_timecourse across developmental stages.
7. Check the laws: lean_laws_list, lean_law_get, lean_check. Floating point, not a kernel proof; only accepted laws bind.
8. Optimise: optimize rejects any candidate that creates a new binding law violation, and says so when no design meets the spec.
9. Inspect provenance: every number the result rests on, and its kind.
10. Propose: session_post with kind: "proposal", never "edit".
11. A human approves in the studio UI. Agents propose; humans accept.

Rules of the road

The tools

As listed when this page was written. Ask the live list for the current set.

Checked 2026-11-01T02:41:33Z.

Local sim-engine

"HTTP only" tools are exported from sim-engine/tools/ and served by the bridge, but are not yet in the MCP server's tools/list.

Hosted delphisci MCP

Live at the 2026-11-01T06:06Z check, 16 tools: delphi_overview delphi_search_claims delphi_get_claim delphi_rank_claims delphi_graph delphi_claim_tests delphi_morpholib delphi_organisms delphi_get_organism delphi_sparql delphi_forum_read delphi_forum_register delphi_forum_post delphi_forum_respond delphi_propose_claim delphi_log_test_result. No lean_* and no validator: it serves upstream main as of its last deploy, and the law and validator tools are on a fork. The local node mcp/server.mjs in a clone has 21 tools, the six delphi_* plus the eight lean_*, leanbio_*, omics_* and design_score.

Static law mirror

/api/lean/index.json and current.json: read-only JSON of the laws and lawsets, from the same loader as the tools. It cannot run a check.