mcp-server-siglent-sdm3045x

Overview Schema Source Related Servers Discussions Admin

burst

Idempotent

Take up to 10,000 readings as fast as the instrument allows and return all values plus summary statistics for measurement analysis.

Instructions

Take a series of readings as fast as the instrument can and return statistics plus all values.

Readings are paced by the instrument and have no individual timestamps. Approximate rates (50 Hz mains): dc_voltage, dc_current and resistance 4/s at speed slow, 40/s medium, 175/s fast; ac functions and temperature 4/s; frequency and period 2/s. Bursts estimated to take longer than 600 s are refused. Without function the present function and range are kept; otherwise they are set as in measure.

Args: count: Number of readings, 1 to 10000. function: Measurement function. Leads in HI/LO for voltage, resistance_2w, capacitance, frequency, period, continuity, diode and temperature; in I/LO for currents; resistance_4w also uses HI Sense/LO Sense. range: Fixed range in V, A, Ω or F; omit for autorange. dc_voltage 0.6, 6, 60, 600, 1000; ac_voltage 0.6, 6, 60, 600, 750; dc_current 0.0006, 0.006, 0.06, 0.6, 6, 10; ac_current 0.06, 0.6, 6, 10; resistance_2w/4w 600, 6e3, 60e3, 600e3, 6e6, 60e6, 100e6; capacitance 2e-9, 20e-9, 200e-9, 2e-6, 20e-6, 200e-6, 0.01. Other functions have no range. speed: Only for dc_voltage, dc_current and resistance: slow (10 PLC, default, most accurate), medium (1 PLC) or fast (0.3 PLC). sensor: Required for temperature: pt100 (RTD) or thermocouple type B, E, J, K, N, R, S or T.

Input Schema

Name	Required	Description	Default
`count`	No
`range`	No
`speed`	No
`sensor`	No
`function`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 28, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint=false, idempotentHint=true) the description discloses substantial behavior: readings have no individual timestamps, pacing is instrument-controlled, bursts projected over 600 s are refused, and function/range may be mutated as a side effect. This is exactly the context annotations cannot carry, and the readOnlyHint=false is consistent with that state-changing behavior.

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?

Purpose is front-loaded, then timing behavior, then an Args block that maps cleanly to the parameters. The per-function range list is long but each value is decision-relevant, so nothing is padding; only the repeated function enumerations could be trimmed.

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?

With an output schema present, the description need not explain return values, and it still summarizes them. All five parameters, the timing/refusal constraint, and the state-mutation semantics are covered, leaving no gap an agent needs filled before calling.

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 description coverage is 0%, so the description carries the full burden, and it does: count bounds (1–10000), per-function lead wiring for function, explicit valid range values for every rangeable function, PLC meanings for speed, and the sensor requirement for temperature. This adds far more than the bare enums in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states a specific verb and resource ('Take a series of readings as fast as the instrument can') and even names the return ('statistics plus all values'). It hints at the relationship to the sibling 'measure' ('set as in measure'), but never explicitly contrasts burst with sample or read, so an agent must infer the distinction.

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

Usage Guidelines3/5

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

The description supplies practical constraints (600 s refusal limit, per-speed sampling rates that let you estimate duration, default function/range retention), which implicitly guide speed selection. However, it never says when to choose burst over sample, read, or measure, and names no exclusions.

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

Deploy Server