Loading ToolBench
MCP server for RTL simulation and verification with command execution, workspace management, and file synchronization
This MCP server provides 5 tools for RTL verification and remote workspace synchronization. The tool definitions include proper parameter schemas with types and descriptions, and most tools have non-empty descriptions. However, several issues limit the score: (1) output schemas are not documented, we cannot verify what fields the tools return, forcing LLMs to guess at response structure; (2) error handling is minimal, tools raise exceptions but do not provide recovery guidance (e.g., 'Workspace is not bound. Call bind_workspace first' is good, but most errors lack this guidance); (3) some parameter descriptions are terse or lack context for LLM reasoning; (4) the tools address a specialized domain (RTL verification) with heavy reliance on external state (metadata files, remote servers) that could be better abstracted. Naming is clear and action-oriented (bind_, sync_, get_, run_, execute_). Parameter validation is present (e.g., SSH port 1-65535) but response shapes are opaque.
Bind a local source directory to a topic_id and write .mcp/workspace.json.
Execute an arbitrary shell command. Use for operations not covered by predefined templates: file management, log inspection, environment checks, one-off scripts, etc. Routes through the same executor as run_predefined_command.
Return skill guidance for the agent. - Omit `name` to get the index and loading hints. - Pass `name='simulators'` to get simulator and command catalog. - Pass a skill name such as `vcs` to load that skill markdown.
Execute a pre-configured simulator command defined in tools.toml. Looks up the command template, substitutes params, then runs the resulting shell command through the same executor as execute_command. SSH routing is handled automatically based on the simulator's config. Prefer this over execute_command when the operation is covered by a template.
Sync flow: 1. Read local metadata to get topic_id. 2. Call remote workspace ensure API. 3. Push local files by rsync. 4. Call remote workspace finalize API (when dry_run is false).
Output schemas are not documented. The tools return dict() or other responses, but LLMs cannot infer what fields to expect. For example, bind_workspace returns 'dict' with unknown structure, making it impossible for downstream tools to extract topic_id or other IDs for chaining. This violates the response-shaper pattern.
Error handling lacks recovery guidance. Most errors are raw exceptions (RuntimeError, ValueError) with minimal context for the LLM to recover. E.g., execute_command timeout or SSH failure messages are not actionable, should include suggestions like 'Increase timeout' or 'Check SSH credentials'. Only bind_workspace's 'Workspace is not bound. Call bind_workspace first' follows the recovery-guide pattern.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 37 | - | v1 |
Parameter 'params' in run_predefined_command accepts arbitrary object without schema. The description says 'e.g. {"files": "rtl/top.sv", "top": "tb"}' but does not validate structure or document required vs optional keys. LLMs cannot reason about which params are mandatory for each simulator/command pair.
Sensitive parameters exposed: auth_token, ssh_key_path, and ssh_key_passphrase appear as tool parameters. While these may be necessary for remote operations, storing passphrases in parameters risks exposure in logs and traces. Should use server-side secret injection from environment or vault.
Tool descriptions lack clarity on when to use each tool. For example, run_predefined_command says 'Prefer this over execute_command when the operation is covered by a template', but the get_skill(name='simulators') return format is not documented, making it hard for the LLM to know what commands are available without calling the tool first.
Workspace binding logic creates external state (metadata files in .mcp/workspace.json). This couples the MCP server to local filesystem state and makes multi-agent or stateless deployments difficult. The on_existing enum ('ask', 'reuse', 'overwrite', 'fail') suggests interactive behavior, but MCP tools must be stateless, 'ask' cannot work in agent contexts.
sync_workspace async definition but no indication of how cancellation is handled or whether the tool supports Multi Round-Trip Requests (MRTR) for user confirmation before finalization. The dry_run parameter is a workaround, not a proper confirmation pattern.