# Multisim Circuit Workflow > Diagnose, configure, generate, simulate, and report on NI Multisim circuits through the Multisim MCP server. Use when the user asks to install or configure Multisim MCP, generate a Multisim schematic, run circuit simulation, analyze waveforms, or produce an electronic design report. - Skill: `yxy050208/multisim-circuit-workflow` (Agent Skill) - Install (CLI): `npx skillmds@latest add yxy050208/multisim-circuit-workflow` - Raw SKILL.md: https://api.skillmd.com/api/skills/yxy050208/multisim-circuit-workflow/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: yxy050208 (https://skillmd.com/u/yxy050208) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/yxy050208/multisim-circuit-workflow --- # Multisim Circuit Workflow Use the `multisim` MCP tools in this order. Do not skip pre-validation. ## 0. Verify the installation When the installed CLI is accessible, start with: ```powershell Get-Command multisim-mcp multisim-mcp --json doctor ``` Read `full_workflow_ready` and each stable `checks[].id`. Apply the provided `repair` instructions instead of repeatedly attempting COM activation. Use `doctor --json --strict` only in CI or when a non-zero incomplete-setup status is useful. Run `doctor --json --connect` only when the user wants a real COM and license probe; it may start Multisim. Preview client configuration when requested: ```powershell multisim-mcp config --client claude-desktop --python C:\Python32\python.exe multisim-mcp config --client codex --python C:\Python32\python.exe multisim-mcp config --client generic --python C:\Python32\python.exe ``` Do not write over a live client configuration. Generate a fragment, inspect it, and merge it manually. Keep the MCP server local over stdio. After the client connects, call `runtime_status` before the first experiment on a new installation. Prefer the high-level `run_circuit_experiment` tool whenever the requested schematic uses its supported component subset; it keeps the generated design, Multisim simulation, exported data, plot, and report tied to one source netlist. For a new design, use the planning gate before writing a netlist: call `plan_design_options`, wait for the user's `plan_id`/`option_id` choice, then call `select_design_option`, `prepare_design_specification`, and (after the specification approval) `prepare_netlist_draft`. Resolve candidate families with `resolve_component_requirements`; once concrete ratings and model provenance have been reviewed, call `approve_component_resolution`. That approval only authorizes a later compiler and never by itself creates SPICE, files, a schematic, or a simulation. For the bounded `signal-passive` template, call `compile_executable_netlist` next and show its pin-level `CircuitDesign`, calculated values, and SPICE preview. Before any schematic or experiment stage, call `approve_executable_netlist` with explicit component/topology/value/SPICE confirmations. This approval only authorizes schematic planning; it does not authorize file writes, stimuli, analysis commands, or simulation. To generate the approved schematic, pass the complete compiler response as `executable_netlist`, the approval artifact as `netlist_approval`, and the preview's exact `spice_netlist` as `netlist` to `create_schematic_from_netlist`; it revalidates the handoff and rejects changed SPICE text. Then call `approve_simulation_plan` with the same preview and netlist approval plus the reviewed `ExperimentSpec` (safe commands, measurements, and limits). Pass all three artifacts to `run_verified_circuit_experiment`; it revalidates the netlist, commands, and measurement contract before creating the schematic or starting Multisim. When the workbench handoff JSON is available, `multisim-mcp execute-handoff --handoff --root --json` provides a validation-only path; after explicit user confirmation, add `--confirm` to execute schematic generation followed by the verified experiment. It rejects root escapes, mismatched approvals, and existing artifacts by default. For a long-running handoff, use `--submit --confirm` after validation; the CLI creates the approved schematic first and then queues the verified experiment for the durable worker. For a durable long-running job, pass the same three artifacts and reviewed requirements to `submit_circuit_experiment`; the isolated worker persists and revalidates them before execution. After an approved run, verify the resulting `directory.manifest.json` through `inspect-project`. The manifest should contain only the sanitized `approval_provenance` identity, and a workbench result refresh should match its path, integrity, and approval/netlist/ compiled/spec digests before treating it as the current run. Legacy or direct experiments without that identity remain evidence-only. ## 1. Clarify the design Collect from the user: - Circuit function and constraints (input, output, supply, frequency). - Component set and tolerance requirements. - Required analyses: DC operating point, AC sweep, transient, or all. - Report format and whether schematic image, netlist, BOM, or CSV data are needed. ## 2. Build and validate the netlist - Write a SPICE netlist as the source of truth. - Pre-validate with `ngspice` when available before touching Multisim. - Keep node names simple and unique: `vin`, `vout`, `vdd`, `vb`, `0` work, while reserved words such as `in`/`out` can fail in the command engine. ## 3. Create or edit the design Preferred paths, in order: 1. Start from a known-good template `.ms14` and edit its decoded XML. 2. Use `decode_ms14` to get XML, edit component values carefully (RLC values require updating both the numeric parameter and display string). 3. Use `encode_ms14` to re-encode. 4. Use `open_circuit` to load the result. Do not try to rename RefDes by editing display text; Multisim renumbers on open. ### Netlist-driven alternative When building a circuit from scratch, `run_spice_netlist` is the fastest path: - Pass a SPICE netlist plus Nutmeg commands such as `dc VIN 0 10 0.1` or `tran 1u 2m`. - Multisim's command engine needs a space-free directory; the tool creates one automatically under `MULTISIM_MCP_WORKDIR` (default `C:\msre_exp`). - The tool appends `write ` without a variable list; `write path v(out)` can fail with `No such vector`. - It waits for the engine to go idle, parses the SPICE3 raw file, and returns `columns`, `n_points`, sampled `rows`, and a CSV path. - Use `output_dir` to copy `circuit.cir`, `run.log`, `result.raw`, and `data.csv` into the workspace. - Only use the safe `op`, `dc`, `ac`, or `tran` command subset. Never request unrestricted command mode unless the user explicitly asks for trusted local security research and the server operator enabled it. ### High-level generated experiment For supported RLC, independent sources, diode, BJT, MOSFET, and op-amp circuits: 1. Call `run_circuit_experiment` with the validated netlist, analysis command, output directory, and report title. 2. Treat the returned `.ms14`, schematic PNG, raw, CSV, SVG, and Markdown as one experiment bundle. 3. Verify `success`, `n_points`, and expected numeric relationships before reporting completion. 4. Generated schematic probes are experimental; use command-engine CSV/raw data as the authoritative experiment result. ## 4. Run simulations - Call `connect`, then `open_circuit`. - `connect` is idempotent; call it at the start of the workflow even if another step already connected. - Call `enum_outputs` and `enum_inputs` to discover valid names. - Use `run_dc_operating_point`, `run_ac_sweep`, `run_ac_single_frequency`, or `run_transient`. - Use `run_spice_netlist` when the design is netlist-only or a schematic does not exist yet; call `connect` (and `new_circuit` if needed) first. - If a waveform input is required, use `set_input_data_sampled` or `set_input_data_raw` before the transient. - If a tool reports not ready, call `stop_simulation`, check `circuit_info`, and retry once. ## 5. Analyze data Returned data shape depends on the analysis: - DC: two rows `(value,)`. - AC: three rows `(frequency, real, imag)`. - Transient: two rows `(time, real)`. Compute mean, min, max, rise/fall, bandwidth, gain, or FFT as required. Keep the raw data in a file when the user asks for a report. `run_spice_netlist` returns its own parsed columns and CSV; use those directly when the schematic-level analysis tools are not applicable. When a concrete reversible `DesignPatch` has already been proposed, prefer `evaluate_design_patch` over an informal rerun. It evaluates the unchanged baseline and exactly one in-memory candidate under the same hard requirements, retains before/after diagnoses and the inverse patch, and never applies the candidate automatically. Treat `adoption_eligible` as evidence for a separate approval step, not as permission to overwrite the design. ## 6. Produce the report - Export `get_circuit_image`, `report_netlist`, and `report_bom`. - Use `generate_report` with the analysis dicts returned by `run_dc_operating_point`, `run_ac_sweep`, and `run_transient` to write a Markdown report with circuit info, exports, and measured tables. - For `run_spice_netlist`, write the report from the returned CSV/rows and include the netlist, analysis commands, measured tables, and plots. - Write a Markdown or CSV report with circuit description, component table, simulation setup, measured values, plots, and conclusions. - Cite measured data and flag anything that was estimated or not verified. - Enumeration tools return structured dicts such as `{"outputs": [...]}`; read the list from the `outputs`/`inputs`/`components` key. ## Safety - Always stop simulations before changing inputs or saving. - Prefer a working directory for outputs; never overwrite the user's source design without `save_circuit` to a new path. - Do not set `unsafe_commands` or invoke `do_command_line` in ordinary circuit workflows. Those capabilities are disabled by default for prompt-injection resistance. - This project is unofficial and not affiliated with NI.