Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
作者提供的说明(英文原文)
Call graph for coding agents: callers up to HTTP routes, callees, usages for TS/JS, Go, Python, Java
这三项永远不会合并成一个分数:意见、测量和人气是不同的东西。
我们还没有为它写通俗的介绍。下面是我们从注册中心读取到的事实。
选择你使用的 AI 应用,然后复制设置。
你需要
你用的是哪个应用?
在上方选择你的应用。我们会记住它,下次按钮会显示“安装到 …”。
打开 Claude Desktop → Settings → Developer → Edit Config,把下面的内容粘贴到 claude_desktop_config.json
{
"mcpServers": {
"layermap": {
"command": "npx",
"args": [
"-y",
"layermap",
"mcp"
]
}
}
}在终端中运行这条命令
claude mcp add layermap -- npx -y layermap mcp粘贴到项目中的 .cursor/mcp.json,或 ~/.cursor/mcp.json
{
"mcpServers": {
"layermap": {
"command": "npx",
"args": [
"-y",
"layermap",
"mcp"
]
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
粘贴到项目中的 .vscode/mcp.json
{
"servers": {
"layermap": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"layermap",
"mcp"
]
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
这个服务器在你的电脑上运行,而 ChatGPT 只能连接互联网上的服务器。请选择其他应用。
你的选择通过 Cookie 保存在这台设备上,无需账户。
这些设置是根据作者在注册中心的条目生成的。如果 README 的写法不同,请以 README 为准。
它在你的电脑上运行;安装后,工具列表会显示在你的 AI 应用中。
我们检查的是任何人都能看到的信息;我们没有阅读代码。不适用的检查项不计入总数。 · 检查于 2026年11月6日
注册名称已通过 GitHub 账户 coffeecoproject 验证,该账户拥有此仓库
我们还没有从 GitHub 读取这个仓库
我们还没有从 GitHub 读取这个仓库
它在你的电脑上运行,没有互联网端点
在你的电脑上运行,改用本地设置
它在你的电脑上运行;我们只能读取互联网端点的工具列表
与注册中心里这个分类中所有活跃的服务器比较。只有当发布者拥有该仓库时,星标数才计入。
它在 1 项适用的基础检查中通过了 1 项。我们没有阅读代码。在添加密钥或令牌之前,请先看看这个服务器要求哪些权限,并使用只具备所需权限的密钥。
注册中心没有列出必需的密钥,不过有些服务器会在首次使用时要求你登录。
它在你的电脑上运行。你的 AI 应用会在需要时启动它,数据不会经过作者的服务器(除非它自己调用在线服务)。
GitHub 仓库最后更新于–,最新版本(0.1.35)于昨天进入注册中心。
支持 MCP 的应用,例如 Claude Desktop、Claude Code、Cursor 和 VS Code。你的电脑上还需要有 Node.js。
同一分类中有:Spec Driven Development, Remote Desktop Commander, Safe Fetch
同一分类中其他作者的服务器,按星标数排序。
如何看卡片:★ GitHub 星标i三大支柱:评价 · 检查 · 使用情况i更新 = 最新版本发布到注册中心的时间i
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
MCP server for fetching URLs, safe against SSRF, DNS rebinding, and redirect-to-internal attacks.
按原文从作者的仓库复制。PopNx MCP 没有审查或背书其内容。HTML、图片和脚本已被移除。链接会离开本站。
English · 中文
LayerMap tells your coding agent what calls a function and what changing it affects, up to the HTTP routes, in one call. With at most 15 requests, Claude Code on Opus 5.5 found 99.9% of affected endpoints with LayerMap vs 76.0% without; with no limit, it found about the same and cost 48% less, or 27% less without the task that gained most (benchmark).
Resolved by each language's compiler or type checker, not guessed from names by tree-sitter: calls through interfaces, base classes, templates and decorators link as the compiler links them, for TypeScript, JavaScript, Go, Python and Java.
A real Claude Code session on Miniflux , replayed: one map call finds every endpoint, then the agent confirms them in source.
A layered map of your codebase for coding agents. LayerMap gives Claude Code, Codex, CodeBuddy Code, Pi, DeepSeek Harness and other MCP clients read-only tools that answer, in one call, what an agent otherwise works out with dozens of searches:
It maps TypeScript, JavaScript, Go, Python and Java with each language's own compiler, so calls through interfaces, base classes, templates and decorators resolve as the compiler resolves them, including the ones text search misses. In WeChat mini-programs, it also links each page's and component's template (.wxml) to the methods it binds and the components it shows, and each event a component emits to the handlers the pages bind to it, so callers reach the pages.
In Miniflux, one call on Storage.MarkFeedAsRead finds all four ways a request reaches it, each with its route:
DECLARATION internal/storage/entry.go: Storage.MarkFeedAsRead m656-680 exported
← called by internal/api/feed.go: handler.markFeedAsRead m140-155 @149 ← called by internal/fever/handler.go: handler.handleWriteFeeds m492-519 @508 ← called by internal/googlereader/handler.go: handler.markAllAsReadHandler m1261-1338 @1311 ← called by internal/ui/feed_mark_as_read.go: handler.markFeedAsRead m14-30 @24 [1] internal/api/feed.go: handler.markFeedAsRead m140-155 ← used as value by internal/api/api.go: Serve f25-84 @61 "PUT /v1/feeds/{feedID}/mark-all-as-read" [1] internal/googlereader/handler.go: handler.markAllAsReadHandler m1261-1338 ← used as value by internal/googlereader/handler.go: Serve f44-64 @62 "POST /reader/api/0/mark-all-as-read" [1] internal/ui/feed_mark_as_read.go: handler.markFeedAsRead m14-30 ← used as value by internal/ui/ui.go: Serve f18-180 @77 "POST /feed/{feedID}/mark-all-as-read" … (the Fever API, then on down to main.go: main)
m and f mark methods and functions with their lines; @ is the line of the call, and the quoted route is what it is registered under: the HTTP method and the full path, with the /v1 prefix its subrouter adds. In Java, Python and TypeScript the route shows on the handler itself, as in @GetMapping("/{id}") route "GET /api/tasks/{id}".
Impact questions ("which HTTP endpoints does changing this affect?") on public Go, Python and Java projects, graded blind against truth sets cross-checked with each language's own toolchain:
| With LayerMap | Without | |
|---|---|---|
| Endpoints found, at most 15 requests (Claude Code on Opus 5.5, 6 tasks × 3 runs) | 99.9% | 76.0% |
| Cost / time at that limit (Opus 5.5) | +12% / +4% | |
| Endpoints found, no request limit (Opus 5.5, 6 tasks × 2 runs) | 100% | 99.7% |
| Cost / time, no request limit (Opus 5.5, maps built ahead) | −48% / −33%; −27% / −21% without the task that gained most | |
| Ripple tasks: runs leaving other features' tests passing (Opus 5.5, 4 tasks × 3 runs) | 12 of 12 | 12 of 12 |
Endpoints found, at most 15 requests (gpt-5.5, 6 tasks × 3 runs) | 97.9% | 58.8% |
| Used unprompted by Claude Code / Codex (plugin installed, two rounds) | 12 of 12 / 12 of 12 | — |
| Endpoints found, no request limit (Claude Code / Codex, 0.1.5) | 100% / 100% | 99.0% / 100% |
| Claude Code cost, no request limit (0.1.5 re-run; first round −32%) | −33% | |
| Codex input tokens, no request limit (current defaults) | +14% | |
Time, no request limit (Claude Code on claude-opus-5 / Codex, 0.1.5) | +25% / +20% | |
| Failing tests the change check lists (Go / Python, functions made to fail) | 100% / 94–98% | — |
| Ripple tasks: runs leaving other features' tests passing (Codex / Claude Code, 4 tasks × 6 runs with, × 3 without) | 23 of 24 / 11 of 24 | 3 of 12 / 4 of 12 |
| Everyday tasks, no impact analysis needed: done right / time (Claude Code and Codex, 8 tasks × 2 runs) | 32 of 32 / +12–31% | 32 of 32 |
With a tight budget, the map finds far more of the affected code, at 12–24% more cost or tokens. With no limit, both agents find nearly everything either way. Claude Code costs a third to a half less with the map. On Opus 5.5 it was also a third faster, though one task accounts for much of that gap and the maps were built ahead; on claude-opus-5 it was a quarter slower. Codex's current defaults already search lean, so the map no longer saves it tokens; at reasoning effort max, in the first round, it saved 55%. Codex with the map explores more widely, which takes longer. On requests whose obvious change breaks another feature, the change check helped Codex keep to the requested feature. Claude Code saw which tests of other features it had changed but often kept the broader change on purpose, so it showed no clear difference; on Opus 5.5 it broke nothing with or without the map, and the check cost 17% more. On small local tasks the map changed nothing but cost about a fifth more time and money. These are small samples on tasks written by LayerMap's authors. The report has the setup, the published tasks and the limitations.
Other tools give agents part of this. LayerMap combines compiler accuracy with whole-chain traces in one local map:
| Tree-sitter code graphs (codegraph, GitNexus, …) | Language servers and IDEs (Claude Code's LSP tool, Serena, JetBrains) | Embedding search (Claude Context, Augment) | LayerMap | |
|---|---|---|---|---|
| How calls are linked | Matched by names, imports and framework rules, often with confidence scores | The compiler's own resolution | Not linked; similar code is retrieved | Resolved by each language's compiler or type checker |
| Callers traced to routes and handlers | In several tools, at varying depth | One level per request (JetBrains: 5 by default) | — | Up to 8 levels in one call |
| Kept as a map | Yes, with file watching | No, answered live by a running server | An index of code chunks | Yes, brought up to date on every call |
| Runs on your machine | Yes; some send anonymous telemetry | Yes | Usually with cloud embeddings | Yes, and sends nothing |
Another tool fits better if you need:
Claude Code
/plugin marketplace add coffeecoproject/layermap
/plugin install layermap@layermap
Codex
codex plugin marketplace add coffeecoproject/layermap
codex plugin add layermap@layermap
CodeBuddy Code
codebuddy plugin marketplace add coffeecoproject/layermap
codebuddy plugin install layermap@layermap
Pi
pi install npm:layermap
DeepSeek Harness
npx layermap setup dsh
This adds LayerMap to every dsh profile. Each session maps the project dsh was started in, and npx layermap remove dsh undoes it.
In every agent, start a new session in a Git repository and ask as usual. LayerMap tells the agent when the map helps. A session started in a folder holding several repositories, or one that moves to another repository, works too: each map tool call maps the repository its path names. The first time a session starts a version of LayerMap, npm installs that pinned layermap package into LayerMap's cache; later sessions start it from there, even offline.
Claude Code asks once before each map tool runs in a project. Choose "don't ask again", or run npx layermap allow claude to allow the plugin's read-only tools everywhere.
After an edit. When the agent changes code, project_check_changes lists what the change affects: the routes, jobs and commands that reach the changed functions, what the map cannot see, and the existing tests related to the change. When the changed code serves several areas (packages or modules), it names each one with its tests, and it names the existing tests the diff rewrote, so a change meant for one feature does not quietly change the others. Environment variables and configuration keys are linked by name only, which no compiler sees, so when the diff removes one from a file, the check names the files that still read or set the old name. In the same way, when the change reaches a route's handler or renames a route, it names the code and templates that request that path: a frontend's fetch, a generated API client, a redirect or a link. When the change adds an import between two modules of the project overview, it names it, and says when the two now depend on each other; whether that direction suits the project's layers is for the agent to judge. When a declaration the change adds reads almost the same as code the project already has, it names both, so the agent can use the existing code instead of a copy. When the change takes away the last call to a declaration, as when new code replaces old, it names that declaration, so the agent can delete what the change left behind. The map does not link a field or type to the code reading it, so for one the change touches, the check searches for its references and follows that code up to the entry points and tests, as possibly affected. It never writes or runs tests. In Claude Code and CodeBuddy Code the plugin asks the agent once, before it finishes, to run this check for each repository it edited code in and has not checked since, whether through its edit tools or shell commands, which count for the code files they name (changes another session makes in the same work tree do not count); the Pi extension does the same after the agent's own edits. Set LAYERMAP_STOP_CHECK=0 to turn that off. Codex and Deep
只显示了开头部分;其余内容请在仓库中阅读