Skip to main content
Glama

sim_run

Run mixed-signal simulations on the focused Altium project to generate a results document and retrieve per-analysis waveform summaries.

Instructions

Run Altium's mixed-signal simulation of the focused project.

Runs the analyses set up for the project: with sim_setup_analysis, or in Altium's Simulation Dashboard. A run started from a script performs an operating point, DC sweep, transient and AC together (MEASURED: the dashboard's on/off switches are not honoured).

It succeeds only when the run produced its results document (a .sdf, opened in its own tab), and fails with SIM_NOT_RUN when nothing appeared. The results are saved and read back: the reply carries each analysis's waves with min, max, first and last, and sim_get_results gives the traces.

Typical workflow: 1. Activate one of the project's schematic sheets. 2. Use sim_get_readiness + sim_attach_* to make sure every component has a SPICE model. 3. Place probes on measurement nodes with sch_place_probe. 4. Set the analyses with sim_setup_analysis. 5. Call sim_run, then sim_get_results for the traces.

Args: analysis: Free-form label echoed back in the response. Does not drive Altium, the project's setup does.

Returns: Dict with success, ran, results_document (the .sdf path), results_saved, results (per analysis, per wave: unit, points, min, max, first, last; magnitude for an AC wave), analysis and note.

Input Schema

NameRequiredDescriptionDefault
analysisNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.1

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden and does so thoroughly: it discloses that script-started runs perform operating point, DC sweep, transient and AC together regardless of dashboard switches, succeeds only when an .sdf results document appears, and fails with SIM_NOT_RUN otherwise. It also explains that results are saved and read back, including which summary values are returned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is longer than typical, but the complexity justifies most of the detail. It is front-loaded with purpose and behavior, then structured with workflow, Args, and Returns sections, though a few sentences could be tightened without losing meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, lack of annotations, and the fact that its behavior depends on external setup, the description is complete enough for correct invocation. It covers prerequisites, success/failure semantics, parameter meaning, workflow, and return shape, even though an output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description fully compensates by explaining that the only parameter, analysis, is a free-form label echoed back and does not drive Altium. This prevents an agent from assuming the argument selects the analysis configuration.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: running Altium's mixed-signal simulation of the focused project. It clearly distinguishes the tool from setup and retrieval siblings by explaining that it executes the configured analyses and produces the results document.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit typical workflow with prerequisites: activate a schematic sheet, verify SPICE readiness, place probes, configure analyses, then call sim_run and sim_get_results. It also names the relevant setup alternatives, sim_setup_analysis and the Simulation Dashboard, so the agent knows where configuration belongs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools