Fallow MCP Server: Setup for Claude Code, Cursor and Other Apps

• Finds unused files, exports, dependencies and circular imports

  Runs the full dead-code analysis on a TypeScript or JavaScript project. It reports unused files, exports, types and dependencies, unresolved imports, circular dependencies and architecture-rule violations. It can save a baseline file if you ask.

  Try: “Find all unused exports and files in this project.”

  Write · analyze

• Checks only the files you changed since a git ref

  Runs the same dead-code analysis but only on files changed since a branch or commit. Finding IDs match a full run, so an ID missing here is unknown, not fixed.

  Try: “What unused code did my changes since main introduce?”

  Write · check_changed

• Gives a pass, warn or fail verdict on your changed files

  Audits changed files for dead code, complexity, duplication and styling and returns a verdict. It can compare against a base ref and read coverage data for sharper complexity scores.

  Try: “Audit my branch against main and tell me if it passes.”

  Files · audit

• Finds copy-pasted code across the project

  Detects duplicated code and groups clones with a stable fingerprint. It can also find near-miss clones inside functions. Like analyze, it can write a baseline file when asked.

  Try: “Find duplicated code in src and list the biggest clone groups.”

  Write · find_dupes

• Scores complexity, hotspots and what to refactor first

  Reports per-function complexity, file health scores, hotspots that change often, and ranked refactoring targets. Options add git churn, ownership, test coverage gaps and trends against a saved snapshot.

  Try: “Which files are the biggest complexity hotspots, and what should I refactor first?”

  Write · check_health

• Checks import cycles and layer-boundary violations

  After you edit files, reports import cycles, boundary violations and rule-pack policy violations with the same finding IDs as analyze.

  Try: “Did my last change introduce any circular imports or boundary violations?”

  Files · check_architecture

• Shows the architecture rules for files before you edit them

  Before an edit, reports which boundary zone a file is in, which zones it may import from, and which calls or rule-pack policies are forbidden.

  Try: “What are the architecture rules for src/billing/invoice.ts before I change it?”

  Files · guard

• Lists possible security problems, not confirmed ones

  Returns unverified local security candidates with category, CWE, severity, evidence and a source-to-sink trace. The severity is a review priority, not a verdict.

  Try: “List security candidates in this project and rank which to review first.”

  Files · security_candidates

• Gathers everything known about one file or export

  For one file or exported symbol, returns dead-code actions, duplication groups, complexity findings and security candidates in one call. An option adds the symbol's call chain.

  Try: “Give me all the findings for src/utils/format.ts.”

  Files · inspect_target

• Explains why an export counts as used or unused

  Shows whether a file is reachable, its direct references, re-export chains and a reason string for one export. Use it before deleting an export that looks unused.

  Try: “Why does fallow think formatDate in src/utils/date.ts is unused?”

  Files · trace_export

• Shows every import edge for a file

  Lists a file's reachability, entry-point status, exports, what it imports, what imports it and its re-exports, so you can tell if it is isolated or live.

  Try: “Who imports src/legacy/old-api.ts, and is it still reachable?”

  Files · trace_file

• Shows where a package is imported

  Returns the files that import a package, the ones that only use its types, a count, and whether package scripts or CI configs call it.

  Try: “Where do we use lodash, and can we remove it?”

  Files · trace_dependency

• Opens one duplicate-code group in detail

  Shows one clone group chosen by file and line or by fingerprint, with every instance and a suggestion for extracting a function.

  Try: “Show me the duplicate group at src/api/users.ts line 40.”

  Files · trace_clone

• Finds the shortest import path between two files

  Returns whether one module can reach another through imports and the chain of hops between them. An unreachable pair is a valid answer.

  Try: “How does the checkout page end up importing the admin module?”

  Files · trace_import_path

• Traces exact TypeScript references with the type checker

  Follows exact symbol references, namespaces, aliases and re-export hops using type-aware analysis. It adds proof to the project-wide usage data and does not return compiler errors.

  Try: “Trace every reference to the User type exported from src/models.ts.”

  Files · trace_symbol

• Shows what a rename or deletion would break

  For a TypeScript export, returns its exact consumers, the files affected transitively and the tests to run. It supports planning and does not replace the compiler.

  Try: “What would break if I renamed parseConfig in src/config.ts?”

  Files · symbol_impact

• Lists files affected by changing one file

  Returns the transitive set of affected files that are not in your diff, and the gaps where modules that rely on the file's contract may need coordinated changes.

  Try: “Which other files could be affected if I change src/auth/session.ts?”

  Files · impact_closure

• Finds functions that do the same thing in different words

  Searches for semantically similar functions with a pinned local model and returns unverified candidates with scores. It never downloads a model, and asks you to run the setup command if one is missing.

  Try: “Find functions in src that look like duplicates of each other even if the code differs.”

  Files · find_similar_code

• Checks one similar-code candidate with evidence

  Reproduces one candidate and returns source, graph, ownership, churn, test and side-effect evidence so you can judge it. It writes no verdicts and edits no code.

  Try: “Show me the evidence for similar-code candidate abc123.”

  Files · inspect_similar_code

• Lists the few design decisions in a change that matter

  Picks out the few structural decisions in a diff: a new dependency between zones, a new or changed public API, or a new third-party dependency, each with the kind of expert to ask.

  Try: “What are the key design decisions in this pull request?”

  Files · decision_surface

• Shows what auto-fix would change, without changing it

  Runs a dry run of the auto-fix and reports what it would remove. No files are changed.

  Try: “Preview what fallow would auto-fix in this project.”

  Files · fix_preview

• Applies the auto-fixes to your code

  Edits your project to apply fixes. It removes unused exports, may delete dead enum declarations, deletes unused dependencies from package.json, removes unused enum members and pnpm catalog entries, and adds ignore rules to the fallow config.

  Try: “Apply the safe auto-fixes for unused exports and dependencies.”

  Delete · fix_apply

• Plans mutation tests without running them

  Lists the code mutations that would be tested, with locations, operators and static test files. It never runs tests, and the real run is a separate command that does.

  Try: “Plan mutation testing for the files I changed.”

  Files · mutation_plan

• Shows one mutation from a saved report

  Shows the original and mutated code, the covering tests and the killing test for one mutant in a saved report. It never runs tests.

  Try: “Show me mutant m-42 from the last mutation report.”

  Files · mutation_inspect

• Combines production coverage data with the health report

  Takes a V8 coverage directory or Istanbul file and returns verdicts such as safe to delete, review required and low traffic, plus hot paths. A single local capture is free, and continuous monitoring needs a license.

  Try: “Use this coverage folder to tell me which functions are never called in production.”

  Files · check_runtime_coverage

• Lists the busiest functions from production coverage

  Returns production hot paths ranked by percentile and call count, each with a cost estimate to help pick speed work. Same inputs and license rules as the runtime coverage tool.

  Try: “Which functions are the hottest paths in this coverage dump?”

  Files · get_hot_paths

• Rates how risky changing a function is

  Returns caller counts, traffic-weighted reach and a low, medium or high risk band for functions, using runtime coverage data.

  Try: “How risky is it to change the functions in this coverage report?”

  Files · get_blast_radius

• Scores how important each function is in production

  Returns a 0 to 100 importance score per function from invocations, complexity and owner count, with a short reason.

  Try: “Rank the most important functions in production by importance.”

  Files · get_importance

• Lists code that looks safe to delete

  Returns verdicts for cleanup review: safe to delete, review required, low traffic or coverage unavailable, based on runtime coverage data.

  Try: “What code can I safely clean up according to this coverage data?”

  Files · get_cleanup_candidates

• Shows where each design token is used

  For Tailwind v4 theme tokens and CSS-in-JS tokens, returns where each token is defined and a count and sample of its consumers. It needs no runtime data.

  Try: “Where is the --color-brand token used across the codebase?”

  Files · get_token_blast_radius

• Pulls production usage data from Fallow Cloud

  Fetches a runtime-context slice for a repo from Fallow Cloud. It needs a cloud API key from an organization on the Pro or Enterprise plan or an active trial.

  Try: “Get the last 30 days of production context for my-org/my-repo from Fallow Cloud.”

  Network · get_cloud_runtime_context

• Pulls production facts for changed files from Fallow Cloud

  Reads production facts for a few changed files or functions from Fallow Cloud without a full pull. It needs a cloud API key.

  Try: “What does production say about the files in this change for my-org/my-repo?”

  Network · get_cloud_review_packet

• Shows how production behavior changed between deployments

  Reads, for each function, how its production activity changed between two deployments, such as newly called or heated up. It needs a cloud API key and gives context, not a deletion verdict.

  Try: “How did production behavior change between the last two deployments of my-org/my-repo?”

  Network · get_cloud_deployment_changes

• Finds feature flags in the code

  Detects environment-variable flags, calls to common flag providers and config-object flags. A top option limits the results.

  Try: “List all feature flags in this codebase.”

  Files · feature_flags

• Reads the opt-in value report for the project

  Shows current finding counts, the trend since the last recorded run, and what the pre-commit gate contained. It runs no analysis and reads a history file stored outside the repo.

  Try: “How has the number of findings changed since fallow was added?”

  Files · impact

• Combines the value reports of every tracked project

  Sums the value reports of all projects tracked on this machine, using hashed project keys instead of paths. It runs no analysis.

  Try: “Show the combined fallow impact across all my projects.”

  Files · impact_all

• Maps a stack trace to the code it names

  Takes pasted stack trace text and classifies each frame as in your project, in node_modules or outside the corpus. It then resolves your project's frames to definitions. It reads no source maps.

  Try: “Here is a stack trace. Which of these frames are in my code?”

  Files · trace_error

• Used by the assistant behind the scenes

  Lists the fallow-ignore comments in your code

  Lists active suppression markers by file with line, kind, reason and whether each is stale, so you can see what a clean result hides.

  Try: “Which findings are suppressed with fallow-ignore, and are any stale?”

  Files · list_suppressions

• Shows your architecture zones and access rules

  Returns boundary zone definitions, access rules, file counts per zone and logical groups. If none are configured it says so.

  Try: “Show me the architecture boundary zones for this project.”

  Files · list_boundaries

• Proposes a fallow config for a project that has none

  Detects the framework, workspace and tooling and returns a proposed config plus the decisions behind each setting. It writes nothing.

  Try: “Propose a fallow config for this repo.”

  Files · recommend

• Runs several read-only analyses in one script

  Runs a short JavaScript snippet in a sandbox that can call fallow's read-only analyses together. The sandbox has no filesystem, network or shell access, and tools that change files are not available.

  Try: “Run dead-code and duplication analysis together and give me one combined summary.”

  Read · code_execute

• Shows the project's plugins, files and entry points

  Returns project metadata such as detected plugins, file list, entry points and boundaries, with options to return only some sections.

  Try: “Which entry points and plugins did fallow detect for this project?”

  Files · project_info

• Explains one kind of finding

  Explains an issue type with its rationale, an example and fix guidance, without running any analysis.

  Try: “Explain what an unused-export finding means and how to fix it.”

  Read · fallow_explain

Watch out for

• It can delete code and dependencies

  The fix tool removes unused exports, deletes unused dependencies from package.json and may delete dead enum declarations. Ask for the preview first and keep your work committed. github.com

• Some analysis tools write files

  Four tools can save a baseline or snapshot file, inside the project root, the CI workspace or the temp folder. A host that auto-approves read-only tools now asks before running them. fallow.tools

• Cloud tools send requests to Fallow Cloud

  They are the only tools that make a network call, and they need an API key from an organization on the Pro or Enterprise plan or an active trial. Skip them if code context must stay local. fallow.tools

• It starts the fallow command for some options

  For options only the command line has, the server runs a fallow subprocess. The FALLOW_BIN setting picks which binary, and the default is fallow on your PATH. fallow.tools

• Telemetry is off unless you opt in

  The README says analysis runs on your machine or CI runner and telemetry is opt-in. github.com

Security advisories