logic-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SIGROK_CLI | No | Path to sigrok-cli if not on PATH | |
| LOGIC_MCP_OUT | No | Artifact directory (default ./out) | ./out |
| LOGIC_MCP_PROFILES | No | Extra panel YAML directory | |
| LOGIC_MCP_DSVIEW_SOCK | No | Default dsview socket | $XDG_RUNTIME_DIR/logic-mcp/dsview.sock |
| LOGIC_MCP_INSTRUMENT_SOCK | No | Default ipc socket | $XDG_RUNTIME_DIR/logic-mcp/instrument.sock |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| protocol_listA | List instrument backends, capture adapters, bus decoders, upper decoders, profiles, sinks. |
| capture_openA | Load a capture/trace file. Returns capture_id and channels. Pin maps belong on bus_decode. |
| instrument_listA | List live-capture backends (id, vendor, status, available, options_schema). |
| instrument_scanB | Discover analyzers. Omit backend to scan every implemented backend that is available. |
| instrument_openB | Open a live backend (mock, dslogic, sigrok_cli, …). Returns device + capabilities. |
| instrument_closeA | Release the open instrument. Does not delete the last LogicCapture. |
| instrument_capabilitiesA | Sample rates, channel names, trigger support for the open instrument. |
| instrument_configureA | Set live capture params (rate, channels, duration or samples, trigger). Does not start yet. |
| instrument_captureC | Run a blocking capture into the session. GUI-owned backends (dsview) do not need sample_rate_hz. |
| instrument_startB | Start capture on the open instrument. DSView uses whatever the GUI already configured. |
| instrument_stopB | Stop an in-progress capture. |
| instrument_waitA | Block until capture completes or timeout_s. |
| instrument_exportC | Ask the vendor hub to export the last capture and load it into the session. |
| bus_decodeB | Create a DecodeJob on the open capture. Same waveform can have several jobs (e.g. SPI + I2C). |
| protocol_rolesC | Channel roles and options_schema for a bus decoder. |
| interpretC | Run an upper decoder on a DecodeJob. Default sink is command_log. Add framebuffer for PNG. |
| display_analyzeC | Sugar: interpret MIPI DCS + command_log sink for a display profile. |
| display_reconstructC | Sugar: interpret MIPI DCS + command_log + framebuffer sinks. |
| session_statusC | Open capture plus all decode/interpret jobs and artifacts. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 19 tools
Most tools map to distinct workflow phases, but instrument_capture vs instrument_start plus wait, and display_analyze vs display_reconstruct, have closely overlapping responsibilities. protocol_list and instrument_list also both touch backends, so an agent could misselect without careful reading.
The instrument_* family is consistently named and object_verb names like capture_open and bus_decode are readable, but interpret is a bare verb and instrument_capabilities, protocol_roles, and session_status are noun-style rather than action-style. This mixed convention is understandable but not fully predictable.
19 tools sits in the 16-25 heavy band, though the logic-analyzer workflow is broad enough to justify many of them. Some consolidation is possible, especially around capture/start and the display sugar tools, without losing core capability.
The server covers the full capture-to-decode pipeline: discovery, opening instruments, configuration, capture, decode, upper decoding, display reconstruction, and session status. Minor gaps like explicit decode-job teardown or saved artifact handling are present but agents can generally work around them.