Skip to main content
Glama
ossenna-hq

ltspice-mcp

by ossenna-hq

pulse_response

Read-onlyIdempotent

Compute step-response metrics: overshoot, undershoot, settling time, peak value, and peak time from a transient waveform. Specify signal and optional window to get precise values, with distinct handling for undefined settling times.

Instructions

Use when you need step-response quality metrics: overshoot %, undershoot %, settling time, peak value and peak time. Inputs a transient .raw covering ONE step transition — ideally with the stimulus edge near t_start and enough tail to see settling.

Returns: direction (rising/falling), initial/steady-state values, peak (absolute and pct), settling_time (to within settling_tolerance_pct band). settling_time is null in three cases, kept distinct in the text and quality flags: 'never (within window)', 'undefined (full-pulse window)', and 'unknown' when the trailing window is too noisy to trust the final value (still ringing) — pass final_value there.

Definitions: overshoot is excursion BEYOND final in the step direction; undershoot is excursion beyond initial opposite the step direction. overshoot_pct = 0 means MEASURED overdamped, not missing data. settling_tolerance_pct defaults to 2% of |final - initial|; 1% and 5% are also common.

If the auto-detected initial/final (mean of first/last 10% of window) is contaminated by ringing, pass explicit initial_value/final_value. Rejects AC analysis.

For just rise/fall time without overshoot, use edge_metrics.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
stepNoStep index for .step sweeps
t_endNoWindow end in SPICE notation
formatNo'json' or 'text'
job_idNoAnalyze a specific run of a completed sweep/MC (or single) job instead of a raw_file path; pair with ``run_index``.
signalYesSignal name (e.g. 'V(out)')
t_startNoWindow start — ideally the stimulus edge. Defaults to full transient.
raw_fileNoPath to .raw transient result file. Pass this OR ``job_id`` (a job run), not both.
run_indexNo0-based run to analyze when ``job_id`` is given (default 0).
final_valueNoPost-step steady value. Auto = mean of last 10% of window.
initial_valueNoPre-step steady value. Auto = mean of first 10% of window. Set explicitly if the start is contaminated by ringing.
settling_tolerance_pctNoSettling band as percent of |final - initial|. 2% is standard; 1% or 5% also common.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
signalYes
qualityYes
warningsYes
directionYes
peak_timeYes
peak_valueYes
initial_valueYes
overshoot_pctNo
settling_timeNo
undershoot_pctNo
steady_state_valueYes
settling_tolerance_pctYes
Behavior4/5

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

Read-only/idempotent/non-destructive annotations already communicate safety; description adds contextual flags: settling_time negative in three cases with quality distinctions ('never (within window)', 'undefined (full-window)', 'unknown' when trailing window too noisy), plus rejection of AC analysis. No annotation contradiction.

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?

Long but justified for 11 params in a signal-analysis tool: lead with 'Use when...', 'Returns...', 'Definitions' convention; parameter descriptions are dense with defaults, ranges, and are free of padding. Beyond schema it is not lengthy: not a single wasted sentence for this scope.

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?

Complete for a step-response tool: 11 params fully documented, output schema, annotation flags, default/alternative semantics, explicit auto-detection setting (first/last 10%) contamination in the initial/final, window, noise desciptions. Sibling tools for rising/falling times given; output schema provides the values; semantic coverage is strong.

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

Parameters4/5

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

Schema covers 100% of 11 params; descriptions enrich defaults (0, auto = mean first/last 10%), invalid combinations (job_id OR raw_file required), output schema present; descriptive defaults added.

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?

States specific verb+resource: 'step response quality metrics: overshoot %, undershoot %, settling time, peak value, peak time.' Distinguishes from edge_metrics for rise/fall time without overshoot. Clearly identifies input (transient .raw covering ONE step, ideally edge near t_start, tail) and return values.

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?

Explicitly states when to use ('Use when you need step response quality metrics'), includes exclusion ('For just rise/fall time without overshoot, use edge_metrics') and exclusions ('Rejects AC analysis.').

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