Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add yxy050208/multisim-mcp --skill multisim-workflowgit clone --depth 1 https://github.com/yxy050208/multisim-mcpWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/yxy050208/multisim-mcp/multisim-workflow)<a href="https://agentmods.dev/skills/yxy050208/multisim-mcp/multisim-workflow"><img src="https://agentmods.dev/badge/skills/yxy050208/multisim-mcp/multisim-workflow/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/yxy050208/multisim-mcp/multisim-workflow"><img src="https://agentmods.dev/badge/skills/yxy050208/multisim-mcp/multisim-workflow.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00064 | $0.02232 |
| Opus 5 | $0.00032 | $0.01116 |
| Sonnet 5 | $0.00013 | $0.00446 |
| Haiku 4.5 | $0.00006 | $0.00223 |
Grade A, and why
multisim-circuit-workflow scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 5d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 175 lines — stays where its author put it; the contents beside it link to each section on GitHub.
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:
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:
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 <file> --root <project> --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.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 5d ago Changed · +43 lines f0eba91aec64
- 9d ago First seen · 132 lines · 64 tokens per session scan A 637b667fef77
multisim-circuit-workflow is a skill published in the GitHub repository yxy050208/multisim-mcp (9 stars, last pushed 6d ago), licensed MIT. It adds 64 tokens to every session and 2,232 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
debugging-executions
Debug failed or wrong-output workflow executions using executions tools. Load when the user reports execution failures, unexpected node output, empty parameter values after a successful run, or a node showing a red or failed expression error.
workflow
A workflow skill for embedded-device projects that plans and runs building, flashing, debugging, observing, and diagnosis tasks.
keep-codex-fast
Diagnose Codex Desktop or CLI local-state bloat and safe recovery options. Use when sessions, archived history, logs, worktrees, or stale Codex config may be making Codex feel slow.
frontend-performance
Audit web performance depth beyond Lighthouse. Use when the user asks for a performance audit, Core Web Vitals (CWV) review, bundle-size analysis, or to optimize loading — including slow LCP/FCP/INP/CLS, a heavy JS/CSS bundle, or missing HTTP/2, text compression, browser caching, HSTS, resource hints, service worker…
systematic-debugger
A structured debugging method that finds the confirmed root cause of a software bug before changing code. It uses four phases: reproduce the problem, form hypotheses, isolate the cause, then make a fix and add a regression test.
browser-automation-studio
Reference for using Browser Automation Studio (BAS) to execute browser workflows, validate UI behavior, and debug automation failures.