ProbePilot Studio

What it does

ProbePilot Studio is a browser-native circuit workspace where a person and an agent share one live design, simulation, and diagnostic bench.

The agent can inspect exact circuit state, add or update components, create semantic terminal-to-terminal connections, validate the design, and run deterministic or local SPICE simulations. The same project renders as an interactive circuit, a PCB preview, and a 3D assembly preview.

Diagnosis changes the control model. The person creates a faulty virtual bench. The agent can request measurements between exact test points, but ProbePilot stops until the person operates the virtual meter. Each reading becomes evidence with a stable ID. After two readings, the agent can publish evidence-linked hypotheses and stage a repair. Only the person can approve and apply that repair. The agent can then verify the repaired bench against the intended design.

ProbePilot keeps the hidden fault outside the DOM, Zustand state, local project files, JSON exports, Circuit JSON, and every WebMCP response. The agent must diagnose from observations instead of reading the answer.

Why WebMCP fits

A circuit editor exposes structured concepts that coordinate-based browser automation handles poorly: components, terminals, wires, revisions, test points, measurement modes, evidence, and repair targets. ProbePilot registers nine narrow WebMCP tools that operate on those concepts directly.

The agent does not need to infer a resistor from pixels or guess which terminal a click represents. Tool schemas describe supported component kinds, strict inputs, revision requirements, and human-owned boundaries. The browser UI and agent use the same command layer, so each action updates the circuit, inspector, activity history, and project persistence together.

Better human-agent experience

The agent handles repetitive construction, validation, simulation, and diagnostic reasoning. The person supplies the evidence that a software agent should not invent and controls the consequential repair decision.

ProbePilot enforces those distinctions in application code:

• WebMCP can request a measurement but cannot take one.
• The agent cannot create the bench or reveal its private fault.
• Hypotheses cite completed human measurements.
• A repair needs at least two measurements.
• The agent stages a repair; the person applies it.
• Verification compares the repaired bench with the frozen intended design.

WebMCP implementation

ProbePilot registers nine tools through document.modelContext.registerTool(...): studio_inspect, design_build_circuit, design_update_components, design_remove_elements, design_validate_and_simulate, bench_request_measurement, bench_update_hypotheses, bench_stage_repair, and bench_verify.

Zod validates each tool input. Mutation tools enforce expected revisions, component support, agent locks, and bench lifecycle rules. The public inspection DTO includes only the information the agent should see. A private bench engine owns the implementation fault and computes measurements and verification results without serializing the fault into public state.

Challenges

The hardest problem was preserving a useful shared workspace without turning the agent into an unrestricted UI robot. ProbePilot needed one command model for the UI and WebMCP, strict stale-revision handling, and a private bench state that could produce measurements without leaking the answer.

The 3D viewer also needed a compatibility boundary. ProbePilot converts its project model into Circuit JSON, lazy-loads @tscircuit/3d-viewer, keeps the camera stationary until the person moves it, and falls back to a six-angle SVG preview when WebGL fails.

Accomplishments

• Nine working WebMCP tools with strict schemas and revision checks.
• A complete design, simulation, diagnosis, repair, and verification journey.
• Human-only measurement and repair approval enforced below the UI.
• A hidden deterministic fault excluded from every agent-visible surface.
• Twenty-one components with honest Design, SPICE, and Bench capability labels.
• Local ngspice WASM plus circuit, PCB, and interactive 3D views.
• Local project CRUD, JSON import and export, URL-restored workspace state, and a 100-entry activity history.
• 346 automated tests covering the domain, UI, persistence, WebMCP contract, and viewer adapters.

What I learned

WebMCP works best when a site exposes domain decisions instead of mirroring every button. The useful boundary was authority: which facts the agent may inspect, which evidence only a person can produce, and which actions require human approval.

Circuit JSON and tsCircuit provided a practical rendering and interoperability layer, but simulation support still needed explicit verification. ProbePilot labels each catalog item by capability rather than implying that every rendered component has a trusted behavioral model.

What's next

The next step is to add reusable diagnostic cases, richer SPICE models, and a portable evidence bundle that can be reviewed outside the browser. A future hardware bridge could let a person collect readings from a physical instrument while keeping the same WebMCP request, evidence, approval, and verification contract.

Built With

• firebase
• github
• react
• tailwind
• tscircuit
• typescript
• vitejs
• vitest
• webassembly
• webmcp
• zod
• zustand