Loading ToolBench
FastMCP 3.2+ server for USB PC oscilloscopes - PicoScope, Hantek, and simulator backends with waveform capture, measurements, and fleet integration.
OscilloscopeMCP uses a portmanteau pattern where 6 tools each accept an 'operation' enum parameter, collapsing multiple distinct operations into single tool definitions. While schemas are present with proper types and enums, this design violates the single-responsibility principle (pattern:tool). Tool names (scope_device, scope_configure, etc.) are generic and do not reflect specific actions, they read like resource names rather than verb_noun patterns. Descriptions are present but brief (20-60 chars), lacking context on WHEN to use each operation or what state changes occur. Parameter descriptions exist but are minimal. No output schemas are documented, forcing LLMs to guess response structure. Error handling and recovery guidance are absent.
Waveform capture: single, preview, export_csv, export_summary, last
Channel configuration: channel, timebase, coupling, range, simulator_profile
Device management: list, connect, disconnect, status, capabilities, backends
Help and documentation: discover, tool_help, status, quickstart, faq, hardware_guide
Measurements from capture: all, vpp, frequency, duty, rise_time, fresh
Trigger control: set, get, arm, force
Portmanteau anti-pattern: 6 tools collapse 30+ distinct operations into single definitions via 'operation' enum. Violates single-responsibility principle. LLMs cannot infer intent from tool name alone (e.g., 'scope_device' could mean list, connect, disconnect, status, capabilities, or backends). Requires LLM to reason about operation enum values before selecting tool.
Tool names are resource-centric (scope_device, scope_configure) rather than action-centric (list_devices, connect_device, configure_channel). Baseline: 90% of A+ tools start with action verbs (get, list, create, search, update). These names read like nouns, not verbs, forcing LLMs to read descriptions to understand what happens.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 43 | <=2025-11-25 | v2 |
No output schemas documented. Tool descriptions state what operations exist but do not describe return types, fields, or structure. LLMs cannot plan downstream calls or extract data without knowing response format. Baseline: 100% of A+ tools have documented return types.
Descriptions are 20-60 characters, below the 50-200 char baseline for LLM-optimized descriptions. They state WHAT operations exist but not WHEN to use each, what state changes occur, or prerequisites. E.g., 'Device management: list, connect, disconnect, status, capabilities, backends' lists operations but does not explain when to call 'connect' vs 'status'.
No error handling or recovery guidance. Tools do not document what errors can occur, whether they are retryable, or what the LLM should do next. Baseline: error responses must tell the LLM what to do next.