How do I use metashunt-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@metashunt-mcp Set a trigger for current rising above 100 mA and start a continuous capture" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

metashunt-mcp

by jwachlin

Overview Schema Related Servers Score Discussions

Python

Local

MetaShunt V2 MCP server

A local MCP server that turns a MetaShunt V2 into a firmware-development current-measurement tool. You (running inside OpenCode / OpenRouter) get a clean tool interface for continuous streaming at ~6.2 kHz, high-rate burst reads up to 127.5 kHz (37,500 samples), threshold/edge detection on the live stream, and named, persistent capture sessions so you can keep data across firmware iterations and server restarts.

Architecture

OpenCode (you, model = OpenRouter)
   │   stdio (MCP)
   ▼
metashunt-mcp                     (this package)
   │   serial — USB FS, VID 1155 PID 22336 (auto-discovered)
   ▼
MetaShunt V2  ──▶  measures from ~10s of nA to ~2 A

Background capture thread. A single thread owns the serial port from the moment the server starts and reads measurement packets continuously into an in-memory ring buffer. Data is therefore always flowing and immediately queryable regardless of which tool you call.
Monotonic device-time base. Every sample carries the device's raw u32 tick (4 ticks/µs → us = ticks / 4). The 32-bit tick wraps every ~17.9 minutes and the device may reset; both cases are unwrapped/re-anchored so burst data stays time-aligned with the continuous stream even though USB-FS delivers the device's 32,000-sample buffer to the host with wall-clock delay.
Charge-preserving adaptive decimation (see below) keeps the MCP responses small without ever "missing" a current spike.

Related MCP server: Embedded Debug MCP

Install

Requires uv (see https://docs.astral.sh/uv/).

cd metashunt_mcp
uv sync
uv run metashunt-mcp          # runs the stdio server (see below)

Self-test (before wiring up an LLM)

A single command walks the whole pipeline — device discovery, connection, continuous streaming, storage, and (optionally) a burst read — and returns a non-zero exit code if any stage fails:

# against a real, plugged-in MetaShunt
uv run python scripts/selftest.py

# offline sanity check of the plumbing (no hardware)
uv run python scripts/selftest.py --simulate

# include a device burst read
uv run python scripts/selftest.py --burst           # or --simulate --burst

Options: -t SECONDS (stream duration, default 3), --rate HZ (burst rate), --log-dir DIR (where the test session lands, default /tmp/msx_selftest), --simulate (offline). Successful output ends with SELF-TEST PASSED and reports the live mean current and on-disk sample count so you can eyeball plausibility before any model connects.

Register with OpenCode

Merge clients/opencode.json's mcp.metashunt block into your opencode configuration (e.g. a project-root opencode.json) so OpenCode launches the server locally over stdio:

{
  "mcp": {
    "metashunt": {
      "type": "stdio",
      "command": "metashunt-mcp",
      "args": []
    }
  }
}

Make sure metashunt-mcp is on PATH for the environment OpenCode uses (uv run metashunt-mcp works if you put the repo on PATH, or set command to the absolute path of metashunt-mcp).

Read-only server (limited model access)

If you want to give a model measurement access without letting it change anything, register the read-only server instead of the full one. It exposes only observe-only tools (metashunt_status, metashunt_stream_now, metashunt_list_sessions, metashunt_load_session, metashunt_slice_log, metashunt_measurement_stats, metashunt_list_triggers) and drops every mutating tool (start_capture, stop_capture, burst, set_trigger, remove_trigger, delete_session). Use clients/opencode.readonly.json:

{
  "mcp": {
    "metashunt": {
      "type": "local",
      "command": ["metashunt-mcp-readonly"],
      "enabled": true
    }
  }
}

You can layer OpenCode permission rules on top (permission in opencode.json) as a second line of defense, e.g. ask/deny on the tool ids mcp__metashunt__*. The read-only server uses the same underlying capture engine; it simply never advertises the mutating tools.

The measurement protocol (what the server does)

Each on-wire measurement packet is framed as:

0xAA | U32 tick  (4/µs) | F32 current_mA | 8-bit checksum

Commands use the same framing. The burst command requests a 37,500-sample read at up to 127.5 kHz and accepts a trigger (immediate, current rising, current falling, stage index, or the KEY2 button). After a burst the device automatically returns to streaming; the server just switches back to recording the continuous stream. Streaming needs no stop command — the server simply stops listening when you call metashunt_stop_capture, and the device keeps measuring on its own.

The device logic this server relies on lives in src/metashunt_mcp/metashunt_v2_lib.py (framing, burst-command building, tick unwrapping, and the thread-safe MetaShuntV2 driver).

Decimation (important to understand)

Every data-returning tool runs the live stream / stored log through an adaptive, charge-preserving decimator rather than "keep every Nth sample", so that sharp events (a wake-up current spike, a burst edge) are preserved at full timing resolution while long steady plateaus compress hard.

Parameters (accepted by every data-returning tool):

max_points — soft cap on the number of returned points (default 1000).
threshold_pct — percent of the last decimated value that counts as a change worth emitting (default 1.0).
abs_min_threshold_ma — absolute floor for that change, so quiet signals still react (default 30 nA = 0.00003 mA).

Algorithm:

The first measurement becomes the first decimated value.
The emit threshold is max(threshold_pct × |last_decimated_value|, abs_min_threshold_ma).
Raw samples accumulate their trapezoidal integral (Δt × mean(current)) — i.e. charge — plus a running time span.
A new decimated point is emitted when either:
- current strays from the last decimated value by more than the emit threshold (a genuine change / spike / wake-up), or
- max_samples raw samples have elapsed since the last point (steady-state guarantee that flat data still yields a point every max_samples samples).
The emitted value is the time-mean of current over that interval, so the total area under the current curve (charge consumed) is preserved exactly no matter how aggressively the data is compressed. The interval is stamped at its closing wall-clock-of-device-time.
A residual tail at end-of-data is flushed so no charge is lost.

metashunt_* tools that return points also return a count and summary stats so you can sanity-check how much was compressed. A noise-heavy signal that cannot reach the max_points budget falls back to stride sampling of the adaptive output.

Example: a 10 s / 6.2 kHz stream that is flat except for one 5 ms 4 mA wake-up compresses to a handful of points (≈1000× reduction) while keeping the 4 mA peak and ~0.02% charge error.

Tools

Tool	Purpose
`metashunt_status`	connection state, capture state, ring fill, last sample, reader health
`metashunt_start_capture(session?, label?, meta?)`	begin continuous streaming into a named session (default: timestamped auto-name)
`metashunt_stop_capture`	stop recording/streaming; device keeps measuring
`metashunt_stream_now(max_points?, threshold_pct?, abs_min_threshold_ma?)`	decimated tail of the live ring buffer
`metashunt_burst(rate_hz?, trigger?, level?, max_points?...)`	device burst read (37,500 samples, up to 127.5 kHz)
`metashunt_set_trigger(name, above_ma?, below_ma?)`	host-side threshold/edge detector on the live stream
`metashunt_list_triggers`	list current trigger rules
`metashunt_remove_trigger(name)`	remove a trigger rule
`metashunt_list_sessions`	list persisted sessions (name, sample count, time span)
`metashunt_load_session(session, decimate args...)`	load a session from disk, decimated
`metashunt_slice_log(session, start_t_us?, end_t_us?, decimate args...)`	load a time window of a session
`metashunt_measurement_stats(session, window?)`	count/mean/std/min/max over a window (no bulk transfer)
`metashunt_delete_session(session)`	delete a session (parts + meta)

Time arguments (start_t_us, end_t_us) are in device-time microseconds relative to device reset/metashunt power-on (the unwrapped tick base), matching the t_us values returned by all tools.

Burst trigger options

metashunt_burst(rate_hz, trigger, level) where trigger:

immediate — capture immediately
rising — begin once current rises above level uA
falling — begin once current falls below level uA
stage — begin at the given stage index (level)
key2 — begin on the device KEY2 button

rate_hz is rounded to the device's 500 Hz steps (max 127.5 kHz). When triggered by current, level is the current in µA (the device encodes at 5 µA/LSB).

Example workflow (firmware testing)

metashunt_status — confirm it sees the device and is IDLE.
metashunt_set_trigger("wakeup", above_ma=1.0) — arm host-side detection of wake-ups.
metashunt_start_capture(label="fw_test_run_42") — start streaming to a session.
Exercise the firmware under test.
metashunt_stream_now(max_points=500) — glance at the live tail; a wake-up spike shows up as a point near mA-level even though the nominal current is nA/µA.
For a high-rate view, metashunt_burst(rate_hz=100000, trigger="rising", level=500) right before the event — the device captures 37,500 samples and the server returns them decimated.
metashunt_stop_capture — finalize the session (device keeps sampling on its own).
metashunt_list_sessions → metashunt_load_session(...) later to compare against the next firmware iteration.

Storage format (what survives on disk)

Sessions live in ~/.metashunt/logs/ (override with METASHUNT_LOG_DIR) as:

<session>.json
<session>.p0001.npz
<session>.p0002.npz
...        (one part per disk flush, appended in order)

Each .p####.npz holds the arrays t_us (float64, µs), current_ma (float32), and kind ('stream' or 'burst') so continuous and burst data stay separable. Parts are append-only and atomic: a flush writes a new part file and never rewrites old ones, which keeps appending cheap and immune to the read-modify-write races that plagued single-file logging.
<session>.json records session metadata: label, started/ended wall times, last flush time, and burst/event annotations.
list_sessions / load_session / slice_log / measurement_stats read these files, so sessions persist across server restarts.

Environment variables

Variable	Default	Meaning
`METASHUNT_BAUD`	1000000	baud for the serial link (cosmetic over USB-FS)
`METASHUNT_LOG_DIR`	`~/.metashunt/logs`	where sessions are persisted
`METASHUNT_RING_SIZE`	262144	in-memory raw ring capacity (samples)
`METASHUNT_IDLE_TIMEOUT`	2.0	reserved (idle detection)
`METASHUNT_SERIAL_READ_TIMEOUT`	0.1	per-read serial timeout (s)
`METASHUNT_DEC_THRESHOLD_PCT`	1.0	default decimation threshold percent
`METASHUNT_DEC_ABS_MIN_MA`	0.00003	default abs-min decimation threshold (mA)
`METASHUNT_DEC_MAX_POINTS`	1000	default `max_points`
`METASHUNT_SELFTEST_SIMULATE`	(unset)	set to `1` to force `scripts/selftest.py` into offline mode

Notes and limitations

Transport is stdio only; the serial I/O stays on the host machine where the MetaShunt is plugged in (OpenCode launches the server locally). No cloud / OpenRouter side ever touches the USB device.
Device time is relative (unwrapped ticks since power-on/reset), not absolute wall clock; use the t_us values in tool responses for any differencing.

Available Tools

13 tools

metashunt_burstC

Perform a high-rate device burst read.

trigger: immediate | rising | falling | stage | key2. level: current in uA for rising/falling, or the stage index for stage. Returns up to 37,500 samples at up to 127.5 kHz, decimated for return.

ParametersJSON Schema

Name	Required	Default
`level`	No
`rate_hz`	No
`trigger`	No	immediate
`max_points`	No
`threshold_pct`	No
`abs_min_threshold_ma`	No

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description bears the full burden of disclosing side effects. It states the tool returns samples and is decimated, but does not mention whether it is read-only, any permissions required, or potential side effects on the device.

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 concise and well-structured, with clear bullet-like formatting for parameters. It wastes no words, though it could be more compact by merging related explanations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema and annotations, the description should cover the tool's overall behavior, return format, and parameter details. It covers the return count and rate but omits explanations for four of six parameters and does not describe the output structure or possible errors.

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

Parameters2/5

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

The description explains 'trigger' and 'level' but does not clarify the meanings of 'rate_hz', 'max_points', 'threshold_pct', or 'abs_min_threshold_ma'. Since the schema provides no parameter descriptions (0% coverage), this is a significant gap.

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 with a specific verb ('perform') and resource ('high-rate device burst read'). It distinguishes itself from sibling tools like metashunt_status and metashunt_start_capture by focusing on burst reads.

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

Usage Guidelines2/5

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

No explicit guidance is given on when to use this tool versus alternatives. The description mentions 'high-rate' and 'burst', but does not clearly differentiate from other read/stream tools or indicate preferred use cases.

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

metashunt_delete_sessionD

ParametersJSON Schema

Name	Required	Description	Default
`session`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

metashunt_list_sessionsA

List persisted capture sessions (from .npz/.json logs).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It conveys that this reads persisted logs rather than live sessions, but does not explicitly state that it is read-only, what it searches, or what the result contains. The word 'list' implies a safe side-effect-free operation, which partially compensates.

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?

A single, tightly scoped sentence with no filler. The key information (what is listed and from where) is front-loaded and every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 0-parameter list tool, it is mostly adequate, but there is no output schema and the description does not describe the return format (session names, paths, metadata). An agent knows it will get a list but not what items look like or how to use them with sibling tools.

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?

The tool has zero parameters, so there is nothing for the description to add beyond the schema. Baseline 4 applies for a parameterless tool.

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 a specific verb (List) and resource (persisted capture sessions), adding the source (.npz/.json logs). This clearly differentiates it from sibling tools like load_session, delete_session, and start_capture.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. It does not mention, for example, using it before load_session or delete_session to enumerate available sessions, nor does it say when it should not be used.

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

metashunt_list_triggersD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

metashunt_load_sessionC

Load a session from disk, decimate, and return its data + summary.

ParametersJSON Schema

Name	Required	Description	Default
`session`	Yes
`max_points`	No
`threshold_pct`	No
`abs_min_threshold_ma`	No

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations, the description must carry the behavioral disclosure burden. It states that the operation is load+decimate+return, but does not disclose whether decimation is performed only in memory or persisted, whether the stored session is modified, any rate/resource limits, required permissions, or failure behavior. 'Decimate' is also used as jargon without explanation.

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 single sentence is lean, front-loaded with the main action, and contains no filler. It sacrifices informativeness for brevity, but what is present is well structured and memorable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 4 parameters, no output schema, and no annotations, the description is under-specified. It gives a high-level output ('data + summary') but not the decimation semantics, parameter meanings, return structure, or how it relates to session listing/capture workflows. It is only minimally viable.

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

Parameters1/5

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

Schema description coverage is 0%, so the description needed to explain the four parameters, but it only hints at the session and the decimation concept. max_points, threshold_pct, and abs_min_threshold_ma are completely unexplained, and even the required session parameter lacks format guidance. The tool name and parameter titles cannot carry this burden.

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 uses a specific verb ('load'), identifies the resource ('session from disk'), and states what comes back ('data + summary'), which clearly separates it from sibling tools like list_sessions, delete_session, and start_capture. Even without naming a sibling, the action and output are precise enough to disambiguate.

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

Usage Guidelines2/5

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

No guidance is given about when to choose this tool over alternatives such as list_sessions, slice_log, or measurement_stats. There is no mention of prerequisites like having a session id from list_sessions or any exclusions/alternatives, so an agent must infer use from the name and one-line description.

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

metashunt_measurement_statsA

Compute aggregate statistics (count/mean/std/min/max) over a session window without transferring the full dataset.

ParametersJSON Schema

Name	Required	Description	Default
`session`	Yes
`end_t_us`	No
`start_t_us`	No

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are present, so the description carries the disclosure burden. It does reveal a useful behavioral trait—computation happens server-side and avoids transferring the full dataset—but it does not disclose output shape, edge behavior for empty windows or invalid sessions, or side effects.

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 a single compact sentence. The primary verb and scope are front-loaded, and the 'without transferring the full dataset' clause adds behavioral value without padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 3-parameter tool with no annotations and no output schema, the description covers the core purpose but omits important invocation details: timestamp semantics, optional window behavior, and what the caller receives in return. It is viable but not fully complete.

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

Parameters2/5

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

Schema description coverage is 0%, and the description adds no per-parameter meaning. It does not explain the units or format of start_t_us/end_t_us, nor how the required session identifier relates to other session tools. The generic phrase 'session window' is the only link to the parameters.

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 names a concrete operation ('Compute aggregate statistics'), enumerates the exact statistics ('count/mean/std/min/max'), and scopes the tool to a session window. The phrase 'without transferring the full dataset' also helps distinguish it from raw-data siblings like metashunt_slice_log.

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?

The description establishes a clear use context: get summary statistics over a session window rather than raw data. It does not explicitly name alternatives or state when not to use it, so it stops just short of full guidance.

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

metashunt_remove_triggerD

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

metashunt_set_triggerB

Add/replace a host-side trigger watching the live stream for a crossing above above_ma and/or below below_ma (mA).

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`above_ma`	No
`below_ma`	No

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description itself must disclose behavior. It states 'Add/replace' but does not explain side effects, such as whether an existing trigger with the same name is overwritten, whether the trigger starts immediately, or what happens on invalid threshold combinations.

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 a single concise sentence that packs the essential purpose and threshold semantics without unnecessary words or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description gives enough to understand the core operation, but lacks important context such as parameter meanings for 'name', threshold validation rules, return behavior, and side effects. It is adequate but not fully complete for an agent to use confidently.

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

Parameters2/5

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

Schema coverage is 0% and the description only partially clarifies above_ma and below_ma as threshold values in mA. The required 'name' parameter is not described at all, and the exact semantics of 'and/or' and whether at least one threshold must be provided remain ambiguous.

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 a specific action ('Add/replace') and resource ('host-side trigger'), and defines the trigger condition as crossing above and/or below the given mA thresholds. It is easily distinguished from sibling tools like list_triggers and remove_trigger.

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

Usage Guidelines2/5

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

The description does not explicitly explain when to use this tool versus alternatives, such as metashunt_list_triggers or metashunt_remove_trigger. There is no guidance on conditions for creating versus replacing an existing trigger or when another tool would be more appropriate.

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

metashunt_slice_logC

Load a time window [start_t_us, end_t_us] of a session on disk.

ParametersJSON Schema

Name	Required	Description	Default
`session`	Yes
`end_t_us`	No
`max_points`	No
`start_t_us`	No
`threshold_pct`	No
`abs_min_threshold_ma`	No

TDQS

C2.7/5.0

Behavior2/5

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

There are no annotations, so the description carries the burden of explaining behavior. It does not mention whether the operation is read-only, how thresholds or max_points affect the result, whether downsampling occurs, or what output is returned.

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 a single concise sentence with no filler. It front-loads the main action and resource, though it omits important qualifying details about thresholds and output.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With six parameters, no output schema, and no annotations, the description is far too thin to give an agent complete context. It explains only the time-window concept and leaves multiple control parameters, output behavior, and edge cases undescribed.

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

Parameters2/5

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

Schema description coverage is 0%, and the description only clarifies start_t_us and end_t_us as the time-window boundaries. The meanings of max_points, threshold_pct, and abs_min_threshold_ma are left entirely unexplained, so the description does not sufficiently compensate for the missing schema descriptions.

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 description states a clear action ('Load') and a specific resource ('a time window [start_t_us, end_t_us] of a session on disk'). This distinguishes it from the sibling 'load_session' tool, though it does not explicitly contrast the two.

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

Usage Guidelines2/5

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

The description gives no guidance about when to use this tool versus alternatives such as metashunt_load_session or metashunt_measurement_stats. It implies use for time-window slicing, but does not state prerequisites, exclusions, or selection criteria.

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

metashunt_start_captureA

Begin continuous (streaming) capture into a named session.

Returns the session name used. Sampling continues in the background until :func:metashunt_stop_capture is called.

ParametersJSON Schema

Name	Required	Description	Default
`meta`	No
`label`	No
`session`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose potential side effects such as whether an existing session is overwritten, whether it creates a new session if none exists, or if any data is lost. The background capture behavior is mentioned, but other behavioral aspects are omitted.

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 concise and to the point, containing only essential information about starting capture, the return value, and the stopping condition. It avoids unnecessary detail and is well-structured for quick understanding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that this tool is part of a suite with related tools (burst, stream_now, set_trigger, etc.), the description does not explain when to use this instead of others, nor does it clarify how the capture works in relation to session management. It is minimally sufficient for a single tool but lacks broader context.

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

Parameters2/5

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

The schema has zero parameter descriptions, and the tool description does not explain what 'meta', 'label', or 'session' mean or how they affect the capture. The phrase 'named session' hints that 'label' or 'session' might be the name, but it's not explicit.

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 function: starting continuous capture into a named session, and it explicitly mentions the return value (session name). The verb 'Begin' and the object 'continuous capture' make the primary purpose unambiguous.

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?

The description indicates that sampling continues in the background until metashunt_stop_capture is called, which gives a clear usage condition (use this for ongoing capture, and use stop_capture to end it). However, it doesn't explicitly differentiate from siblings like burst or stream_now, so it's slightly incomplete but still useful.

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

metashunt_statusB

Return connection and capture status.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior3/5

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

With no annotations, the description carries the burden of indicating side effects. The verb 'Return' implies a read-only operation, but there is no explicit statement about safety, side effects, or data access. This gives moderate transparency.

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 extremely concise, using a single clear sentence without unnecessary words. It is well-structured and immediately understandable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool (no parameters, straightforward purpose), the description is largely complete. Minor ambiguity remains about the exact contents of 'status', but it does not hinder basic understanding.

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

Parameters3/5

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

The tool has no parameters, and the schema coverage is trivially 100%. No parameter semantics are needed, so a neutral score of 3 is appropriate.

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 description clearly states the tool returns connection and capture status, using a specific verb and resource. However, it does not elaborate on what aspects of status are included, nor does it distinguish from sibling tools beyond the name.

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

Usage Guidelines1/5

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

No guidance is provided on when to use this tool versus alternatives such as metashunt_start_capture or metashunt_list_sessions. The description lacks any context for selection.

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

metashunt_stop_captureA

Stop recording. The device keeps measuring; the server just stops listening. The current session is finalized on disk.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the burden of side effects and clearly discloses that the server stops listening, the device continues measuring, and the current session is finalized on disk. It does not mention reversibility or errors, but the core behavioral impact is transparent.

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 two concise sentences with no redundant or filler content. Every clause adds useful information about the tool's effect and side effects.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless stop command, the description provides enough context: it clarifies the server-side scope, confirms the device continues, and states that the session is finalized. It does not discuss return values or error states, but given the lack of an output schema and the tool's simplicity, this is not a significant gap.

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?

The tool has zero parameters and the schema coverage is complete, so there are no parameter details to add. Per the baseline for tools with no parameters, this is fully adequate.

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 action ('Stop recording') and identifies the specific resource and scope ('the server just stops listening', 'current session is finalized on disk'). It is unambiguous and easily distinguished from sibling tools like start_capture.

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 gives some behavioral context (device keeps measuring while server stops listening), which implies when to use it, but it does not explicitly state use cases or compare with alternatives. A more direct 'use when you want to end server-side capture without halting the device' would strengthen this dimension.

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

metashunt_stream_nowB

Return the most recent samples from the live ring, decimated.

max_points caps the output; the adaptive decimator preserves charge and keeps spike timing. Returns decimated (t_us, cur_ma) plus a summary.

ParametersJSON Schema

Name	Required	Description	Default
`max_points`	No
`threshold_pct`	No
`abs_min_threshold_ma`	No

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, the description carries the transparency burden. It discloses the adaptive decimation behavior and the return shape, but it does not mention side effects, failure modes, or performance implications.

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 two tight sentences with the purpose front-loaded. It uses no filler and communicates the key behavior and output format efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The return format is described as decimated (t_us, cur_ma) plus a summary, which helps given there is no output schema. However, the parameter effects beyond max_points are unclear, leaving the operational context incomplete.

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

Parameters2/5

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

Only max_points is explained as capping the output. threshold_pct and abs_min_threshold_ma are not connected to the decimation or triggering behavior, and schema coverage is 0%, so the description does not fully compensate.

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 states a specific action and resource: returning the most recent samples from the live ring, with decimation. It is clear enough to distinguish from historical/session-oriented sibling tools like slice_log and list_sessions.

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

Usage Guidelines2/5

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

It implies use on live/current data, but it does not explicitly explain when to use this instead of alternatives such as burst, slice_log, or load_session. There is no when-not-to-use guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

13 tool updatesv0.1.0Sep 6, 2026
- First observedmetashunt_burst
- First observedmetashunt_delete_session
- First observedmetashunt_list_sessions
- First observedmetashunt_list_triggers
- First observedmetashunt_load_session
- First observedmetashunt_measurement_stats
- First observedmetashunt_remove_trigger
- First observedmetashunt_set_trigger
- First observedmetashunt_slice_log
- First observedmetashunt_start_capture
- First observedmetashunt_status
- First observedmetashunt_stop_capture
- First observedmetashunt_stream_now

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.8/5.0

Disambiguation5/5

Each tool targets a distinct operation: status, capture start/stop, streaming, burst reads, trigger management, and session persistence/analysis. Even tools with empty descriptions (e.g., list_triggers, delete_session) have unambiguous names that clearly convey their purpose.

Naming Consistency4/5

All tools share the metashunt_ prefix and mostly follow a verb_noun pattern (start_capture, set_trigger, list_sessions). A few exceptions like 'status' (noun) and 'burst' (verb) deviate slightly, but the overall pattern remains predictable and readable.

Tool Count5/5

With 13 tools, the server is well-scoped for a device control and data analysis role. Each tool serves a clear, non-redundant function, covering capture, streaming, triggers, and session management without bloat.

Completeness4/5

The tool surface covers the core lifecycle: capture start/stop, live data retrieval, burst reads, trigger configuration, and session persistence with loading, slicing, statistics, and deletion. Minor gaps like device configuration or metadata retrieval exist, but agents can accomplish primary workflows without dead ends.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

ChiplabOAuth
ai.veecle
Run, build, and validate firmware on virtual hardware from your AI agent. Hardware knowledge corpus.
Embedded system Code Execution Virtualization
216
Kai CSV Profiler and Domain Watch Intake
io.dedyn.kai-system-agent
Bounded CSV profiling plus review-only host monitoring requests through one remote MCP endpoint.
1
Neonia: The Cloud Backend for AI Agents
io.neonia
Multiple MCP tools, persistent graph memory, token-saving data pointers, and more.
Knowledge & Memory Agent Orchestration Cloud Platforms
24
MTContext A
io.github.mtcontext
Connect any MCP client to MetaTrader 4/5 to read prices, manage positions, and place trades.
Finance Research & Data
1

Related MCP Servers

Bench
Embedded system Developer Tools
seayniclabs
A
license
Not graded
quality
C
maintenance
USB hardware discovery, device identification, serial communication, and diagnostics for makers and hardware engineers.
Updated 4 months ago (2026-05-20 23:27 UTC)
MIT
Embedded Debug MCP
Embedded system Shell Access
bitshelf
F
license
Not graded
quality
B
maintenance
Provides serial debugging for embedded Linux targets, enabling boot log capture, automatic login, crash detection, U-Boot interrupt, and hardware reset via MCP protocol.
Updated a day ago (2026-09-06 03:20 UTC)
-
dwf-mcp-server
Embedded system
KenosInc
A
license
Not graded
quality
C
maintenance
Enables control of Digilent WaveForms instruments (oscilloscope, AWG, logic analyzer) over USB, supporting devices like Analog Discovery 2/3 and Digital Discovery.
Updated a month ago (2026-08-05 01:14 UTC)
3
MIT
dsview-mcp
Embedded system Testing & QA Tools
modelclixxo
F
license
Not graded
quality
C
maintenance
Local MCP server for building an agent-facing integration around DreamSourceLab DSView. Enables native logic capture, protocol decode, and analysis with artifact management for I2C, SPI, and UART.
Updated 2 months ago (2026-07-01 14:05 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/jwachlin/metashunt_mcp'

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