Loading ToolBench
A confusingly-named client that connects to Claude Code's VS Code bridge, not actually MCP
This server presents as an MCP tool suite but is fundamentally a WebSocket client to Claude Code's VS Code bridge, not an actual MCP server. All 12 tools have basic descriptions (10-40 chars) and input schemas are present but extremely minimal. Most parameters lack descriptions entirely. No error handling guidance, no idempotent hints, no structured output documentation. The naming is reasonable (verb-first: get*, open*, close*, execute*) but parameters are underdescribed. This is a STDIO-equivalent facade wrapped in a custom JSON-RPC protocol, not MCP-compliant.
Check if a document has unsaved changes
Close all diff view tabs
Close a tab in VS Code
Execute code in a notebook environment
Get the current text selection in the active editor
Get diagnostics (errors, warnings) for a file or all files
Get the latest text selection in the active editor
Zero parameter descriptions across all 12 tools. 'startText', 'endText', 'preview', 'selectToEndOfLine', 'makeFrontmost', 'uri', 'old_file_path', 'new_file_path', 'new_file_contents', 'tab_name', 'filePath' parameters appear in schemas but lack descriptions. This violates pattern:tool-description, LLMs cannot infer parameter meaning from names alone ('status' could mean HTTP status, project status, or active flag).
No output schemas documented. Tools like getOpenEditors, executeCode, getDiagnostics return unspecified structures. The CLI code shows parsing logic (e.g., 'editors.editors', 'diagnostics.diagnostics') but no schema definition is visible in tool registration. LLMs cannot plan downstream tool calls without knowing return field names and types.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 27 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | 2024-11-05+ | v1 |
Get list of open editors in VS Code
Get workspace folder paths
Open a diff view between two files
Open a file in VS Code editor
Save a document in VS Code
Tool descriptions are 20 - 40 characters, far below the 194 char baseline for A+ tools (p10=34, p90=392). Descriptions lack context for when to call the tool (WHEN) vs similar alternatives, prerequisites, or what the return structure contains. E.g., 'Get list of open editors in VS Code' doesn't explain what fields are returned or when to call this instead of getWorkspaceFolders.
Not an actual MCP server, it's a WebSocket client to Claude Code's bridge. The package.json description admits 'confusingly-named client that connects to Claude Code's VS Code bridge, not actually MCP'. Transport is custom JSON-RPC over WebSocket, not HTTP (deprecated) or Streamable HTTP (current). This cannot be integrated with standard MCP hosts.
No error handling guidance. Tools do not document what errors they return, whether errors are retryable, or how to recover. Per pattern:recovery-guide, errors must tell the LLM what to do next. A failed executeCode call returns nothing actionable to guide the agent.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The Risk field in metadata shows WRITE vs READ_ONLY, but tools do not declare idempotency or retry behavior. Pattern:idempotent-operation requires agents to know which calls are safe to retry, this is missing.
Parameter naming inconsistency: 'close_tab' uses snake_case while most other tools use camelCase (filePath, startText, endText). Also, 'close_tab' is weak naming, should be 'closeTab' (verb_noun) for consistency with openFile, saveDocument.
WebSocket transport with custom JSON-RPC is not MCP-compliant. No stateless protocol versioning, no _meta per-request, no capabilities negotiation. The initialize() call shown in CLI suggests a stateful handshake, which violates the current MCP spec's stateless design (removed Mcp-Session-Id).