Callgraph MCP

调用图mcp

CallGraph MCP服务器 --将任何代码库的确定性调用图分析作为MCP工具公开。给你的AI代理一个精确的代码结构图——没有幻觉，没有猜测。

完全本地化。没有云。没有法学硕士。没有遥测。

由...驱动 @codeflow-map/core 以及Tree sitter WASM解析器。

支持： TypeScript·JavaScript·TSX·JSX·Python·Go

*设计用于零假阴性（在静态限制内）。它从不错过任何它能看到的东西（高召回率），即使这意味着过度报道。*

捆绑语法： 包括TypeScript、JavaScript、TSX、JSX、Python和Go语法。安装后，它们可以在 callgraph-mcp/grammars.

______________________________________________________________________

为什么确定性分析很重要

大多数AI编码工具通过将源文件读取为文本并对其进行推理来回答有关代码库的结构性问题。这会导致三种复合故障模式：

• 幻觉。 当被问及“什么电话 processPayment“”，没有结构基础的模型将根据命名模式和训练先验进行猜测。它将自信地命名不存在的调用者，并忽略存在的调用者。
• 在中间丢了。 研究表明，LLM系统地无法从长上下文中回忆信息。将200个文件的代码库粘贴到上下文中，模型将根据顶部或底部附近发生的任何事情来回答。
• 注意力稀释。 即使存在信息，将模型的注意力分散到数万行中也意味着每个单独的事实的权重较小。调用图中的一个关键边与其他所有边争夺注意力。

callgraph mcp消除了这三个。 它从不把你的代码当作散文来阅读。它使用Tree sitter将每个文件解析为AST，构建一个精确的有向调用图，并根据该图回答结构化查询。每个调用者、每个被调用者、每个可访问的函数、每个循环都作为精确的索引返回。无论你的代码库有多大，哪些文件恰好在上下文中，或者函数埋得有多深，答案总是一样的。 不存在任何可能性。没有注意稀释。

*该图显示了callgraph如何解释python fastAPI代码库中的POST方法流。无论代码库有多大或多小，它都不会错过任何优势。*

______________________________________________________________________

设置

选项1--VS代码通过 npx

添加到您的项目 .vscode/mcp.json:

{
  "servers": {
    "flowmap": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "callgraph-mcp"],
      "env": {
        "FLOWMAP_TRANSPORT": "stdio"
      }
    }
  }
}

选项2

{
  "servers": {
    "flowmap": {
      "type": "stdio",
      "command": "callgraph-mcp",
      "args": [],
      "env": {
        "FLOWMAP_TRANSPORT": "stdio"
      }
    }
  }
}

在编辑器中启动服务器。WASM语法是捆绑在一起的——不需要环境变量。

提示： 创建 .vscode/mcp.json 通过命令面板-> MCP：添加服务器 -> 标准.

选项3-HTTP-SSE（共享或远程服务器）

使用 FLOWMAP_TRANSPORT=http 适用于HTTP-SSE兼容客户端。

启动服务器：

FLOWMAP_TRANSPORT=http FLOWMAP_PORT=3100 npx callgraph-mcp
# Windows PowerShell:
# $env:FLOWMAP_TRANSPORT="http"; $env:FLOWMAP_PORT="3100"; npx callgraph-mcp

然后将你的客户指向它：

{
  "servers": {
    "flowmap": {
      "type": "http",
      "url": "http://localhost:3100/mcp"
    }
  }
}

工具参考

可选参数如所示 [brackets].

workspacePath --到repo根的绝对路径（例如。 /home/user/my-project 或 C:\projects\my-app).

代币保存用例

______________________________________________________________________

环境变量参考

______________________________________________________________________

示例用例

PR审查和变更安全

*我刚刚进行了修改 processPayment。在不阅读任何代码的情况下，告诉我每个可能破坏它们的函数，并根据它们距离更改的跳数对它们进行排名。"*

代理人打电话来 flowmap_get_callers("processPayment", workspacePath) 对于直接影响半径（1跳），然后递归遍历调用者的调用者，以构建按距离排序的列表。

______________________________________________________________________

*“我们即将合并一个涉及 validateCart给我一份影响报告——如果这个函数抛出，最坏的情况是什么。"*

代理人打电话来 flowmap_get_flow("validateCart", workspacePath) 映射下游可访问的每个功能，然后 flowmap_get_callers("validateCart", workspacePath) 映射每个上游呼叫者。

______________________________________________________________________

架构问题

*“这个代码库中的哪些函数是架构上令人讨厌的惊喜——除了自己调用很多之外，其他所有函数都会调用。我想要名称、文件路径和确切的计数。”*

代理人打电话来 flowmap_analyze_workspace(workspacePath) 为了获得完整的图，然后过滤入度高（许多调用者）和出度高（很多被调用者）的节点。这些是结构性阻塞点——bug在两个方向上传播的功能。带着精确的计数返回。没有近似值。

______________________________________________________________________

*“在调用图中找到每个循环。对于每个循环，告诉我应该在哪个文件中打破依赖关系，以便干净地解决它。”*

代理人打电话来 flowmap_find_cycles(workspacePath)每个循环都以函数的有序列表形式返回，其中包含形成循环的文件路径和确切的调用边，不需要进行后处理。因为图是精确的，所以循环成员是精确的——而不是猜测哪些模块“看起来”是圆形的。

______________________________________________________________________

死代码和清理

*“我想安全地删除代码。给我每个可证明无法访问的函数——不被任何东西调用，也不是入口点。包括文件和行号。”*

代理人打电话来 flowmap_find_orphans(workspacePath)。这将返回从调用图中的任何入口点都无法访问的每个函数——每个函数都有文件路径和行号。

______________________________________________________________________

入职

*“我刚加入这个团队。从入口点开始，引导我浏览这个代码库——用简单的英语解释每个主要流程，而无需我阅读任何文件。”*

代理人打电话来 flowmap_list_entry_points(workspacePath) 查找每个main、路由处理程序、CLI命令和React根。然后它叫 flowmap_get_flow 在每个人身上追踪执行情况。

______________________________________________________________________

重构

*“我想将支付逻辑提取到自己的模块中。纯粹基于调用关系，哪些函数自然属于一起，哪些函数需要留下来。”*

代理人打电话来 flowmap_analyze_workspace(workspacePath) 并使用该图来找到从支付相关入口点可访问的函数的连接组件。

______________________________________________________________________

AI代理审查

*“Cursor刚刚在14个文件中进行了更改。根据它所触及的内容，代码库中还有什么我应该担心它没有触及的地方。”*

代理人打电话来 flowmap_get_callers 对于每个修改后的功能和 flowmap_get_flow 对于每个修改后的功能。这些结果的联合——减去已经接触的文件——是一组依赖于更改但未更新的函数。这些是最有可能发生无声破坏的地方。返回的是一个精确的列表，而不是对“可能相关”的猜测。

______________________________________________________________________

具有结构护栏的代理代码生成

当代理生成新代码时，它可以调用 flowmap_analyze_workspace 在验证之前和之后：

• 新函数连接到调用图（不是意外孤立的）
• 没有破坏现有的入口点
• 预期的呼叫关系实际上已经创建

______________________________________________________________________

捕捉剂在合成之前引入了复制

*“我们已经使用人工智能代理构建这个代码库3个月了。它默默地复制了多少逻辑？”*

代理针对当前指令进行优化，而不是针对长期架构。它复制，稍作调整，然后继续前进。它满足了当地的目标。

代理人打电话来 flowmap_find_duplicates(workspacePath)结果中的每个集群都是一组具有不同名称的函数——通常在不同的组件中——它们调用同一组依赖关系。

______________________________________________________________________

检测由代理生成的代码引入的循环依赖关系

*“代理已添加功能数周。在这成为生产问题之前，我是否应该知道任何循环调用依赖关系？”*

代理人打电话来 flowmap_find_cycles(workspacePath)每个循环都会返回所涉及的确切函数。

______________________________________________________________________

*重复标记可能是单个可重复使用函数的不同函数*

运作原理

1. 树型WASM语法将每个源文件解析为AST——无需运行时执行，无需导入
2. 从AST中提取函数和调用点
3. 通过将调用站点名称解析为函数定义（按名称、后缀和文件）来构建调用图
4. 检测入口点：从不调用但调用其他函数的函数
5. 该图通过BFS从每个入口点划分为独立的执行流

文件以50个并行批的形式解析。结果被缓存30秒——会话中的重复调用是即时的。

______________________________________________________________________

链接

• VS代码扩展
• 核心包（@codeflow map/Core）
• 源代码
• 报告问题

许可证

麻省理工学院