LabscoMCP early access ↗
HarperZ9MCP SERVER

Project Telos

A zero-dependency local workbench that makes AI work re-checkable: every run writes a receipt, and every proof packet carries the materials needed to recompute its own verdict.

by HarperZ9 ↗Physical Sciences & Scientific ComputingCommunity

LABSCO SUMMARY

A verifier that cannot fail is not a verifier.

That is the line the whole project is built around, and it shows in the demo: it renders a scene, checks the recovered counts against the true criterion, then deliberately feeds the loop a render too small to read and shows it returning UNVERIFIABLE instead of a confident pass. Editing any load-bearing field of a packet flips the verdict to DRIFT, so a canned success is structurally impossible. Set expectations accordingly on the research packets — they are deterministic preflights with explicit non-claims, not claims about real robots, real hardware error correction, or causal discovery.

What it is

A local workbench for creating, simulating and replaying AI work, exposed as an MCP surface alongside CLI equivalents. The organising idea is a receipt: a command's output is not a claim, it is a packet whose load-bearing values a verifier recomputes from embedded materials — and which can come back MATCH, DRIFT or UNVERIFIABLE rather than always passing.

What you get

  • Four proof lanes, each with its own verifier that recomputes every load-bearing claim from materials inside the packet — agent-action, research-claim, visual-truth and build — telos.proof, telos.proof.research, telos.proof.visual, telos.proof.build
  • A doctor suite that audits the things that quietly rot: CI runtime and action-major drift, failure triage that separates blocking failures from migration warnings, README parity, static accessibility, byte budgets, protocol coverage and discoverability — telos.ci.doctor, telos.ci.triage, telos.presentation.doctor, telos.accessibility.doctor, telos.performance.doctor, telos.compatibility.doctor, telos.operator.doctor
  • A freshness check for the MCP layer itself, which compares an observed tool surface against the expected version and behavior probes — because a loaded server can be stale even when the source tree is current — telos.mcp.freshness
  • Context packaging for large codebases: budgeted, validated context packs and envelopes that hand a big workspace to a model without losing provenance — telos.context.pack, telos.context.envelope
  • A creative engine with deterministic kernels and ten runnable meters across histogram, dither, splat, cluster, audio, flicker, curvature, interaction, uncertainty and frame-budget signals — telos.creative.engine, telos.creative.kernels, telos.measurement.layers
  • Model-foundry and learning-forge lanes for routing work across hosted and local models, with executable lab contracts and a daemon loop that only promotes verified changes — telos.model.foundry, telos.learning.forge, telos.learning.labs
  • A read-only capability catalog for workstation control, plus reviewable browser-evidence packets — telos.native.control, telos.browser.evidence, telos.workstation.substrate
  • A catalog command that is the authoritative map: 69 tools across the five flagships, with 41 native ones in this server and the rest launched beside it from one manifest

Requirements

No account and no key, and no runtime dependencies at all. Node 20 or newer, with CI running on Node 24. Clone the repository and run the demo entry point; the MCP server starts over stdio through the package's own start script, and the manifest command prints ready-to-paste host config for Codex in TOML, Claude in JSON and OpenAI Agents. The package publishes telos and telos-mcp bin entries. It is a 0.2.0 source-registry package — npm publishing is operator-gated and interfaces may still move between minor versions.

Setup effort

Build from source — git clone https://github.com/HarperZ9/telos.git

See installation options