Skip to main content
Glama
ossenna-hq

ltspice-mcp

by ossenna-hq

timing_between

Read-onlyIdempotent

Measure propagation delay or skew between two signals from a transient .raw file, using first threshold crossings with per-signal thresholds and direction control.

Instructions

Use when you need propagation delay / skew between TWO signals — e.g. input-to-output delay, clock-to-Q, input-skew. Inputs one transient .raw containing both signals on a shared time axis.

Returns: signed delay = t_b - t_a where t_a and t_b are the FIRST threshold crossings of signal_a and signal_b in the window. Negative delay means signal_b leads signal_a.

Thresholds default to 50% of EACH signal's own min-max range in the window — intentional for asymmetric CMOS where V_in and V_out have different rails. Override per-signal via threshold_a / threshold_b if you need absolute thresholds (e.g. VIH/VIL at fixed voltages). Set direction_a / direction_b independently (e.g. rising input → falling output for an inverter).

Picks only the FIRST crossing of each signal in the window — if both signals have multiple edges, tighten t_start/t_end around the specific edge pair you want. Rejects AC analysis.

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``.
t_startNoWindow start in SPICE notation
raw_fileNoPath to .raw transient result file. Pass this OR ``job_id`` (a job run), not both.
signal_aYesReference signal (e.g. 'V(in)')
signal_bYesDelayed signal (e.g. 'V(out)'). delay = t_b - t_a.
run_indexNo0-based run to analyze when ``job_id`` is given (default 0).
direction_aNorising
direction_bNorising
threshold_aNoAbsolute threshold for signal_a. If omitted, threshold_pct of signal_a's range is used.
threshold_bNoAbsolute threshold for signal_b. If omitted, threshold_pct of signal_b's range is used.
threshold_pctNoThreshold percent applied PER SIGNAL (not shared) — asymmetric for CMOS with different rails.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
t_aYes
t_bYes
delayYes
signal_aYes
signal_bYes
warningsYes
direction_aYes
direction_bYes
num_crossings_aYes
num_crossings_bYes
threshold_a_usedYes
threshold_b_usedYes
Behavior5/5

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

The description goes far beyond the annotations (readOnly, idempotent) by explaining the exact algorithm: first threshold crossings, signed delay semantics, per-signal threshold defaults, direction overrides, and the need to tighten window for multiple edges. No contradictions with annotations; this adds substantial behavioral context.

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 compact yet information-dense, with a clear front-loaded purpose. Each sentence contributes essential details—from usage scenarios to algorithm specifics to edge-case handling—without redundancy. It's well-structured for quick comprehension.

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?

For a tool with 14 parameters and an output schema, the description covers all critical aspects: input requirements, return value semantics, threshold logic, direction handling, edge limitation, and AC rejection. It is complete enough for an agent to use correctly without further clarification.

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 coverage is high (86%) but the description adds critical interpretive meaning beyond the schema: threshold_a/b override behavior, direction_a/b independence, and the importance of t_start/t_end when multiple edges exist. These clarifications are not explicit in the schema, enriching parameter understanding.

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 purpose: measuring propagation delay/skew between two signals, with specific examples like input-to-output delay, clock-to-Q, and input-skew. It distinguishes from siblings by focusing on two-signal timing analysis, which is distinct from broader metrics tools like edge_metrics or signal_stats.

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

Usage Guidelines4/5

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

Provides explicit scenarios for use (e.g., input-to-output, clock-to-Q) and a clear exclusion ('Rejects AC analysis'). However, it does not name alternative tools directly, but the context strongly implies when to use this tool vs others, so it's close to a 5.

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