Send any Socket API command verbatim to a KingstVIS logic analyzer and receive the raw reply. Use for direct control when higher-level tools don't cover a specific operation.
Escape hatch: send any Socket API command verbatim, return the raw reply.
e.g. 'get-sample-rate', 'set-trigger --reset --pos-edge 0'. Commands must be <=2048 characters; 'ACK ...' is returned as ok=true.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | ||
| timeout_s | No |
Changes observed during successful MCP inspections.
v2.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and discloses key facts: commands are sent verbatim, replies are raw, ACK replies map to ok=true, and commands are limited to 2048 characters. It does not describe timeout behavior or non-ACK/error replies, but the pass-through nature is communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences carry the essential information, with the purpose and escape-hatch framing front-loaded. No filler or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic escape hatch with no output schema and no annotations, the description covers purpose, example usage, length limit, and one reply-format detail. It is not fully complete because timeout_s semantics and non-ACK/error response behavior are absent, which an agent would need when invoking arbitrary commands.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. It gives concrete command examples and a length constraint for 'command', but says nothing about 'timeout_s' or how it affects execution, leaving one parameter effectively undocumented except by its name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('send any Socket API command verbatim') and a clear resource (Socket API), and frames itself as an escape hatch that returns the raw reply. This distinguishes it from the dedicated sibling tools, which are typed wrappers for individual commands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'escape hatch' label implies it is a fallback for commands not covered by dedicated siblings, and the examples show the expected command format. However, it does not explicitly say when to prefer raw_command over a sibling such as get_sample_rate or set_trigger, and one example ('get-sample-rate') overlaps with an existing sibling, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.