Skip to main content
Glama

edge_metrics

Read-onlyIdempotent

Quantify transition speed including rise time, fall time, and slew rate from a transient simulation by analyzing a specified time window.

Instructions

Use when you need to quantify HOW FAST one transition happened: rise time, fall time, slew rate. Inputs a transient .raw plus a time window around the edge of interest.

Returns: transition_time (10→90% by default, configurable via low_pct/high_pct), slew_rate (V/s or A/s), detected low/high levels, and the three crossing times.

Levels are auto-estimated from the first/last 10% of the window — NOT global min/max — so overshoot/undershoot doesn't poison the level estimate. Crossings are sub-sample-accurate via linear interpolation. Rejects AC analysis.

PICK THE WINDOW. If the transient has startup glitches or multiple edges, set t_start/t_end tightly around the edge you care about — otherwise you get the first edge in the full waveform, which is often the power-up artifact. Use edge_index only when multiple edges in the window are intentional.

For settling/overshoot after the edge, use pulse_response. For delay between two signals' edges, use timing_between.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
raw_fileYesPath to .raw transient result file
signalYesSignal name (e.g. 'V(out)')
stepNoStep index for .step sweeps
t_startNoWindow start time in SPICE notation (e.g. '1m', '100u'). Strongly recommended when the transient contains startup transients or multiple edges — otherwise the first edge in the full waveform is measured (often the power-up glitch).
t_endNoWindow end time in SPICE notation
edgeNoEdge direction. 'auto' infers from window endpoints.auto
edge_indexNoWhich matching edge in the window (0 = first). Use with tight t_start/t_end for determinism.
low_pctNoLow threshold percent (default 10%)
high_pctNoHigh threshold percent (default 90%)
low_levelNoAbsolute low rail level, overriding auto-detection. Use when the auto estimate (mean of first/last 10%) is biased — e.g. a rise-from-rail where early samples cluster in the fast ramp.
high_levelNoAbsolute high rail level, overriding auto-detection.
formatNo'json' or 'text'

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
transition_timeYes
slew_rateYes
low_levelYes
high_levelYes
t_low_crossingYes
t_high_crossingYes
t_mid_crossingYes
edge_directionYes
is_rise_timeYes
low_pctYes
high_pctYes
num_edges_in_windowYes
warningsYes
signalYes
Behavior4/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows it's safe. The description adds valuable behavioral details: level estimation from first/last 10% (not global min/max), sub-sample accuracy via linear interpolation, rejection of AC analysis, and potential power-up glitch issue. No contradiction with annotations.

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 well-structured: starts with purpose, lists returns, explains behavioral details, and ends with usage tips and sibling references. Every sentence adds value, though it is somewhat lengthy. Could be slightly more concise but overall effective.

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 (12 parameters, 2 required, output schema exists), the description is highly complete. It explains key parameters, limitations, and how to use effectively. The output schema covers return values, so no need to repeat them.

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 description coverage is 100%, so baseline is 3. The description adds meaningful context beyond the schema: explains auto-detection of levels, when to override with low_level/high_level, and provides examples (e.g., signal 'V(out)'). This extra guidance pushes the score to 4.

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: 'quantify HOW FAST one transition happened: rise time, fall time, slew rate.' It also explicitly distinguishes from sibling tools pulse_response and timing_between.

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 when-to-use guidance ('Use when you need to quantify HOW FAST one transition happened'), when-not-to-use (rejects AC analysis), and alternatives (pulse_response for settling/overshoot, timing_between for delay). Also gives specific guidance on window selection and edge_index.

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