Loading ToolBench
Field-level semantic impact analysis for Claude Code — see the ripple effect of any code change
This MCP server demonstrates solid engineering with well-structured tools for code impact analysis. All 5 tools are explicitly registered with complete input schemas, clear verb-based naming, and comprehensive descriptions (all >200 chars). However, output schemas are not formally documented in the code provided, which prevents a higher score. Tool annotations (readOnlyHint) are correctly applied. Parameter descriptions are thorough and include context about regex patterns, array items, and practical examples. The main gaps are: (1) no explicit output schema documentation visible in the source, (2) error handling guidance is minimal (no recovery steps documented for failure cases), and (3) no mention of how the server handles malformed input or timeouts.
对 Python 代码做 AST 级别精确分析，比 grep 更准确。支持多种搜索目标，可同时指定多类： - symbols: 任何标识符（变量名、类名、常量名） - field_names: 字段/属性名（捕获 obj.field / obj['field'] / obj.get('field')） - string_values: 字符串字面量值（捕获代码中的字符串常量） - call_names: 函数/方法调用名 - import_names: 导入的模块或符号名 每个命中都标注所在函数名、访问方式和置信度，适合需要精确上下文的场景。返回按文件聚合的 JSON：{total_found, returned, truncated, files:[{file:相对路径, hits:[{line, kind, value, extra, function, confidence}]}]}。
将扫描结果聚合成结构化 Markdown 影响分析报告。若不传 scan_results/ast_results，自动使用该 project_path 的最近一次扫描缓存。推荐工作流：先调用 scan_patterns 和/或 analyze_python_ast，再调用此工具生成报告。
获取代码上下文，帮助判断命中处是否真正受变更影响。支持两种模式：单点（file_path + line_number）或批量（locations 数组，推荐——验证多个命中时一次调用替代多次往返）。
在代码库中搜索任意正则表达式 pattern，支持 Python/TypeScript/JavaScript/任意文本文件。这是最通用的搜索工具，适用于所有变更场景：字段访问、函数调用、字符串值、常量、配置项、API 路径、SQL 字段名、注释、枚举值等任何内容。当用户描述任何类型的代码变更并想知道影响范围时，调用此工具。由 Claude 根据变更描述决定要搜什么 pattern，此工具只负责机械执行搜索。返回按文件聚合的 JSON：{engine, total_found, returned, truncated, files:[{file:相对路径, hits:[{line, code, patterns, confidence}]}]}。
BFS 逐层找出调用指定函数的函数：depth=1 为直接调用者，depth=2 再找「调用者的调用者」，依此类推（上限 5 层）。适合回答「改了函数 X，影响会波及到哪里？」返回 {target, max_depth, total_found, truncated, levels:[{depth, callers:[{file, line, caller_function, callee, confidence}]}]}。confidence=high 表示 foo(x) 直呼；medium 表示 obj.foo() 按方法名匹配，可能是其他类的同名方法。
Output schemas not formally documented. Tool descriptions explain what is returned (e.g., '{engine, total_found, returned, truncated, files:[...]}' for scan_patterns), but no explicit JSON Schema output definition is visible in the code. LLMs cannot reliably plan downstream calls without seeing the exact output structure and field types.
Error handling and recovery guidance missing. The server accepts file paths, regex patterns, and directory exclusions but provides no documented guidance on what happens if paths are invalid, regexes fail to compile, or the project has no Python files. Error responses should tell the LLM what to do next (e.g., 'Invalid regex: ... Try escaping backslashes' or 'Project path not found. Verify the absolute path and try again.').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 76 | 2026-07-28+ | v2 |
get_code_context accepts both single-point (file_path + line_number) and batch (locations array) modes but does not document mutual exclusivity. Description states 'properties' but does not explicitly forbid passing both modes simultaneously. Per the rubric, undocumented dependencies cause silent misuse.
generate_impact_report has optional 'scan_results' and 'ast_results' params that 'auto-use cache if not passed'. This creates ambiguity: LLMs may not realize that calling the tool without results re-runs cached scans rather than using fresh data. The cache behavior should be explicit in the parameter description or split into separate 'use_cache' flag and separate result params.
No documented limits on result processing time. The tools accept 'max_results' (default 500) and support multi-level traversal (trace_callers up to depth 5), but there is no mention of timeout behavior, performance warnings for large projects, or guidance on when to use 'exclude_dirs' to reduce scope. An LLM running scan_patterns on a large monorepo could hang.