About depmap
depmap is a local CLI and MCP server that turns supplied monorepo package dependencies into structured graph data and a Mermaid diagram. It identifies roots, leaves, external dependencies, and cycles, with deterministic output and input validation.
Key features
- 01Map internal package dependencies
- 02Report edges, roots, and leaves
- 03Identify cyclic packages and a cycle
- 04Count external dependencies
- 05Generate a Mermaid graph
- 06Validate input and sort results
Use cases
- 01Inspect dependency structure in a monorepo
- 02Find packages involved in dependency cycles
- 03Render a package graph in a Mermaid viewer
MCP support
Exposes the map_internal_dependencies tool to MCP clients. It accepts package names and dependencies, then returns structured graph data and Mermaid output.
Configuration
Local server config is the same for every client. Copy it into your client’s MCP config file.
Tools
1Saved tool list · updated 1w ago
| Parameter | Type | Required | Description |
|---|---|---|---|
| packages | array | Yes | Packages in the monorepo (at least one) |
Details
From the project READMEdepmap
A monorepo is easy to lose track of: which packages actually depend on which other packages in the set, what sits at the top with nothing depending on it, what sits at the bottom depending on nothing internal, and whether the internal graph loops back on itself. depmap takes the package graph — every package's name and the names it depends on — and draws the whole map:
- Per-package entries — for every package, its internal
dependencies (
depends_on), the packages that depend on it (depended_by), andexternal_count: how many of its dependency names point outside the set. External names are counted, never mapped, and never an error — a package may freely depend on libraries the monorepo does not contain. - Edges, roots, and leaves — every internal dependency
as a
{from, to}edge, the roots (packages nothing internal depends on), and the leaves (packages with no internal dependencies). - Cycles, two ways —
cyclic_packageslists every package that lies on any cycle: members of a strongly connected component of more than one package, plus any package that depends on itself. Alongside it,cyclereports one concrete cycle, found by a depth-first search that visits names and dependencies in ascending order. A cycle is a finding, not an error. - A Mermaid graph — the map rendered as a
graph TDdiagram you can paste into any Mermaid renderer. Package names that are not valid Mermaid ids get a sanitised id (@scope/appbecomes_scope_app) with a declaration line tying the id back to the real name.
Duplicate entries in one package's dependencies are
de-duplicated before mapping, and every list in the result
is sorted ascending, so the same graph always yields
exactly the same map. Malformed input — a missing or empty
package list, a missing or duplicate package name, a
wrongly typed field — is a validation error naming the
offending path (for example
packages[1].dependencies[0] must be a string), and no
partial map is produced. The computation is pure and
local: no network, no configuration, no files read beyond
the input you pass in.
CLI
npx @reneturcios/depmap map --input args.json
npx @reneturcios/depmap --version
args.json contains the full arguments object:
{
"packages": [
{ "name": "core" },
{ "name": "lib", "dependencies": ["core"] },
{ "name": "app", "dependencies": ["lib", "react"] }
]
}
dependencies defaults to [] per package; here react
is external to the set, so it appears only in app's
external_count. The map is printed as JSON:
{
"packages": [
{ "name": "app", "depends_on": ["lib"], "depended_by": [], "external_count": 1 },
{ "name": "core", "depends_on": [], "depended_by": ["lib"], "external_count": 0 },
{ "name": "lib", "depends_on": ["core"], "depended_by": ["app"], "external_count": 0 }
],
"edges": [
{ "from": "app", "to": "lib" },
{ "from": "lib", "to": "core" }
],
"roots": ["app"],
"leaves": ["core"],
"has_cycle": false,
"cycle": [],
"cyclic_packages": [],
"mermaid": "graph TD\n app --> lib\n lib --> core"
}
Exit codes: 0 on success, 1 on a runtime error (including
an unreadable or invalid input file, or invalid input), 2
on a usage error.
MCP server
npx -y @reneturcios/depmap mcp
MCP client config:
{
"mcpServers": {
"depmap": {
"command": "npx",
"args": ["-y", "@reneturcios/depmap", "mcp"]
}
}
}
Tools
-
map_internal_dependencies— Map a monorepo's internal dependencies.packages(array, required, at least one) — packages as{name, dependencies?}objects;nameis unique across the set, and eachdependenciesentry either names another supplied package (internal) or anything else (external, counted only)
Returns
{packages, edges, roots, leaves, has_cycle, cycle, cyclic_packages, mermaid}.
Docker
docker run -i ghcr.io/cloudcorprecords/depmap
docker run --rm -v "$PWD:/w" ghcr.io/cloudcorprecords/depmap map --input /w/args.json
Development
npm install
npm run build # tsc -> dist/
npm test # tsx --test test/*.test.ts (pure local, no network)
npm run dev # run the CLI from source
License
MIT — Copyright (c) 2026 Rene Turcios
Comments
New to MCP?
From what the protocol is to installing your first server, these answers cover most first questions.
An open protocol that defines how AI applications connect to external tools and data in a uniform way. Clients talk to the model; MCP servers provide tools, resources and prompt templates. They exchange standard messages, so one server can be reused by many clients.