seamcheck
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@seamcheckscan this project for dead seams"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
seamcheck
Find dead seams: code your tests exercise that nothing in production calls.
A dead seam is distinct from dead code. Dead code is reached by nothing and looks abandoned. A dead seam is reached by your test suite and by nothing else, so it looks finished: written, reviewed, green. A repository can hold a fully passing suite while its main loop cannot reach the organs the suite is guarding. Coverage will not tell you, because coverage asks whether tests reach code, never whether the application does. Review will not tell you, because the missing call site is an absence, and absences do not appear in diffs.
seamcheck asks the missing question directly. It finds your production entry points, walks the import graph, and reports every file that only your tests can reach.
Use
npx seamcheck .Exit codes: 0 clean, 1 seams found, 2 scan error. Add --json for machine-readable output; the MCP server returns the same JSON.
The report has three verdicts. Alive: reachable from a production entry point. Dead seam: reachable only from test files. Dead code: reachable from nothing.
Related MCP server: agentguard
What a run looks like
Real output against the fixture repo this package tests itself with:
seamcheck v0.1.0
root: C:\Users\operator\projects\fixture
entry points (1): src/main.ts
DEAD SEAMS (1) — tests reach these; production cannot:
src/seam.ts
DEAD CODE (1) — nothing reaches these at all:
src/orphan.ts
summary: 3 alive, 1 seams, 1 dead, across 5 production files (1 test files).
Why suites lie about done: https://emberthread.dev/seamsRun against itself, seamcheck reports zero seams and zero dead files, which is the least it owes you.
MCP
The package ships an MCP server exposing one tool, scan_dead_seams, so a coding agent can run the scan on its own work mid-session. Configuration:
{ "mcpServers": { "seamcheck": { "command": "npx", "args": ["-y", "-p", "seamcheck", "seamcheck-mcp"] } } }Seams found is a finding, not an error; the agent gets the same JSON as --json.
Entry points
seamcheck reads production roots from package.json (bin, main, module, exports), mapping built paths like dist/x.js back to their sources where it can. Add anything it cannot infer, such as route handlers registered by name or scheduled jobs, to .seamcheckrc.json:
{
"entryPoints": ["src/jobs/nightly.ts"],
"ignore": ["scripts/**"],
"testPatterns": ["**/*.test.*", "**/*.spec.*", "**/__tests__/**", "**/test/**", "**/tests/**"]
}Patterns support **, *, ?, and single-level {a,b} alternation. The entry point census is the one part of the scan that deserves your judgment. Everything after it is a mechanical walk.
Honesty
Version 0.1 classifies at file level over the static import graph, for TypeScript and JavaScript. Dynamic import() and require() calls with non-literal arguments are invisible to it; when they exist, the report says so and how many, rather than pretending the graph is complete. Files wired only through string-keyed registries can be misclassified: declare them as entry points or ignore them, and treat the note in the report as the tool admitting the limit of what it can see. Cross-package edges through installed or workspace dependencies are not traced yet either; in a monorepo, scan each package separately.
Prior art
knip's --production mode and unimported walk entry-point graphs too, and if they already work for you, keep them. seamcheck exists for one distinction they don't make: it separates dead seams (tests reach it, so it looks finished and actively misleads) from dead code (nothing reaches it, so it looks abandoned). That verdict is the point; the dangerous file is the one your suite is guarding. It also ships as an MCP tool so an agent can scan itself mid-session, which is the workflow it was built for.
Why this exists
This tool ships alongside a field manual on running persistent coding agents, written after a month of stalls in a project whose suite of 1,308 tests was green while 229 files sat unreachable from its main loop. The scan that ended that month took an afternoon to write. This is that afternoon, made general. The full anatomy of the defect class is a free chapter: https://emberthread.dev/seams — part of Running a Persistent Coding Agent, the field manual this tool ships with.
MIT © 2026 Emberthread
This server cannot be deployed
Maintenance
Related MCP Connectors
Codebase intelligence for AI agents — dead code, blast radius, ownership.
AI-powered codebase analysis — call graphs, security, dead code, complexity. 150+ tools.
Scan code for quantum-vulnerable cryptography and get NIST post-quantum migration guidance.
Scan configs, files, or text for leaked secrets and obvious misconfigurations. Nothing stored.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceProvides code analysis for Next.js projects through the Model Context Protocol, enabling IDE and LLM integration to identify unused files, dead code, and redundant API endpoints.48MIT
- AlicenseNot gradedqualityAmaintenanceEnables scanning of AI agent code for security vulnerabilities such as prompt injection, tool abuse, and data exfiltration, directly from MCP-compatible clients like Claude Code.2LGPL 3.0
- AlicenseNot gradedqualityAmaintenanceEnables AI agents to scan code for security and quality issues and receive machine-readable reports with suggested fixes and verification criteria.722MIT
- AlicenseNot gradedqualityAmaintenanceGive your coding agent the dependency graph it is about to change: scan, diff, explain, audit.12Apache 2.0