Skip to main content
Glama

bode_metrics

Read-onlyIdempotent

Analyze AC simulation results to extract filter characteristics, magnitude slope, magnitude/phase at specific frequencies, or crossing frequencies from LTspice .raw files or completed jobs.

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. mode='slope' — magnitude slope (dB/decade + dB/octave) between f_low and f_high; pick endpoints ≥1 decade past any knee. 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
raw_fileNoPath to AC analysis .raw result file. Pass this OR ``job_id``, not both.
job_idNoAnalyze a specific run of a completed sweep/MC (or single) job instead of a raw_file path; pair with ``run_index``. Combine with ``all_steps`` to sweep the .step axis WITHIN that run.
run_indexNo0-based run to analyze when ``job_id`` is given (default 0).
signalYesSignal name (e.g. 'V(out)')
modeYesWhich view of the AC response to compute: 'filter' — LPF/HPF/BPF/BSF type, cutoffs, ripple, rejection (args: ref_db, flatness_db, passband_range, stopband_range) 'slope' — magnitude slope between two frequencies (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
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'.
quantityNocrossing: 'magnitude_db' | 'magnitude_linear' | 'phase_deg'.
levelNocrossing: level to cross, in the units of `quantity`.
directionNocrossing: edge direction.any
f_startNocrossing: lower frequency bound.
f_endNocrossing: upper frequency bound.
max_resultsNocrossing: cap on returned crossings.
min_separation_decadesNocrossing: merge crossings within this many decades.
frequenciesNopoint: frequencies to query (SPICE notation).
include_unwrapped_phaseNopoint: also return cumulative unwrapped phase.
ref_dbNofilter: cutoff reference below passband (dB).
flatness_dbNofilter: passband flatness tolerance (dB).
passband_rangeNofilter: optional [f_lo, f_hi] passband override.
stopband_rangeNofilter: optional [f_lo, f_hi] stopband region.
f_lowNoslope: low frequency bound (required).
f_highNoslope: high frequency bound (required).
formatNo

Output Schema

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

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

Annotations declare readOnlyHint, destructiveHint, idempotentHint. Description adds mode-specific behavior: response shape depends on mode, out-of-range clamping with warnings for point mode, and all_steps returns steps list with error handling.

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?

Well-structured with mode descriptions in a clear list, front-loaded purpose. Slightly long but every sentence adds value; no waste.

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 23 parameters and output schema, the description covers all key aspects: modes, parameter combinations, error handling, use cases, and alternatives. Complete for a complex tool.

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 coverage is 96%, but the description goes beyond by detailing each mode's required arguments (e.g., ref_db for filter, f_low/f_high for slope), explaining all_steps behavior, and clarifying job_id/run_index use.

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 it performs AC/Bode-plot analysis selected by mode, and explicitly distinguishes from siblings stability_metrics and resonance. Each mode is defined with specific output details.

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?

Provides explicit guidance: when to use each mode, when to use all_steps, when to use job_id vs raw_file, and directs to sibling tools for other analyses.

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/Cognitohazard/ltspice-mcp'

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