
Wraps JetBrains dotMemory CLI with a heuristic rule engine to surface concrete memory issues in .NET applications. You get tools to capture snapshots, compare before/after memory states, and run 10 built-in rules that flag event handler leaks, undisposed IDisposables, LOH fragmentation, and closure retention issues. Automatically downloads the dotMemory CLI on first use for Windows, Linux, and macOS, or falls back to DOTMEMORY_PATH if you're on an unsupported platform. Findings come back with severity levels and AI-actionable suggestions. Reach for this when you suspect a leak or memory bloat in a running .NET process and want Claude to interpret profiler output without manually digging through dotMemory workspaces.
On-demand .NET memory profiling with concrete, AI-actionable code fix suggestions — no profiler to install.
A hosted deployment is available on Fronteir AI.
{
"mcpServers": {
"memorylens": {
"type": "stdio",
"command": "npx",
"args": ["-y", "memorylens-mcp"]
}
}
}
The npm package ships no server code — it is a launcher that installs the MemoryLens.Mcp .NET
global tool at a matching version and execs it, so the .NET 10 SDK must be on PATH.
Subsequent starts skip the install entirely and work offline.
Add to your MCP settings (.vscode/mcp.json or VS settings):
{
"servers": {
"memorylens": {
"type": "stdio",
"command": "dnx",
"args": ["MemoryLens.Mcp", "--yes"]
}
}
}
claude install gh:MarcelRoozekrans/memorylens-mcp
dotnet tool install -g MemoryLens.Mcp
docker build -t memorylens-mcp .
docker run -i --rm --pid=host --cap-add=SYS_PTRACE \
-v /tmp:/tmp \
-v "$PWD:/workspace" memorylens-mcp
Profiling from a container needs ptrace and the host PID namespace, and on
Docker Desktop that namespace is the Linux VM rather than your desktop — see
docs/docker.md before choosing this route.
-v /tmp:/tmp is what makes list_processes return anything — the runtime's
diagnostic sockets live in the temp directory — and it is also what keeps
snapshots alive after --rm, since they are written to
/tmp/memorylens-snapshots inside the container. -v "$PWD:/workspace" is only
so .memorylens.json is picked up; nothing is written there.
global.json)Running a filtered subset of the tests, e.g. dotnet test --filter <name>, will exit with code 9
and print error: 1, failed: 0. That's the test project's discovery-collapse guard
(--minimum-expected-tests) firing because the filter left fewer tests than expected — it is
not a test failure, and a full dotnet test run is unaffected.
MemoryLens collects heap data in-process over EventPipe, the .NET runtime's built-in diagnostics channel. There is no profiler to install, no download on first use, and no external tool on PATH.
snapshot attaches to a running .NET process by pid, induces a collection, and aggregates the heap into per-type counts and sizes. Snapshots are written as small JSON files under your temp directory and referenced by a short id.
On Linux and in containers, attaching to another process's diagnostic endpoint may require matching UID or SYS_PTRACE — see docs/docker.md.
| Tool | Description |
|---|---|
list_processes | Lists running .NET processes available for profiling, discovered from their diagnostic IPC endpoints |
snapshot | Captures a single memory snapshot of a target process |
compare_snapshots | Captures two snapshots with configurable delay and compares them |
analyze | Runs the rule engine against a captured snapshot and returns findings |
get_rules | Lists all available analysis rules with their metadata |
| ID | Severity | Category | Description |
|---|---|---|---|
| ML001 | critical | leak | Event handler leak detected |
| ML002 | critical | leak | Static collection growing unbounded |
| ML003 | high | leak | Disposable object not disposed |
| ML004 | high | fragmentation | Large Object Heap fragmentation |
| ML005 | medium | retention | Object retained longer than expected |
| ML006 | medium | allocation | Excessive allocations in hot path |
| ML007 | medium | retention | Closure retaining unexpected references |
| ML008 | low | allocation | Array/list resizing without capacity hint |
| ML009 | low | pattern | Finalizer without Dispose pattern |
| ML010 | low | pattern | String interning opportunity |
Create a .memorylens.json file in your project root to customize rule behavior:
{
"rules": {
"ML001": { "enabled": true, "severity": "critical" },
"ML002": { "enabled": true, "severity": "critical" },
"ML003": { "enabled": true, "severity": "high" },
"ML004": { "enabled": true, "severity": "high" },
"ML005": { "enabled": true, "severity": "medium" },
"ML006": { "enabled": true, "severity": "medium" },
"ML007": { "enabled": true, "severity": "medium" },
"ML008": { "enabled": true, "severity": "low" },
"ML009": { "enabled": true, "severity": "low" },
"ML010": { "enabled": true, "severity": "low" }
}
}
Capture a memory snapshot of a running process to inspect current memory state:
> /memorylens
> Take a snapshot of my running API (PID 12345)
Claude will call snapshot with the target PID, then analyze the returned snapshot id and present findings ordered by severity.
Detect memory growth by comparing two snapshots taken with a delay:
> /memorylens
> Check if my app has a memory leak — compare before and after processing 1000 requests
Claude will call compare_snapshots with a delaySeconds value (default 10 seconds) between the two captures, then analyze the diff to identify objects that grew between snapshots.