LM Tools Bridge

LM Tools Bridge is a VS Code extension that exposes workspace tools over MCP. External MCP clients connect to a local stdio manager, bind to a target VS Code workspace, and then use the bridged tools.

English | 中文

English

What It Is

LM Tools Bridge exposes VS Code workspace tools to external MCP clients.

• Windows only
• Designed for terminal MCP clients and agent workflows

Requirements

• VS Code
• Node.js on PATH

If node is missing, the extension shows a startup warning with Install with winget and Download Node.js.

Quick Start

1. Install the extension in VS Code.
2. Open your project folder or .code-workspace.
3. Let the extension activate once.
4. The extension will:
   • auto-start the local MCP server
   • sync stdioManager.js and stdioManagerRuntime.js to %LOCALAPPDATA%\lm-tools-bridge
5. Long-lived MCP manager processes keep using node "%LOCALAPPDATA%\\lm-tools-bridge\\stdioManager.js". Runtime updates no longer require manually restarting the chat thread. During a runtime update, stateful bind and bridged calls may return an MCP internal error; wait up to 3 seconds, then retry once. A successful runtime reload invalidates the current workspace bind and requires a fresh lmToolsBridge_bindWorkspace. If the runtime reload fails, that stdio manager becomes unavailable and the client must let VS Code create a fresh manager.

MCP Client Example

Codex example:

[mcp_servers.lm_tools_bridge]
command = "powershell.exe"
args = [
  "-NoProfile",
  "-Command",
  "node \"$env:LOCALAPPDATA\\lm-tools-bridge\\stdioManager.js\""
]
enabled = true

The PowerShell wrapper is recommended because many MCP clients do not expand environment variables inside raw args.

Basic Usage Flow

1. Start one stdio manager for the client session.
2. Read lm-tools://guide once.
3. Call lmToolsBridge_bindWorkspace with a short title.
4. Set cwd to an absolute path for either:
   • the project path
   • the .code-workspace path
   • relative paths are invalid
5. After bind succeeds, use bridged workspace tools from tools/list, or call lmToolsBridge_callBridgedTool.

Notes:

• Handshake is required before using bridged workspace tools.
• lmToolsBridge_bindWorkspace is the entrypoint when the task calls for vscode-tools-like workspace search, code navigation, diagnostics, or VS Code IDE actions, or explicitly includes phrases like vscode-tools or use vscode.
• Read lm-tools://guide for the concise bind, tool-discovery, routing, and recovery guide. It is guide-only and does not embed live status snapshots or example payloads.
• VS Code-sourced workspace tools are exposed with an lm_ prefix. For example, copilot_searchCodebase is exposed as lm_copilot_searchCodebase.
• lm_formatFiles is exposed by default but disabled by default. It formats the files selected by pathScope through VS Code's document-format command so the configured formatter selection, including editor.defaultFormatter, is honored, then saves changed files after you enable it.
• Handshake discovery.bridgedTools returns tool names only. discovery.toolDefinitionsTool describes the local lmToolsBridge_getToolDefinitions helper plus input/output schemas, including its required wrapper title. Before invoking a bridged tool, first use lmToolsBridge_getToolDefinitions with a short title and only tool names whose ToolDefinitions are unknown; helper-returned definitions include MCP display/UI metadata such as title, _meta, annotations, and outputSchema, while omitting VS Code metadata such as tags. Do not guess or infer input schemas from tool names, then reuse known ToolDefinitions. It is available only after lmToolsBridge_bindWorkspace succeeds and is not callable through lmToolsBridge_callBridgedTool.
• Bridged tool descriptors include MCP Apps/OpenAI Apps metadata for the shared ui://lm-tools-bridge/tool-result-card.html resource. Tool results still include text content fallback plus structuredContent; result _meta is reserved for component-only hydration data.
• lmToolsBridge_bindWorkspace, lmToolsBridge_getToolDefinitions, and lmToolsBridge_callBridgedTool require a short wrapper title parameter for readable MCP UI labels. lmToolsBridge_callBridgedTool does not pass that title to the target bridged tool. The names-only discovery resource is lm-tools://tool-names, and it returns an actionable bind/rebind error until the workspace is actively bound.
• If a tool argument uses pathScope, use the compact syntax summary in that parameter's description; the full syntax is in lm-tools://guide.
• When a new stdio manager runtime generation is published, the stdio transport stays connected and lm-tools://guide remains readable. During the update window, stateful bind, ToolDefinition lookup, bridged tool call, and bridged resource read operations return an MCP internal error with a wait-up-to-3-seconds retry hint. A successful runtime reload keeps the manager alive but invalidates the current workspace bind until the client binds again. A failed runtime reload makes that stdio manager unavailable and returns a fatal MCP error until VS Code creates a fresh manager.

Workspace Settings

• When lmToolsBridge.useWorkspaceSettings=true, the extension writes its own config through the current workspace scope.
• In a saved .code-workspace, settings are written to the workspace file.
• In a single-folder workspace, settings are written to .vscode/settings.json.
• Reads keep the existing fallback behavior: single-folder workspaces prefer WorkspaceFolder values and fall back to Workspace values when needed.

Troubleshooting

• node is missing: install Node.js, restart VS Code, and retry.
• Untitled multi-root workspace is not supported: save it as a real .code-workspace file first.

中文

是什么

LM Tools Bridge 是一个 VS Code 扩展,用于通过 MCP 向外部客户端暴露当前 workspace 的工具能力.

• 仅支持 Windows
• 面向终端 MCP 客户端和 agent 工作流

依赖

• VS Code
• 系统 PATH 上可直接执行 node

如果缺少 node,扩展启动时会弹出提示,可直接选择 Install with winget 或 Download Node.js.

快速开始

1. 在 VS Code 中安装扩展.
2. 打开项目目录或 .code-workspace.
3. 让扩展至少激活一次.
4. 扩展会自动:
   • 启动本地 MCP server
   • 将 stdioManager.js 和 stdioManagerRuntime.js 同步到 %LOCALAPPDATA%\lm-tools-bridge
5. 长驻的 MCP manager 进程依然通过 node "%LOCALAPPDATA%\\lm-tools-bridge\\stdioManager.js" 启动. runtime 更新现在不再需要手工重启聊天线程. runtime 更新期间,依赖状态的 bind 和 bridged 调用可能返回 MCP internal error; 最多等待 3 秒后重试一次. 如果 runtime reload 成功,当前 workspace bind 会失效,因此 MCP 客户端需要重新调用 lmToolsBridge_bindWorkspace. 如果 runtime reload 失败,当前 stdio manager 会直接不可用,需要让 VS Code 创建一个新的 manager.

MCP 客户端示例

下面是 Codex 配置示例:

[mcp_servers.lm_tools_bridge]
command = "powershell.exe"
args = [
  "-NoProfile",
  "-Command",
  "node \"$env:LOCALAPPDATA\\lm-tools-bridge\\stdioManager.js\""
]
enabled = true

推荐包一层 PowerShell,因为很多 MCP 客户端不会自动展开原始 args 里的环境变量.

基本使用流程

1. 为当前客户端会话启动一个 stdio manager.
2. 先读取一次 lm-tools://guide.
3. 调用带简短 title 的 lmToolsBridge_bindWorkspace.
4. cwd 需要传绝对路径,可以是:
   • 项目路径
   • .code-workspace 路径
   • 相对路径无效
5. 绑定成功后,通过 tools/list 使用桥接后的 workspace tools,或继续调用 lmToolsBridge_callBridgedTool.

说明:

• 使用桥接 workspace tools 之前,必须先完成握手.
• 当任务需要类似 vscode-tools 的 workspace search、code navigation、diagnostics 或 VS Code IDE actions,或明确说出 vscode-tools 或 use vscode 时,应从 lmToolsBridge_bindWorkspace 开始.
• 读取 lm-tools://guide,里面包含精简后的 bind、tool discovery、routing 和 recovery 指南,不会内嵌 live status snapshot 或 example payload.
• 来自 VS Code 的 workspace tool 对外统一带 lm_ 前缀. 例如 copilot_searchCodebase 会暴露为 lm_copilot_searchCodebase.
• lm_formatFiles 默认已暴露但默认禁用,启用后会按 pathScope 选择文件,通过 VS Code 的 document format 命令执行格式化,从而遵循已配置的 formatter 选择(包括 editor.defaultFormatter),然后保存实际发生变更的文件.
• 握手里的 discovery.bridgedTools 只返回 tool name. discovery.toolDefinitionsTool 会包含本地 helper lmToolsBridge_getToolDefinitions 的用法说明和 input/output schema, 包括必填 wrapper title. 调用某个 bridged tool 前, 必须先用带简短 title 的 lmToolsBridge_getToolDefinitions 获取 ToolDefinition 未知的 exact tool 完整 ToolDefinition; helper 返回的 definition 包含 title、_meta、annotations 和 outputSchema 等 MCP display/UI metadata, 但会省略 tags 等 VS Code metadata. 不得根据 tool name 猜测或推断 input schema, 后续复用已知 ToolDefinition. 它只能在 lmToolsBridge_bindWorkspace 成功后调用, 且不能通过 lmToolsBridge_callBridgedTool 包装调用.
• Bridged tool descriptor 会包含指向共享 ui://lm-tools-bridge/tool-result-card.html resource 的 MCP Apps/OpenAI Apps metadata. Tool result 仍保留 text content fallback 和 structuredContent; result _meta 只用于 component hydration data.
• lmToolsBridge_bindWorkspace、lmToolsBridge_getToolDefinitions 和 lmToolsBridge_callBridgedTool 都要求传入简短 wrapper title 参数用于可读 MCP UI label. lmToolsBridge_callBridgedTool 不会把该 title 传给目标 bridged tool. names-only discovery resource 是 lm-tools://tool-names, 它在未绑定或绑定失效时会返回可执行的 bind/rebind 提示.
• 如果某个工具参数使用了 pathScope,先看该参数 description 中的压缩语法说明; 完整语法在 lm-tools://guide 中.
• 当新的 stdio manager runtime generation 发布后,stdio transport 会保持连接,且 lm-tools://guide 仍可读取. 更新窗口内,依赖状态的 bind、ToolDefinition lookup、bridged tool call 和 bridged resource read 会返回 MCP internal error,并提示最多等待 3 秒后重试. 如果 runtime reload 成功,当前 workspace bind 会失效,需要重新执行 lmToolsBridge_bindWorkspace. 如果 runtime reload 失败,当前 stdio manager 会直接不可用,并持续返回 fatal MCP 错误,直到 VS Code 创建新的 manager.

工作区设置

• 当 lmToolsBridge.useWorkspaceSettings=true 时,扩展会按当前 workspace scope 写入自己的配置.
• 在已保存的 .code-workspace 中,配置写入 workspace 文件本身.
• 在单文件夹 workspace 中,配置写入 .vscode/settings.json.
• 读取时保留现有 fallback: 单文件夹 workspace 优先读取 WorkspaceFolder,缺失时回退到 Workspace.

故障排查

• 缺少 node: 安装 Node.js,重启 VS Code 后再试.
• Untitled multi-root workspace is not supported: 先把当前多根 workspace 保存成真实 .code-workspace 文件.