Skip to main content
Glama
ossenna-hq

ltspice-mcp

by ossenna-hq

bode_metrics

Read-onlyIdempotent

Analyze LTspice AC simulations to extract filter cutoffs, roll-off slope, gain/phase at specific frequencies, and crossing points (e.g. unity-gain, phase-margin) in one call.

Instructions

AC / Bode-plot analysis in one tool, selected by mode. The response shape depends on the mode: mode='filter' — filter type, cutoffs (at ref_db below passband), passband gain/ripple, stopband rejection, transition BW, pole-order, and an auto-estimated asymptotic roll-off slope (dB/decade) — covers cutoff AND slope in one call. mode='slope' — magnitude slope (dB/decade + dB/octave) between f_low and f_high; pick endpoints ≥1 decade past any knee. Use when you need a custom window or dB/octave ('filter' already reports an auto-estimated asymptotic dB/decade slope). mode='point' — magnitude (dB + linear) and phase at each of frequencies (log-axis interpolation; out-of-range clamps + warns). mode='crossing' — every frequency where quantity crosses level (phase is UNWRAPPED first); the escape hatch for custom queries like unity-gain (0 dB) or phase-margin (-180°) frequencies.

Pass all_steps=true to compute the chosen mode for every step of a .step sweep in one call (returns a steps list instead of a single result) — e.g. the -3 dB cutoff at every value of a stepped component.

To analyze a run of a completed sweep/MC job, pass job_id + run_index instead of raw_file (combine with all_steps to also sweep the .step axis within that run).

For loop-gain stability margins use stability_metrics; for resonant peaks & Q use resonance.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeYesWhich view of the AC response to compute: 'filter' — LPF/HPF/BPF/BSF type, cutoffs, ripple, rejection, and an auto-estimated asymptotic roll-off slope (dB/decade) — so one call gives both cutoff AND slope (args: ref_db, flatness_db, passband_range, stopband_range) 'slope' — magnitude slope between two explicit frequencies; use when you need a custom window or dB/octave ('filter' already reports an asymptotic dB/decade slope) (args: f_low, f_high — both required) 'point' — magnitude (dB + linear) and phase at specific frequencies (args: frequencies — required; include_unwrapped_phase) 'crossing' — every frequency where magnitude/phase crosses a level (args: quantity + level — required; direction, f_start, f_end, max_results, min_separation_decades)
stepNoStep index for .step sweeps
f_endNocrossing: upper frequency bound.
f_lowNoslope: low frequency bound (required).
levelNocrossing: level to cross, in the units of `quantity`.
f_highNoslope: high frequency bound (required).
formatNo
job_idNoAnalyze a specific run of a completed sweep/MC (or single) job instead of a raw_file path; pair with ``run_index``. The analyzed run's swept parameter values are echoed back under ``params`` (with ``run_index``), so you can tell which sweep point this is without a separate batch_results call. Combine with ``all_steps`` to sweep the .step axis WITHIN that run (a value-list/param sweep stores each run as its own raw — address those by run_index, not all_steps).
ref_dbNofilter: cutoff reference below passband (dB).
signalYesSignal to analyze: a single trace (e.g. 'V(out)') or a transfer-function ratio of two traces (e.g. 'V(out)/V(mid)'), which divides the two complex AC waves — the way to express an inter-stage gain, loop gain, or PSRR the simulator doesn't store as its own trace.
f_startNocrossing: lower frequency bound.
quantityNocrossing: 'magnitude_db' | 'magnitude_linear' | 'phase_deg'.
raw_fileNoPath to AC analysis .raw result file. Pass this OR ``job_id``, not both.
all_stepsNoCompute the metric for EVERY step of a stepped (.step) sweep in one call, instead of the single `step`. Returns `steps`: a list of per-step results (each tagged with its `step` index). A step whose computation fails is returned with an `error` field rather than aborting the whole call. On a non-stepped raw this returns a single entry. Use this for 'give me the cutoff/slope/gain at every step'.
directionNocrossing: edge direction.any
run_indexNo0-based run to analyze when ``job_id`` is given (default 0).
flatness_dbNofilter: passband flatness tolerance (dB).
frequenciesNopoint: frequencies to query (SPICE notation).
max_resultsNocrossing: cap on returned crossings.
passband_rangeNofilter: optional [f_lo, f_hi] passband override.
stopband_rangeNofilter: optional [f_lo, f_hi] stopband region.
min_separation_decadesNocrossing: merge crossings within this many decades.
include_unwrapped_phaseNopoint: also return cumulative unwrapped phase.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNo
levelNo
stepsNo
paramsNo
pointsNo
ref_dbNo
signalNo
delta_dbNo
f_low_hzNo
quantityNo
warningsNo
all_stepsNo
crossingsNo
directionNo
f_high_hzNo
run_indexNo
step_countNo
filter_typeNo
gain_low_dbNo
gain_high_dbNo
span_decadesNo
cutoff_low_hzNo
cutoff_high_hzNo
cutoff_level_dbNo
estimated_orderNo
passband_low_hzNo
passband_gain_dbNo
passband_high_hzNo
passband_ripple_dbNo
slope_db_per_decadeNo
slope_db_per_octaveNo
stopband_rejection_dbNo
transition_bandwidth_hzNo
nearest_pole_order_estimateNo
rolloff_slope_db_per_decadeNo
Behavior5/5

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

The description goes well beyond the readOnly/idempotent annotations by detailing behaviors: out-of-range frequencies clamp and warn, all_steps returns per-step errors, signal can be a ratio that divides complex waves, job_id echoes back params, and crossing merges within min_separation_decades. These are non-obvious behavioral details not inferable from annotations alone.

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

Conciseness5/5

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

The description is well-structured with mode-by-mode bullet points that mirror the schema organization. Despite the tool's complexity, every sentence contributes unique information—no redundancy or filler. The format is scannable and logically ordered, making it easy for an agent to extract the relevant mode's details quickly.

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?

The description fully covers the tool's scope, including all four modes, parameter inheritance across modes, edge-case behaviors (clamping, merging, error handling), and integration with swept/MC jobs. It also references sibling tools for alternatives and explains output shapes (steps list, unwrapped phase). No significant context is missing.

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?

Although the JSON schema already covers 96% of parameters with descriptions, the tool description adds crucial clarifications: which parameters are required for each mode, the units for crossing level, the relationship between raw_file and job_id (mutually exclusive), and the distinction between run_index and all_steps for swept loads. This enriches the parameter semantics beyond what the schema provides.

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 clearly states the tool's function as AC/Bode-plot analysis with four distinct modes, each precisely defined. It also distinguishes from sibling tools by explicitly recommending stability_metrics for loop-gain margins and resonance for peaks/Q, leaving no ambiguity about what this tool does.

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?

The description gives explicit guidance on when to use each mode (e.g., 'Use when you need a custom window or dB/octave' for slope) and when to prefer alternatives. It also explains the trade-offs between raw_file vs job_id, all_steps vs step, and how to combine them, providing actionable usage context beyond the schema.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ossenna-hq/MCP_LTSpice'

If you have feedback or need assistance with the MCP directory API, please join our Discord server