mcp-project-helper

一个最小的 MCP（Model Context Protocol）服务器，为编程 AI 助手——特别是 Claude Code——提供一组小而安全的工具（tools），用于处理某一个特定项目目录：在其文件中搜索、读取文件、搜索本地文档以及运行预先批准的检查（测试）。

项目分阶段实现（Stage 0 → Stage 3，提示词历史见 PROMPTS.md）；当前阶段为 Stage 3：最终定稿。全部四个 tool 均已实现并通过测试覆盖（Stage 1），服务器已接入 Claude Code 并通过 Claude Code CLI 用真实请求手动验证（Stage 2–3，证据见 evidence/）。

关于项目

与其让助手直接访问 shell 或不受限制地访问文件系统，项目提供由四个 tools 组成的狭窄、易于审计的接口：

• search_project_files — 文本搜索，限制在项目根目录内。

• read_project_file — 读取单个文件，限制在项目根目录内。

• get_docs — 在此仓库的 docs/ 中搜索本地文档。

• run_project_check — 运行白名单中的检查（目前是 tests），但绝不运行任意 shell 命令。

这是一个教学项目（家庭作业）——其目标不是覆盖所有可能的用例，而是展示一个端到端、诚实记录的 MCP 服务器示例：从框架和安全原语（Stage 0），经过 tools 的真实实现（Stage 1），到与 IDE 代理集成以及可复现的真实调用证据（Stage 2–3）。

Related MCP server: GPT Commander

什么是 MCP 以及代理连接如何工作

MCP（Model Context Protocol） 是一种基于 JSON-RPC 的开放协议，描述了 AI 助手（客户端/主机，例如 Claude Code）如何发现并调用由独立进程（MCP 服务器）提供的外部工具（tools），而助手无需直接访问主机的 shell、网络或文件系统。

本项目使用 stdio 传输——这是本地工具最简单、最常用的方式：

1. 主机（Claude Code）读取其 MCP 配置（.mcp.json），并将服务器作为普通本地子进程启动，使用指定的命令/参数和环境变量。

2. 主机和服务器通过该子进程的 stdin/stdout 交换 JSON-RPC 消息（因此要求 stdout 仅保留给协议使用——参见“日志与调试”一节）。

3. 主机调用 initialize() — 服务器以其名称/版本（mcp-project-helper 0.1.0）和功能作为响应。

4. 主机调用 list_tools() — 服务器返回已注册 tools 的列表，包含其名称、描述以及由 MCP SDK 从函数签名生成的输入参数 JSON Schema（inputSchema）。

5. 当用户（或模型本身）决定调用某个 tool 时，主机发送 call_tool(name, arguments)；服务器执行相应的 Python 函数并返回结构化结果（见下文“工具输出契约”）或 tool 级别的错误。

6. 不打开任何网络端口：服务器的生命周期完全绑定到主机启动的子进程——如果主机关闭连接，子进程即终止。

这里不涉及任何 LLM/AI API 调用（OpenAI、Anthropic 等）：此服务器只是提供由客户端（Claude Code）调用的 tools；get_docs 中的“搜索”只是按 Markdown 章节进行的简单确定性子串匹配，没有 embeddings/向量数据库。运行服务器不需要任何 API 密钥。

此服务器中什么算作 tool

Tool 是一个普通的 Python 函数，用 @mcp.tool() 装饰，接受 JSON 可序列化的参数并返回 dict[str, Any]。MCP SDK 自动：

• 从函数参数的签名和类型注解生成 inputSchema（JSON Schema）——无需在任何地方手动描述该模式；

• 将返回值注解 -> dict[str, Any] 转换为 tool 的结构化输出（outputSchema/structuredContent），见下文“工具输出契约”；

• 将 tool 函数内部未处理的 Python 异常转换为带 tool 级别错误的结构化结果（CallToolResult.is_error = True），而不会使 MCP 会话本身崩溃。

所有四个注册都集中在 server.py:37-58；每个面向 MCP 的薄包装（其 docstring 成为模型可见的 tool 描述）将调用委托给 tools/*.py 中的真实实现，将协议层签名与逻辑分离。

技术栈

• Python 3.14（pyproject.toml 中 requires-python = ">=3.10" — 这是所用 MCP SDK 的实际下限，而不是声称只有 3.14 才能工作）。

• 官方 MCP Python SDK（包 mcp，安装版本 2.0.0）— 提供服务器框架（mcp.server.MCPServer）、tools 注册（@mcp.tool()）和 stdio 传输（mcp.run(transport="stdio")）。

• pytest — 唯一的开发依赖，用于测试套件。

• 没有 LLM/AI API 集成，也没有网络传输（未配置 HTTP/SSE）— 见上一节。

架构

src/mcp_project_helper/
  server.py        точка входа: создаёт MCPServer, регистрирует tools, запускает stdio
  config.py        корень проекта / корень docs / настройки логирования / whitelist проверок / лимиты
  security.py      resolve_within_root() — единый шлюз ограничения путей
  logging_setup.py логирование в stderr (+ опционально файл), не затрагивая stdout
  tools/
    search_project_files.py   поиск текста в пределах корня проекта
    read_project_file.py      чтение одного файла в пределах корня проекта
    get_docs.py                поиск по секциям markdown в docs/
    run_project_check.py       запуск подпроцесса из белого списка

每个处理文件的 tool 在打开任何路径之前都会经过 security.resolve_within_root(root, relative_path)。config.py 从环境变量 MCP_PROJECT_HELPER_ROOT（默认 ./demo_project）定义项目根目录，因此服务器可以指向任何项目而无需修改代码。

已实现的 MCP tools

search_project_files(query, path=".", max_results=50)

递归地在 path 下（相对于项目根目录；默认是整个根目录）的文本文件中搜索 query 子串的精确匹配。跳过 config.IGNORED_DIR_NAMES 中的目录（.git、.venv、__pycache__、node_modules 等）以及任何 *.egg-info 目录。文件会检查二进制内容（前 4 KB 中的 NUL 字节或无效 UTF-8），静默跳过而不是报错。绝不跟随指向根目录之外的目录或文件的符号链接——每个候选路径除了 os.walk 不跟随目录符号链接的标准行为外，还会额外通过 resolve_within_root 检查。

max_results 上限为 config.SEARCH_RESULTS_CAP（200）；超过 config.SEARCH_MAX_LINE_CHARS（300）的匹配行会被截断；大于 config.SEARCH_MAX_FILE_BYTES（2 MB）的文件会被跳过而不是扫描。

实现：tools/search_project_files.py:41-130。

read_project_file(path)

按路径 path（相对于项目根目录）读取单个文本文件。拒绝目录、不存在的文件和二进制内容（NUL 字节或无效 UTF-8）。内容限制为 config.READ_MAX_FILE_BYTES（200 KB）— 更大的文件返回截断内容而不是被拒绝。

实现：tools/read_project_file.py:25-69。

get_docs(query=None, max_results=10)

在 docs/*.md（递归）中搜索，按 Markdown 标题拆分为章节。当提供 query 时，返回标题或正文包含搜索子串（不区分大小写）的章节，每章注明源文件和标题。不带 query 时，返回每个文件一个章节的列表——即存在哪些文档的清单。仅受 config.get_docs_root() 限制——绝不涉及项目根目录。

max_results 上限为 config.DOCS_RESULTS_CAP（50）；片段（snippets）限制为 config.DOCS_MAX_SNIPPET_CHARS（800 个字符）。

实现：tools/get_docs.py:58-114。

run_project_check(check_name)

运行白名单中的检查。check_name 在任何内容运行之前就在 config.ALLOWED_CHECKS 中查找——未知名称立即引发错误，子进程绝不会启动。白名单中的 argv 通过 subprocess.run(argv, shell=False, cwd=<项目根目录>, timeout=...) 执行：不使用 shell，使用固定的工作目录，调用方不会向命令行添加任何内容。

实现：tools/run_project_check.py:32-90。

白名单

ALLOWED_CHECKS = {
    "tests": [sys.executable, "-m", "pytest", "-q"],
}

定义于 config.py:55-57。使用 sys.executable（而不是简单的字符串 "pytest"）是为了确保检查始终使用与服务器相同的解释器/环境运行，无论 PATH 中第一个是什么。这里有意没有 lint 条目：此仓库中没有 ruff 依赖或配置，因此接入“lint”检查要么是虚构的，要么是欺骗。以后可以添加它（config.ALLOWED_CHECKS["lint"] = [sys.executable, "-m", "ruff", "check", "."]），当 ruff 成为具有真实配置的项目实际依赖时——白名单机制已经支持这一点，无需任何其他代码更改。

超时（config.CHECK_TIMEOUT_SECONDS，默认 60 秒）和输出量限制（config.CHECK_MAX_OUTPUT_CHARS，默认每个流 20,000 个字符）适用于每次检查运行。

工具输出契约

每个 tool 从带有 -> dict[str, Any] 注解的函数返回一个普通 Python dict；MCP SDK 自动将其识别为 tool 的结构化输出（填充 CallToolResult.structured_content 并输出 outputSchema）——这里没有任何地方手动将结果序列化为 JSON 字符串。错误情况（无效输入、路径越界、未知检查、文件未找到、二进制内容等）引发 Python 异常而不是返回 dict；SDK 自动将其转换为带 tool 级别错误的结果（CallToolResult.is_error = True）。唯一的例外是检查超时：这是成功启动的检查的合法执行结果，而不是输入错误，因此它作为结构化 dict {"status": "error", ...} 返回，而不是引发异常。

search_project_files

{
  "status": "success",
  "query": "apply_discount",
  "path": ".",
  "matches": [
    {"file": "demo_app/services.py", "line": 12, "text": "def apply_discount(order: Order, percent: float) -> float:"}
  ],
  "count": 4,
  "truncated": false
}

read_project_file

{
  "status": "success",
  "file": "demo_app/models.py",
  "content": "...",
  "size": 397,
  "truncated": false
}

get_docs

{
  "status": "success",
  "query": "whitelist",
  "results": [
    {"file": "architecture.md", "heading": "Whitelist", "snippet": "..."}
  ],
  "count": 1,
  "truncated": false
}

run_project_check

{
  "status": "success",
  "check_name": "tests",
  "exit_code": 0,
  "stdout": "...",
  "stderr": "",
  "truncated": false
}

超时时：{"status": "error", "check_name": ..., "error": "check timed out after 60s", "exit_code": null, "stdout": "...", "stderr": "...", "truncated": ...}。

上述字段名称以及 status/count/truncated 约定被视为面向未来的稳定契约，而非实现细节。

安全限制

• 路径限制：security.resolve_within_root (security.py:19-50) 拒绝 绝对路径、通过 .. 的目录穿越（任意深度）、NUL 字节以及指向配置根目录之外的 符号链接。在 read_project_file 和 search_project_files 中相对于项目根目录使用， 并在 search_project_files 遍历期间对每个候选文件再次使用。由 tests/test_security.py 中的 unit 测试覆盖，并通过 Claude Code 的真实负面测试手动确认（见下方 "检查结果"，测试 6）。

• 遍历时不通过符号链接越界： search_project_files 和 get_docs 从不跟随指向目录的符号链接（os.walk 的默认行为）， 并完全跳过指向文件的符号链接。

• 无任意 shell 命令：run_project_check 在运行任何内容之前，将请求的检查名称 与 config.ALLOWED_CHECKS 进行校验 (config.py:55-57)；未知名称立即被拒绝， 检查本身通过 subprocess.run(argv, shell=False, ...) 执行，使用固定的 cwd， 且不包含调用方添加的任何参数。

• 所有地方输出受限：每个 tool 都限制返回的数据量——搜索和 docs 使用 max_results + 硬性限制， 文件读取有字节限制，检查输出有字符限制 + 超时——因此任何调用都不能返回无限量的数据 或无限期运行。

• stdout 保持干净：所有日志都通过 logging_setup.py 输出到 stderr（并可选择输出到日志文件）； 服务器中没有任何内容写入 stdout，该输出保留给 MCP 协议的 JSON-RPC framing。

• 日志中无秘密：服务器完全不接受任何 API 密钥或凭据。每个真实的 tool 调用都会记录 tool 名称、其安全的输入参数（查询字符串、路径、检查名称、结果数量/大小——但绝不记录文件内容）以及 最终的 status=success/status=error。

日志与调试

每个真实的 tool 调用都会通过公共 logger mcp_project_helper（stderr，加上通过 MCP_PROJECT_HELPER_LOG_FILE 的可选文件）记录一行， 例如（来自 evidence/tool-calls.log 的真实行）：

INFO mcp_project_helper: tool=search_project_files query='apply_discount' path='.' max_results=50 matches=4 truncated=False status=success
INFO mcp_project_helper: tool=read_project_file path='demo_app/models.py' size=397 truncated=False status=success
INFO mcp_project_helper: tool=run_project_check check_name='tests' exit_code=0 status=success
INFO mcp_project_helper: tool=read_project_file path='../../../../etc/passwd' status=error

文件内容从不被记录——只记录调用元数据 （路径、查询字符串、大小、数量、退出代码）。日志配置——logging_setup.py:20-42。

调试方法：

• 日志级别由 MCP_PROJECT_HELPER_LOG_LEVEL 控制（DEBUG、 INFO、WARNING、ERROR、CRITICAL；默认为 INFO）。

• 日志文件由 MCP_PROJECT_HELPER_LOG_FILE 指定；默认情况下（未设置此 变量时）仅写入 stderr。从 Claude Code 启动时 （.mcp.json），它指向 evidence/tool-calls.log。

• 切勿在服务器代码中使用 print()——stdout 保留给 JSON-RPC 协议；任何多余的 stdout 输出都会破坏 stdio 传输。

• 要查看当前 Claude Code 会话中实际发生了哪些调用，请打开 MCP_PROJECT_HELPER_LOG_FILE 指向的文件 （evidence/tool-calls.log），或手动启动服务器 （python -m mcp_project_helper.server）并查看 stderr。

安装

python3 -m venv .venv
source .venv/bin/activate
pip install -e ".[dev]"

唯一的运行时依赖是 mcp 包；pytest 仅是 开发/测试依赖（两者都固定在 pyproject.toml 中）。

环境配置

配置通过环境变量设置——将 .env.example 复制为 .env，如有必要可修改值：

服务器不需要秘密（API 密钥、令牌）——.env.example 仅包含 安全的路径和日志级别示例，而 .env 被 git 忽略（见下方"项目结构"）。

启动 MCP 服务器

直接启动服务器（它将等待 stdin 上的客户端——这对 stdio 传输的 MCP 服务器来说是正常的；通过 Ctrl+C 退出）：

python -m mcp_project_helper.server

运行测试套件：

pytest -q

直接运行 demo 项目的自身测试（run_project_check("tests") 默认运行的内容， 因为 MCP_PROJECT_HELPER_ROOT 默认指向 demo_project）：

cd demo_project && pytest -q

与 Claude Code 集成

此仓库包含一个 project-scoped 文件 .mcp.json，位于仓库根目录——这是专门为 Claude Code 的配置 （与 .vscode/mcp.json——native MCP host VS Code 的单独配置 不同；见下方详细比较）。

Claude Code 在打开项目文件夹时发现 .mcp.json，将服务器作为子进程启动， 并通过 stdio 以 JSON-RPC 与其通信——与本项目所有自动化测试中使用的 传输方式相同，只是由 Claude Code 本身启动，而非测试 harness。

已确认的端到端场景：Claude Code CLI → MCP server → custom tools。 所有 6 个验证请求（见下方"检查结果"）都通过 Claude Code CLI 与此服务器实际执行，通过 .mcp.json 连接——不仅是配置了， 而是实际调用了，并附有真实截图和 server-side 日志记录。

Claude Code 的配置

.mcp.json：

{
  "mcpServers": {
    "mcp-project-helper": {
      "command": "${CLAUDE_PROJECT_DIR:-.}/.venv/bin/python",
      "args": ["-m", "mcp_project_helper.server"],
      "env": {
        "MCP_PROJECT_HELPER_ROOT": "${CLAUDE_PROJECT_DIR:-.}/demo_project",
        "MCP_PROJECT_HELPER_LOG_FILE": "${CLAUDE_PROJECT_DIR:-.}/evidence/tool-calls.log"
      }
    }
  }
}

${CLAUDE_PROJECT_DIR} 由 Claude Code 本身展开为仓库被克隆到的目录的绝对路径， 因此该文件不包含特定于机器的路径，git clone 后无需修改。使用的正是带 fallback 值 ${CLAUDE_PROJECT_DIR:-.} 的形式，而非裸的 ${CLAUDE_PROJECT_DIR}：没有 :-. 时变量不会展开，Claude Code 会尝试字面执行 ${CLAUDE_PROJECT_DIR}/.venv/bin/python 作为可执行文件路径（此 错误在 Stage 2 的第一版配置中确实被观察到，见 REPORT.md）。MCP_PROJECT_HELPER_ROOT 被显式设置为 ${CLAUDE_PROJECT_DIR:-.}/demo_project，以确保传递给服务器的项目根目录 是明确的，不受 config.py 中自身默认值的影响。

平台说明：.venv/bin/python 是 Unix（macOS/Linux）的 venv 结构， 本项目的所有部分都使用它。在 Windows 上 等效路径是 .venv\Scripts\python.exe；要也支持该 平台，.mcp.json 需要第二条特定于 Windows 的条目 （或包装脚本）——这没有做，因为项目 仅在 macOS 上开发和验证。

VS Code 的配置

此仓库还包含 .vscode/mcp.json—— 用于 VS Code 内置 MCP 主机（由 GitHub Copilot Chat 的代理模式使用）的单独工作区配置：

{
  "servers": {
    "mcp-project-helper": {
      "type": "stdio",
      "command": "${workspaceFolder}/.venv/bin/python",
      "args": ["-m", "mcp_project_helper.server"],
      "env": {
        "MCP_PROJECT_HELPER_ROOT": "${workspaceFolder}/demo_project",
        "MCP_PROJECT_HELPER_LOG_FILE": "${workspaceFolder}/evidence/tool-calls.log"
      }
    }
  }
}

同一个 stdio 服务器 mcp-project-helper，MCP_PROJECT_HELPER_ROOT 设置为 ${workspaceFolder}/demo_project，MCP_PROJECT_HELPER_LOG_FILE 设置为 ${workspaceFolder}/evidence/tool-calls.log。

为什么是两个文件，而不是一个：.mcp.json 和 .vscode/mcp.json 遵循 不同的、不兼容的模式，它们的路径替换变量在主机之间 不可互换：

• .mcp.json（Claude Code 配置）使用顶层键 mcpServers，并将 ${CLAUDE_PROJECT_DIR:-.} 展开为仓库根目录。

• .vscode/mcp.json（native MCP host VS Code 配置）使用 顶层键 servers、显式字段 "type": "stdio"，并改为将 ${workspaceFolder} 展开为打开的文件夹路径。 VS Code 的 MCP 主机不理解 ${CLAUDE_PROJECT_DIR}——当尝试 直接从 VS Code 打开 .mcp.json 时，变量会字面传递，服务器无法启动 （spawn ${CLAUDE_PROJECT_DIR}/.venv/bin/python ENOENT）——这是实际观察到的错误，也是单独的 .vscode/mcp.json 出现的原因。将每个主机的配置 存储在自己的文件中，使用自己的变量，可以避免此错误，并允许 两个工具使用同一个克隆，而不会让一个配置 损害另一个的语法。

.vscode/mcp.json 是 .gitignore 中忽略 .vscode/* 的一般规则的唯一例外； 其他本地 VS Code 状态（settings.local.json 等）不被跟踪。

VS Code 验证状态：.vscode/mcp.json 在语法和语义上 正确（与工作的 Claude Code 配置相同的服务器、相同的命令/环境变量），并已作为 JSON 验证。此外， 通过真实截图 evidence/vscode_mcp_server_connected.png 确认了内置 native MCP host VS Code 确实根据此配置启动服务器的事实： Starting server mcp-project-helper → Connection state: Running → Discovered 4 tools，并在同一输出中附有 mcp_project_helper 进程自身 stderr 日志中的确认行。这不等同于 通过 VS Code 界面调用 custom tools 的确认——没有 通过该界面执行任何用户场景（search_project_files 等），也不声称已验证。唯一 IDE 集成，已确认到用户实际调用 tools 的程度 （所有 6 个场景的截图 + server-side 日志）——是 Claude Code CLI，见 下方"检查结果"。与两者都分开：通过 Claude Code Desktop / VS Code 内的 Claude Code 扩展的集成在本会话中完全未验证——不要与 native MCP host VS Code（本节）或 Claude Code CLI 混淆。

如何启用 MCP

简要说明（详情见上方各小节）：

Claude Code：

1. 创建 venv 并安装依赖（"安装"部分）。

2. 在 Claude Code 中打开仓库根目录（从仓库根目录运行 claude）。

3. Claude Code 发现 .mcp.json，并一次性提示确认 服务器 mcp-project-helper 的工作区信任——确认。

4. 执行 /mcp（或在终端中运行 claude mcp list），确认 mcp-project-helper 已连接并带有 4 个 tools。

VS Code（native MCP host，Copilot Chat 代理模式）：

1. 像为 Claude Code 一样创建 venv——.vscode/mcp.json 期望 相同的 .venv/bin/python。

2. 在 VS Code 中将仓库根目录作为文件夹打开。

3. VS Code 发现 .vscode/mcp.json 并提示启动服务器—— 启动/确认信任。

4. 通过 MCP: List Servers 检查状态。

两种方案都假定使用 Unix 结构的 venv（.venv/bin/python）；在 Windows 中为 .venv\Scripts\python.exe（未配置，见上文）。

验证请求

六个通过 Claude Code CLI 实际执行的场景，用于确认集成（完整结果表格见 evidence/README.md）：

1. 通过 MCP 查找 demo_project 中所有使用函数 apply_discount 的位置 → 预期调用 search_project_files。

2. 通过 MCP 读取文件 demo_app/models.py 并简要说明其中定义了哪些模型 → 预期调用 read_project_file。

3. 使用项目的 MCP 文档，说明 MCP 服务器有哪些安全限制 → 预期调用 get_docs。

4. 通过 MCP 工具检查 demo_project 的测试是否通过 → 预期调用 run_project_check。

5. 仅使用 MCP 工具，在 demo_project 中找到 apply_discount 的实现，然后读取定义该函数的文件，并解释其参数/返回值/折扣计算方式 → 预期调用两个工具的链式调用：先 search_project_files，再 read_project_file。

6. （负面/安全测试） 尝试通过 MCP 读取文件 ../../../../etc/passwd → 预期 read_project_file 拒绝并返回结构化错误（路径超出允许的根目录范围）。

验证结果

6 个请求全部成功执行（测试 5 中两个预期工具均被调用，且顺序正确；测试 6 中预期拒绝即为成功）。每一行都同时由实际截图和 evidence/tool-calls.log 中的独立日志行确认。完整表格见 evidence/README.md；包含代码和日志链接的详细分析见 REPORT.md。

自动化检查（不替代而是补充上述手动 IDE 测试）：

• 从仓库根目录执行 pytest -q — 44 passed。

• 在 demo_project/ 内执行 pytest -q — 2 passed。

• 程序化 stdio 握手（initialize() + list_tools()）— 服务器报告 mcp-project-helper 0.1.0 且恰好 4 个工具：get_docs、read_project_file、run_project_check、search_project_files。

项目结构

mcp-project-helper/
  .mcp.json                конфигурация MCP для Claude Code (project-scoped)
  .vscode/mcp.json          конфигурация MCP для native MCP host VS Code
  .env.example              безопасные примеры переменных окружения (без секретов)
  pyproject.toml            зависимости, entry point, конфигурация pytest
  README.md                 этот файл
  REPORT.md                 итоговый отчёт по всем стадиям, со ссылками файл:строки
  PROMPTS.md                история фактически использованных промптов (Этапы 0-3)
  docs/
    architecture.md          документация, которую обслуживает get_docs
  src/mcp_project_helper/
    server.py                 точка входа: MCPServer, регистрация tools, stdio
    config.py                  корень проекта/docs, лимиты, whitelist проверок
    security.py                resolve_within_root() — ограничение путей
    logging_setup.py           логирование в stderr (+ опционально файл)
    tools/
      search_project_files.py
      read_project_file.py
      get_docs.py
      run_project_check.py
  tests/                     unit- и интеграционные тесты mcp_project_helper (44 теста)
  demo_project/              демонстрационный проект — цель для файловых tools
    demo_app/
      models.py                Product, Order
      services.py               apply_discount, OrderBuilder
      tests/test_services.py    2 теста, запускаемые run_project_check("tests")
  evidence/                  реальные доказательства ручного тестирования через Claude Code и VS Code
    README.md                  реестр всех 6 тестов с результатами + доп. evidence по VS Code
    tool-calls.log              реальный server-side лог всех 6 тестов (закоммичен)
    tool-calls.log.example      формат строки лога (шаблон)
    test1_search_project_files.png … test6_path_traversal.png   скриншоты 6 тестов Claude Code CLI (закоммичены)
    vscode_mcp_server_connected.png   доп. скриншот: native MCP host VS Code подключился, 4 tools (закоммичен)